Summary Experience Network Startup Network Migration App Delivery Major Upgrades Tools & Templates Help Desk Standardising Office Move Write Apps Write Documentation New User Guide Technical Skills

Plan, direct and perform all major upgrades.

By "plan, direct and perform", I mean that I research the upgrade as described below, settle on a process that I believe will minimise staff disruption, and schedule and carry out the upgrade. I often have assistance from others, but I own the project from beginning to end.

Major upgrades I have carried out include:

• Upgraded NetWare servers in H&A's Boston office from 3.11 to 3.12; later, from 3.12 to 4.11.
   
• Migrated H&A (the whole company) from WordPerfect/Quattro to Word/Excel 97. Via the magic of WinInstall, the upgrade occurred simultaneously in all offices overnight.
   
• When H&A centralised control of IT, many of the other offices had separate email systems using MSMail, which had been set up independently before the company had settled on Novell's GroupWise. I migrated those offices to GroupWise, and forged a single, company-wide enterprise email system.
   
• Upgraded H&A from GroupWise 4.1 to 5.5.

When I perform a major upgrade, I do it very carefully.

• I look at the new software to find out what advantages it offers, and what features that we use no longer exist or have been significantly modified. Along the way, I verify that the upgrade is worthwhile and necessary; it isn't always!
   
• I then investigate what problems other companies have encountered in the new version or during the upgrade process.
   
• I address any concerns that arise during this research.
   
• If practical, I test the upgrade in an isolated, non-production environment.
   
• Whenever possible, I upgrade a limited set of test users first, and observe their experience.

This preparation shows me what, exactly, the upgrade process is, and what details must be handled before and after it. I document all this, to a fairly horrifying level of detail, so that I know exactly what I'm doing when I get to the Real Thing. A major upgrade can include hundreds of steps, when you factor in the small details that must be attended to along the way. Making a really detailed list helps me avoid inadvertently overlooking any of those small steps. It can also be used to delegate parts of the process to other staff. Sometimes the list comes in handy later, if some part of the upgrade must be performed again (for example, if the company acquires a new office).

This kind of preparation doesn't mean that it takes longer to perform the upgrade. Rather, I spend the time in advance preparation instead of problem-solving afterward. It's a lot easier on the users if we know about, and have prepared for, the problems that the upgrade is going to cause, than if they come as a surprise to us too.

A couple of examples, drawn from my GroupWise 4.1 to 5.5 upgrade:

• In GroupWise 4.1, I had written a lot of macros to automate or simplify common tasks. These macros were in use in all offices, by all staff. During my research prior to the upgrade, I found out that the macro language had been discontinued entirely in GroupWise 5.5! However, it did have a method for integrating programs written in Visual Basic (or C++, etc). So I figured out how all this worked, and wrote VB versions of the important macros, before we did the upgrade. Had we just bulled ahead and done the upgrade, we'd have found out the next morning that none of the macros worked, and it would have taken weeks or months to provide replacements.
   
• We also had several 16-bit applications that were email-enabled using MAPI. 16-bit MAPI and 32-bit MAPI are totally different, noncommunicating animals. Each of these applications (many programmed in-house) had to be upgraded to a 32-bit version, and the upgrade had to happen simultaneous to the GroupWise upgrade. Had I not found out about the MAPI problem, we'd have been scratching our heads saying "Oh yeah, MAPI..." the morning after the upgrade.
   
• A simpler, but more immediate problem: The GroupWise 5.5 client required a lot more disk space than 4.1 did. Many of our older computers simply didn't have room. I had to decide in advance how to handle these cases, because an email upgrade is all or nothing; you can't leave some computers running the old version.

I follow a similar preparation process for major hardware upgrades (servers).

Here is an example of a list of steps (Acrobat; 64 KB) from a major upgrade. It is, as I've mentioned, horrifyingly detailed, but it does convey a sense of the care with which I approach major upgrades.

See also my musings elsewhere on the subjects of cautious and well-planned upgrades.