As with installation, there are a variety of ways to make upgrading less painful. For starters, review the algorithm for installing software presented in Chapter 11. Upgrading typically follows the same steps, and this algorithm will help make certain you're not missing anything important and that you're asking your customer to do things in an orderly manner.
Choices for Painless Upgrades
Upgrading raises some additional issues best handled by the entire development team working together. Consider the following.
Number and Timing
Customers can't absorb releases that occur too quickly, and they get frustrated and concerned if releases happen too slowly. You have to understand the events and rhythms of your market (see Appendix B) to know how frequently you can create and distribute upgrades.
All of the steps I recommended in Chapter 11, such as checking for the necessary disk space and verifying configuration parameters, still apply. In addition, and depending on the upgrade, you may want to examine how the customer is using the current version to determine the best upgrade approach. For example, suppose that your system is composed of several optional features that can be installed as part of a custom configuration. Before simply upgrading various components , you should check what has been installed to make certain you only change what must be changed. A good rule of thumb is that it is best to make the least amount of changes possible when performing either an installation or an upgrade.
It sounds simple: Take data from version n -1 and migrate it to version n. It might actually be simple, depending on the changes being made in the system. Unfortunately, in the real world of working systems and customer environments things are surprisingly complex.
Recall that data is typically stored in two basic formats: Semi-structured data in files, and structured data in a database management system. Data migration for these formats differs in a number of ways, including when the data has to be upgraded and how much work the customer must do during the migration process.
For data stored in a database, you have to work out the data migration process because chances are that all of the data must be migrated at once. This can be pretty simple if you're absolutely certain that the customer hasn't modified the schema in any way. If they have, you're going to have to find a way to handle the modifications. You can require your customer to do all of the work (e.g., export all customizations and associated data and then import them after the upgrade), but then, if your customer doesn't want to do this work, you may have to create the tools to do it automatically. I've had the best results with a middle-ground approach, in which developers write special tools that the professional services organization then uses in the field. It is imperative that the services organization understand these tools because there is a good chance they will have to modify them in the field to deal with unique problems that occur only in customer environments.
Data stored in a flat file can often be upgraded on demand, such as when an application opens a data file from a previous version but stores it in a new version. It is good practice to warn the user that you are doing this.
Upgrade Configuration and Customization Information
Like many users of Microsoft Office products, I customize these products according to my personal preferences. Unfortunately these settings are not preserved when I upgrade from one version of Office to another, which is very frustrating. Don't make this mistake with your users. Make certain that you upgrade configuration and customization information.
A big problem with migrating data from a previous version to the current version is that probably not all of your customers are going to be running the same version of the old software. If you're releasing version 3.7, you may have to deal with customers who are upgrading from any prior release. Only a careful examination of your customer base will let you know how many previous versions you need to handle.
There are two basic strategies for dealing with older versions, and a sensible approach often combines them. The first is a single-step migration, in which you provide a direct path from any previous version to the current version. The second is a multistep migration, in which you pick a subset of the previous versions that can be upgraded to the current version. Customers whose version isn't within this subset must first migrate to one of the versions in the supported set. To make certain you're managing all of the prior versions, draw a directed graph that includes all versionseven versions that are not supported but may still be in use.
Coexist or Replace?
A special issue in upgrading existing software is whether or not the new version should completely replace one or more existing components or co-exist with them. Resolving this requires a detailed technical understanding of the dependencies between system components as well as marketing's input on the user experience. While successful systems have used both approaches, I recommend replacing components if at all possible. If you don't, you'll confuse your users, who won't know when they should remove the old version (if it wasn't safe to remove it during the upgrade, when will it be safe to do so? And who will remind the user when they should do this?).