by John Browne, on Apr 29, 2013 1:43:00 PM
On August 24, 2013, I'll be celebrating a wedding and Windows XP will be wearing a party hat for its 12th birthday.
Almost 40% of desktops are still running Windows XP. And they're not all old machines. Some of them are fairly new, with IT sticking XP and all their line of business apps on the new laptop because why? Because they only run in XP.
And now with the enterprise giving Windows 8 the same welcome your big sister used to when you wanted to tag along on her date, Microsoft is making a big push to migrate all those desktops to something (anything!) newer, and that looks increasingly like the venerable and much-loved Windows 7.
Start button and all. 
If it was just buying the OS and running setup, it would be a no-brainer. After all, Windows 7 is a GREAT OS. It's lean, it's mean, plug and play replaced plug & pray, and best of all it's got desktop gadgets. XP is like your Dad's Dodge Dart (old, clunky, but reliable). Windows 7 is a C6 Corvette.
But you can't just run setup, because the gulf is too wide from XP to Win7, so there's no in-place update. You have to start with a clean slate. FDISK your C: drive and start from scratch. Find all the install disks for your commercial apps, assuming they will still run on Win 7.
But even that's not the elephant in the room. The real problem is with legacy applications: particularly VB and .NET 1.1 applications.
Windows 7 ships with a built-in XP VM called "compatibility mode." You can run an old XP or Win16 apps inside this VM, but there are plenty of issues that brings along. Basically you're inviting a disaster using this mode, and we've heard from enough IT managers to know this isn't acceptable to them.
Visual Basic is, by several ways to measure, the most successful programming language. Ever. And 35% of legacy applications were (and still are) written in VB6 or earlier. It's a non-trivial task to move those to a more modern platform like C# or VB.NET. (Note: even though we make THE tools to move these code bases forward we would never call the migration tasks trivial: there's plenty of work to go around.)
Problem #2 is old .NET versions, specifically 1.1, and C++/Win32 apps (some of which targeted the original .NET framework). These will require a lot of modernizing, from dealing with deleted .NET types to moving from Win32 API methods to 64 bits. For example, any bit-level functions might change when different types change sizes. Someone will have to go look--line by line--at code to see what needs to be changed.
With XP going out of maintenance on Apr. 8, 2014 (247 days from today), the chatter, as they say, is picking up. After all, these migration projects will take some time.
Regrettably there's no easy solutions, although outsourcing is probably the least painful. When should you start? As my good friend Jim likes to say, "The best time to plant a tree is 10 years ago. The next best time is today."
