Making Upgrades Less Painful

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.

Upgrade Readiness

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.

Data Migration

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.

It's Easier to Say Yes than No

I've earned a reputation of fairly ruthlessly assessing application features. Simply put, if a feature isn't needed, take it out. Of course, like so much advice this is easy to say but hard to do. Removing a feature is usually traumatic because it raises all sorts of questions: Which customers are using this feature? How are they using it? How will they react if we take it away? Attempting to answer all of these questions can be costly and time consuming. Even asking the question can alert customers to a potential change, and there are times when it is best to deal with customers affected by such a decision in a very controlled, and subtle, manner.

Virtually the only way to remove a feature is during the upgrade process. Features often correlate in some way with the application's persistent data. By carefully assessing the persistent data of an existing installation, you can often determine if a feature is actually used. If the data indicate that it isn't being used, then you can often relatively quietly drop support for it.

In one application we allowed our customers to associate keywords with certain data. We thought this implementation was good enough, but it really wasn't. It was too hard to use and the results weren't all that useful. A more thorough analysis showed that making this feature better would be much more work than originally expected. So, since it wasn't as important as other features, I decided to remove it. The team modified the upgrade procedure and analyzed the database. No keywords meant no use of the feature and safe removal.

More generally , it is a good idea to write a program that assesses the current installation to determine the best way to upgrade it. A good assessment will let you know how the system is being used (based on persistent data) and may tell you about any modifications, integrations, or extensions, and it will help you identify any ripple upgrade requirements. Log files, configuration and customization files, and even corporate settings (such as LDAP servers) are sources of potentially useful information that can help you plan a sensible upgrade, including the removal of features.

Finally, if you use this technique to help you remove features, remember that removing a feature is more complex than examining persistent data and removing some software. Feature removal requires coordination among the entire development team: Printed and on-line technical documentation needs to be updated, services must be informed, and training programs may need to be added. In other words, removing a feature is at least as hard as adding one, often more so (which makes you wonder why features are added so easily in the first place!).

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.

Previous Versions

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?).

Which Version Do I Use?

As mentioned in Chapter 6, allowing multiple versions of the same application or product on the same system increases testing complexity (the matrix of pain) and often increases support costs. For example, I was confused when I installed an AOL upgrade on my laptop and found that my desktop had two nearly identical shortcutsone referenced the old version; one the new version. They looked identical, and even more frustrating, not all of the data I had entered into my old version was transferred so I had to do it by hand. I don't mean to single out AOL. All of the applications I use on a regular basis have a variety of upgrade- related problems, ranging from data migration to unknown or unstated ripple upgrade requirements. Given that more money is made in upgrades over the life of a successful application than in its initial sales, you would think that marketects and tarchitects would take the upgrade process more seriously.