As the clock ticks down to end-of-life for Windows XP, several tricks from Y2K conversion projects have become relevant again.

 

 

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.

By Mary Shacklett in 10 Things, February 19, 2014, 5:46 AM PST