Keeping your DBMS software up-to-date can be a significant job. The typical release cycle for DBMS software is every 18 to 36 months for major releases, with constant bug fixes and maintenance updates delivered in between those major releases.
In a complex, heterogeneous, distributed database environment, a coherent upgrade strategy is essential. Failure to plan your upgrade can result in improper and inefficient adoption of new features, performance degradation of new and existing applications, and downtime.
An effective DBMS upgrade strategy must balance the benefits against the risks of upgrading to arrive at the best timeline for migrating to a new DBMS version or release—and there are risks when upgrading to a new DBMS release.
A DBMS upgrade can cause disruption to business operations. At a minimum, databases may not be available while the DBMS is being upgraded. This can result in downtime and lost business opportunities if the upgrade occurs during normal business hours (or if there is no planned downtime). Clustered database implementations may permit some database availability while individual database clusters are migrated to the new version. Other disruptions can also occur, such as having to convert database structures or when features are deprecated. Delays to application implementation timelines are another possibility.
The expense of an upgrade can be a further barrier to release migration. The cost of the new version or release must be budgeted. DBMS vendors typically increase the price of a new DBMS version by as much as 10–25%. The upgrade budget must also factor in the costs of planning, installing, testing, and deploying not just the DBMS but also any applications using databases. Finally, be sure to include the cost of any new resources required to use the updated features delivered by the enhanced DBMS version.
There are many rewards that can be gained by upgrading to a new DBMS release, though. Often, developers can avail themselves of new features and functionality delivered only in the updated release. Quick ROI for upgrading may be achievable when program development time can be reduced or made more cost-effective. And new DBMS releases usually deliver enhanced performance and availability features that can optimize existing applications.
DBMS vendors provide better support and respond to problems faster for a new release of their software — so maintainability improves by upgrading.
There may also be cost-savings that accrue by upgrading to a new DBMS release. Older versions that have reached their “end of support” date can be expensive to manage. Sometimes, extended support can be purchased for “unsupported” versions but usually at a very high price.
After weighing the benefits of upgrading against the risks of a new DB2 release, the DBA group must create an upgrade plan that works for the organization. Sometimes, the decision will be to upgrade immediately upon availability, but often there is a lag between the general availability of a new release and its widespread adoption. Your organization style will come into play when deciding on an upgrade timeline.
Industry analysts at Gartner developed an organizational ranking system with three distinct groups: Types A, B, and C. Type A is technology-driven and will be more likely to risk using new and unproven technologies to try to gain a competitive advantage. Type B is less willing to take risks but will adopt new technologies once others have shaken out the bugs. Type C is conscious of cost and averse to risk so it will lag behind when it comes to technology migration.
Only type-A organizations should plan on moving aggressively to new DBMS releases immediately upon availability if the new features of the release will deliver advantages to the company. Type-C enterprises should adopt a conservative strategy to ensure that the DBMS release is stable and well-tested by types A and B first. Type-B organizations fall somewhere between types A and C. Rarely upgrading immediately, the type-B company will adopt the new release after the earliest users have shaken out the biggest problems but well before type-C enterprises.
Some type-C (and, perhaps, type-B) organizations try to get by running DBMS versions that are no longer supported by the vendor. This might seem to be a less risky strategy than upgrading to a new version, but it actually can be more troublesome. Unless you negotiate a high-cost, limited-support contract from the vendor, any bugs or errors you encounter can bring your organization’s applications to a standstill. Running unsupported DBMS software is not a wise course of action if your organization is conducting mission-critical services using that DBMS.