Onward to OnBase 17: a Release Candidate upgrade success story

When it comes to upgrading OnBase, there are typically three types of upgrade interval strategies that I see organizations use. For the sake of this discussion, I’ll refer to these as Musts, Wants, and Requires.

The Musts have a tendency to wait until it is absolutely necessary to upgrade their OnBase solutions. “Musts” tend to go for longer periods between upgrades because they are driven by platform obsolescence, such as when Microsoft announces it will stop supporting a server OS or SQL version.

The Wants will upgrade based on new OnBase features or integrations. Wants upgrade with purpose and strategy, but sometimes sporadically. They may upgrade two years in a row, and then wait a couple of versions.

The Requires are our more business-driven users and have strict policies on exactly how often OnBase upgrades must occur. Requires upgrade with clockwork regularity, sometimes down to a repeatable quarter.

There is no “one-size-fits-all” upgrade solution, but typically, Hyland does recommend upgrading at least every two years in order to keep .NET, server OS, and database platform support parity between the legacy and upgrade version of OnBase.

Drinking our own sparkling wine

That said, today we’re going to talk about a customer that defies these generalities and performs approximately three enterprise-wide upgrades to its OnBase solution every calendar year. Definitely in the Require category, its business demands the organization to upgrade every time OnBase releases a new version, as well as install every service pack. It is also at the lead of waiting lists for several new features every year, as its software change requests for fixes and enhancements help drive our development and keep pushing our product further.

I am speaking of none other than Hyland’s own internal OnBase application.

As you can imagine, we’ve implemented OnBase in every corner of our enterprise. If you’ve been to CommunityLIVE in years past, you may have heard Hyland’s own Dan Preputnik discuss upgrades, WorkView/case management or how to administer and support an OnBase system. Dan serves as a team lead for the administration and support resources of our internal OnBase team.

I spoke with Dan recently, and he had a lot of great things to say about our internal OnBase team’s upgrade experience to a Release Candidate build.

Mike: First off, I appreciate you taking the time during this busy period for your team while you continue to roll out our upgrade to OnBase 17. Can you tell our readers a little bit about the OnBase system your team supports?

Dan: Thanks, Mike. Yes, Hyland has its own internal implementation of OnBase that we use across every department in the organization. Our system has evolved over the last 20-plus years and now contains over 150 separate solutions, hundreds of workflow lifecycles, thousands of document types, 55 WorkView apps (and counting), and countless amounts of data. It is truly a critical line of business (LOB) system for us that continually helps us to be a more effective organization.

Mike: I’ll start with the question many of our readers are probably thinking right now; how in the world do you stay on top of three upgrade projects every year?

Dan: Actually, performing upgrades that often makes the experience easier for us, since it keeps the process fresh in our memory and allows us to iterate and make it more efficient each time. We always upgrade with the annual release cycle, but also with nearly every service pack that Hyland releases.

The annual release is where we spend the majority of our time testing and planning; however, we aren’t doing it alone. We have identified solution owners and knowledge experts across our organization and enlisted their help. We have invited them to our “upgrade testing” sessions so they, being the most familiar with how everything is meant to work, can validate their processes in our test environment and walk away with the comfort that there won’t be any unexpected issues when the upgrade to production happens. Also, bribing them with donuts and other snacks doesn’t hurt.

Mike: Tell me about your experiences with end-user testing. It sounds like that helps your team a lot when it comes to upgrading OnBase.

Dan: Indeed. As I mentioned, having those solution owners and knowledge experts come test with us takes a large amount of burden off my team. Even though we may be the administrators and even the architects of the solutions within our system, we aren’t the ones who are using those processes day in and day out. Those who do are far more effective at quickly verifying that things are working as they should than my team ever could be – in the same amount of time.

23 years, 20 million documents

Mike: Can you give some general information about the size of your OnBase system?

Dan: Well, it’s been around for just a bit, about 23 years or so, and has grown quite a lot in that time, as you’d imagine. At my last count, we had about 20 million documents and records in our system, growing at about 3 million per year at this point.

The logic around that data is supported by 500+ workflow lifecycles, 1,500 document types, 1,400 WorkView record types, and 55 individual WorkView solutions. As you can see, it’s a nice little system.

Mike: How have incremental parallel upgrades impacted your team?

Dan: Would a “Grand Finale Fireworks Spectacular” properly convey my excitement and love of the IPUP?

I hope that paints a clear picture. I can sit here and tell you stories of years past when we’d have all-hands-on-deck for an entire Friday evening of system downtime, late into the night and sometimes throughout the weekend, performing an upgrade and hoping everything went as planned so that we didn’t have to roll back. Or having the knowledge that come Monday morning, we’d have a deluge of issues, requests, and installs that didn’t quite work to contend with.

With incremental upgrades, all of that is a distant memory reserved for fireside tales with the newer staff members explaining how we did things “back in the old days.” These days, we have only one or two employees performing the upgrade, with as little as half an hour of downtime. From there, we can do everything during business hours and rollout to groups within our organization in an orderly manner. This ensures both everything is functional early, but also gives our internal administration and support team the breathing room necessary to tackle issues in a manageable fashion, thereby keeping stress low and avoiding any hesitation or fear of upgrading from everyone involved.

Mike: What can you tell our readers about this years’ upgrade to OnBase 17? You’re upgrading your production environment with a Release Candidate build, correct?

Dan: Yes sir. Actually, we are a few builds ahead of the Release Candidate. That’s how stable the software is. Our entire organization is now running on OnBase 17. I am thoroughly impressed with the improvements made in both product as well as the release cycle and the quality of the software prior to its “official” release.

Mike: This year has been the first version OnBase has had a Release Candidate. What are your impressions?

Dan: I’m a fan! Changing the way we release software to this methodology has allowed us to focus more time on getting nearly everything right straight out the gate, but also allowing for that dedicated time to make adjustments here and there while still being in the “high alert, crunch time” mode that guarantees visibility and quick resolution to any issues found.

Mike: Not that you have much of a choice, but will you be using Release Candidate again next year?

Dan: Indubitably. End of story.

I hope this discussion has you thinking about your next OnBase upgrade, and checking out the Release Candidate program if you haven’t already.

Sun Tzu said, “Every battle is won before it’s ever fought.” This is also true of software upgrades; thankfully, OnBase has the tools and training to help you prepare, whether you’re a Must, Want, or a Require.

There’s still time to start preparations for your OnBase 17 projects with Release Candidate before June 26. Contact your first line of support to get started with OnBase 17 today.

If this article has inspired you or if you have any follow-up questions, you can find us on the OnBase Community in the Upgrades forum. Or leave a comment below.

We at Hyland are proud and happy to “drink our own champagne” when using our OnBase products. Although technically, since OnBase is made in Northeast Ohio, we are drinking our own sparkling wine. Yes, that’s a joke for all you oenophiles out there.

Mike Current started at Hyland in 2010 as a technical support rep and cloud engineer for Global Cloud Services. He is currently an Infrastructure Admin in Quality Assurance. Mike tests configuration, runs projects such as Release Candidate and the OnBase 16 Beta Program, manages the “Mitigating Risk in OnBase Upgrades” whitepaper and evangelizes synchronous and incremental parallel upgrades.

Outside of OnBase, Mike loves spending time with his family, working out and playing Xbox. He can often be found sipping a whisky and talking about geeky things while watching a Patriots football or Cleveland Cavaliers game.
Mike Current

Mike Current

Mike Current started at Hyland in 2010 as a technical support rep and cloud engineer for Global Cloud Services. He is currently an Infrastructure Admin in Quality Assurance. Mike tests... read more about: Mike Current