Regular readers of this column are aware that I am a proponent of getting rid of bad database standards. But sometimes it can be difficult to determine if a particular standard is bad, or just a lot of trouble to comply with!
Well, what am I getting at here? Have you ever been thwarted by a global fiat from management? Of course you have, we all have. But I’m talking about a particular type of dictum from above. Something like this: “New software installations, including updated versions and releases, must be supported by current tooling before they can be installed.”
Now, I suppose that the overall intent of this ruling is good. After all, you’ll want to use your tools on the new software when it gets installed. Think about it: if your database change management tool doesn’t support the new features of the new version of Db2 (for example), then you won’t be able to use new features until it does. This is especially true if your standards enforce the usage of a change management tool to make database changes (which is also a good idea, in general).
But a rule such as this can make it practically impossible to introduce anything new. Think about the following, which is not all that uncommon in modern software stacks: What if we have an ERP package that relies on a particular DBMS feature and we use a database change management tool that interacts with our modeling tool and our application program change management tool? And, that database change management tool uses utility programs from another software vendor to load and unload data. Oh, and our help desk, which uses an Application Server stores trouble tickets in a database managed by that same DBMS. And, maybe you have written application programs using multiple different programming languages to access data in that DBMS.
Go ahead… poke that stack of cards somewhere by attempting to upgrade one of the components. Any one of them. Can you categorically verify to upper management that all of these things will work together correctly? Not without a lot of reading and testing and worrying, you can’t!
Of course, there are nuances to consider. What does “support” mean, after all? Having worked at various ISVs I know that it can mean any number of things. Many ISVs have differentiated between “support” and “exploit.” Support means the tool will run without breaking on the new version and support all old functionality. Exploit means what non-IT humans would think “support” means’; that is, it works with all of the functionality of the new software, both the old features and the new ones.
So, in this case the managerial dictate is probably not worded in such a way to comply with what a DBA would think of when considering new version support (and exploitation). Nevertheless, the intent of the edict is sound, and DBAs need to have plans in place for managing software upgrades that involves careful coordination, detailed planning, and thorough testing. So, what steps can be taken to ensure a reasonable upgrade process?
The first steps should be an assessment and inventory of your current implementation, where you identify dependencies. This requires listing all the software and systems that interact with the software being upgraded. Then, you need to assess compatibility by checking the new software version with existing systems and infrastructure. This can be tedious and time-consuming. The end results should be a document of the current state showing current versions, configurations, and dependencies.
Next, you need to establish stakeholder engagement. Communicate with stakeholders by informing them all about the planned upgrade, including IT teams, business users, and external partners. In some cases, this will require expanding the upgrade team to include more participants.
Be sure to then conduct a risk assessment study to identify potential risks associated with the upgrade, such as downtime, data loss, and compatibility issues. You can then create plans to mitigate identified risks, including rollback plans and backup strategies.
After that, you must move into the planning and design stage by defining the scope and objectives of the upgrade project, followed by developing a detailed project plan with timelines, milestones, and resource allocation. This should include different types of testing (unit, integration, system, user acceptance testing) to ensure the upgrade does not disrupt existing functionality.
Keep in mind, the upgrade plan will likely require instructions for updating multiple pieces of inter-related software, as discussed above. But not every piece will need to be updated at the same time. So, timing should be a crucial component of the plan (e.g., database change management tooling should be updated before the DBMS is updated).
Do not ignore training and documentation. The migration team will need to update all relevant documentation to reflect the new software version and any changes in procedures. Likewise, training sessions should be provided for end-users and IT staff on the new features and any changes in the workflow.
Then you need to plan the implementation, including scheduling downtime, if necessary. After deploying the upgrade according to the project plan, conduct appropriate tests by monitoring the system and running post-upgrade validation scripts to ensure that all systems and functionalities are working as expected. Be sure to plan for time to resolve any issues that arise.
Summary
Systems comprised of multiple inter-related pieces of software and infrastructure can be difficult to upgrade. Nevertheless, you will be called to do so because system software is always changing to add features and functionality that can benefit your organizations. By understanding the difficulties involved, and following the steps outlined here, you can effectively plan and execute software upgrades while minimizing risks and ensuring a smooth transition. But, please, don’t poke that stack of cards without a plan!