"Hell, there are no rules here -- we're trying to accomplish something."
-Thomas A. Edision

Zero Downtime Upgrades
Congratulations! The upgrade was a complete success. Using the latest techniques in zero downtime upgrade ingenuity, your IT staff was able to complete the "big rollout" of the new version of your software with no downtime to the end user.

There are many tricks that can be used to do an upgrade with zero downtime. The most common is the "High Confidence Upgrade" where the upgrade is done in place on existing live servers. This requires testing and re-testing to the point where confidence is high that the upgrade will complete error-free and without interruption of service.

If you have the budget, a better option is the "Orphan Upgrade" where new software is installed and tested on separate, often new hardware. The actual upgrade consists simply of redirecting the firewall or load balancer to make the new servers become the live servers. Should something go wrong, the old servers with the old version are still available. If it does work, the former live servers become "orphaned" and are used to stage the next version and the process repeats.

So if the upgrade was so successful, why is your helpdesk phone ringing off the hook?

Fuzzy Downtime
Your precious zero downtime upgrade changed the UI, as most major upgrades do. Sure your application works, but it sure doesn't work like it did before. Any upgrade that breaks the UI is a temporary degradation of service. Since this brownout is not quantifiable we call it fuzzy downtime. And now your users are calling to let you know about it.

You say improvements, your customers say confusion. You say upgrade, your customers say I want the old stuff. All metrics report your application to be working quite well thank you very much. Yet user productivity is off. Complaints are up.

Should you really care? Complete the following survey concerning your attitude about the impact of UI upgrades on end users:

a) Users are a bunch of whiny babies who should learn to adapt
b) We will do hand-holding as needed but we're not really concerned
c) We sent an email telling users about the upgrade
d) We carefully and systematically prepared users for this upgrade. We informed them numerous times in advance of when the upgrade was coming. We provided sneak peaks and training on the new interface. The new UI offers improved help features, better search and disambiguation pages. We also planned for a temporary increase in helpdesk staff to assist with the expected increase in support requests.

If you answered "d", well done! If you answered "c", you get an honorable mention. If you answered "b", your users must be geniuses. If you answered "a", stop reading this article immediately and click here for some quick therapy before returning.

And if you are wondering what that disambiguous word was, please read on.

Disambiguations
Wikipedia uses disambiguation as a way to resolve ambiguity. Disambiguations are pages within Wikipedia that lead to different topic pages that share the same term in their title. If you search for "bugs" on Wikipedia, you get a disambiguation page asking if you were looking for the plural of "bug" or Bugs Bunny or something else. The disambiguation page lists several possibilities and allows you to choose.

Could your fuzzy downtime problem be minimized through the use of disambiguation pages? Most certainly it can! For starters, when a user clicks on "help", do you really know what they want? Provide a disambiguation page for clarification. For example:

You are looking for help. Did you want to. . .
Contact us for technical support?
View our FAQs?
Look at our Top 10 Knowledge-Base Articles?
Browse our Online Help?
Search for Something in Particular?

Disambiguation pages can help users adapt to the new look and feel of your software. Once you embrace the concept of disambiguation pages, you realize they empower the user. Clever use of disambiguation pages can even be used to promote premium features or additional services.

If you have online software, you already know that change is inevitable and constant. Handling the change event is important and zero downtime upgrades are a great way to do it. But the release itself is only the first step. Every manager should look for new ways to help users cope with the added complexity and ambiguity each new release brings.