Frequency
Because most ECM systems have a regular yearly release, it is ideal to
realize the benefits of upgrading every year. This will help with keeping up
with OS and database upgrades as well.
SP2
In general, upgrades to enterprise software should wait for
Service Pack 2 of the current release. This allows for initial release bugs to
be fixed and stabilized. For OnBase, this usually puts the upgrade window in
the third quarter of any given year.
Budget
If an upgrade is planned for every year, the budget line
item will smaller and more digestible by management.
Schedule
An upgrade schedule should be regular and expected. The more
regular, the easier and less expensive it is. The resources involved with not
being trying to remember all the steps from scratch again. The steps themselves
will be more up-to-date.
IE, OS and Database
At the enterprise level, you don’t want OnBase slowing down
IE releases, or database upgrades. It makes sense to keep up.
Environments
With VMs and multiple environments, upgrade steps can be
written and tested many times before the actual upgrade. This should help
minimize risk for each upgrade cycle.
Enterprise system upgrade and implementation schedules
It’s important to get on the upgrade train each year (or
two) as early as possible. There will always be larger, more important
initiatives that will bump OnBase upgrades, but at least you’ll be on the list.
When new solutions are being developed, the requirement to be using the latest possible version of software is much more important. Even one year can make huge difference between solution offerings.
Sample Upgrade Matrix
There are concerns and potential issues when it comes to planning and executing upgrades. As the scale and complexity of the solution increases, so does the upgrade matrix.
Concern
|
Solution Details
|
Impact on Solution
|
|
Impact on Users
|
|
Environment Setup
|
|
Integration
|
|
Complexity
|
|
Cutover Approach
|
|
Downtime requirements
|
|
Testing
|
|
Upgrade Risk
|
|
Risk of Waiting
|
|
Resources
|
|