Remember the great Y2K conversion? Even though it’s been 14
years, the Y2K playbook included several excellent strategies you can apply to
large-scale migrations off Windows XP. Like Y2K, Windows XP’s end of life has a
drop-dead date: April 8, 2014. So if you’re watching the grains slip through
the hourglass, these key plays from Y2K initiatives might keep your aspirin on
the shelf.

1: Accept disruption

Anytime you have a large user base and a definite end-of-life
date, there is bound to be disruption, because not all migrations are smooth or
entirely predictable. Organize a phased migration plan that proceeds either by
application or by user area. Ensure that everyone involved has visibility of this
plan and your progress against it.

Keeping your plan visible and updated takes a lot of the mystery
and the anxiety out of the process for end users and IT staff. You should also
have a “Plan B” failover strategy in case an application migration
fails: Continue to run the app on XP (even once XP is unsupported) until you
can safely migrate the app over to its new operating system. (Note: At least
the XP Plan B beats Y2K’s, which for many IT departments was a set of one-way
tickets to Rio!)

2: Don’t get
fancy

Stick with just doing a straight app conversion and avoid the
temptation to enhance an app or add something new that is custom. If you don’t
keep your code base the same on both sides of the migration, you’ll complicate the
process. Custom changes can introduce their own sets of bugs.

3: Get upfront
buy-in on the budget

It costs money to migrate. Businesses don’t like to pay for
projects that return little value because all that is accomplished is that the
same apps you’ve always run now run on something else. During Y2K, CIOs faced
major hurdles obtaining the budgets they needed to do the full Y2K job. Until
enough “risk” articles appeared in magazines about Y2K, many CEOs had
trouble believing that a little date routine could put their entire business at
risk. Budgetary support eventually got there, but CIOs had to fight for it. If
you have a budget issue with your XP migration, make sure your higher-ups
understand that you might have to run certain areas of the business on unsupported
software for a time — and what the risks are in doing that.

4: Have a risk management/failover
strategy in place

If your XP migration is exceptionally large, you will likely
experience some migration failures (or at least complications). Define a failover
methodology and allocate IT resources for failover so that your staff can quickly
migrate an application back to the original XP platform if that becomes
necessary.

5: Don’t count
on vendor support

Most vendors were great during Y2K — but some weren’t. In
fact, there were those who didn’t even warn you about a Y2K date bug they
already knew about until your conversion failed. Y2K folks quickly learned who
these vendors were and didn’t count on them for support when they had to resolve
an issue. The XP migration team should adopt the same self-reliant attitude.

6: Identify
your must-have apps

If you have a large XP migration comprising many applications,
sit down with your users so you can all agree on a prioritization of which apps
should be migrated first. These apps should be the most mission-critical to the
business. You want to include your end users in this exercise because you need
business buy-in. If everyone agrees to the game plan, they will be much more
understanding if time runs out and you couldn’t complete a total migration of
all applications.

7: Choose total
deconversion where it makes sense

One of the best things about Y2K was that it gave IT departments
(and the business) an opportunity to throw out the trash. As IT and end users worked
though the library of enterprise applications, a number of apps were discovered
that had been installed but not actively used for years. In other cases, apps
were so archaic that it was pointless to convert them. XP should present
similar housekeeping opportunities.

8: Consider the
cloud as an alternative

Migrations are a great time to consider whether you want to
move an app to a cloud vendor forever —or if you’re up against the deadline,
move an app to the cloud until you can migrate it internally. Cloud is one weapon
IT’ers didn’t have during Y2K.

9: Communicate,
communicate, communicate

One of the greatest moves from the Y2K playbook was the
focus on daily project communications to end users, to IT, and to critical stakeholders
in the enterprise, such as shareholders and boards of directors. After all, a
failed Y2K conversion could break a business. The stakes may not be as great
for XP conversions, but plenty of concerns can still be mitigated if IT regularly
communicates status to interested parties.

10: Share the
pain and the solutions with others

Widespread collaboration on problem resolutions and tricks
of conversion between companies was a trademark of Y2K. It might have been one
of the few times when companies that normally were fiercely competitive with
each other opened their doors and shared both pain and solutions, because everyone
had a common objective to beat the clock with their date fixes.

Organizations with major XP conversions can do the same thing.
Sharing information on fixes and problems saves time and frustration. And it
lets you know that you are not the only one out there who is wrestling with the
migration.

Good times…

Were you involved in Y2K conversions? What other strategies
from those days are playing into your Windows XP migration plans?