"Windows XP will essentially have a 'zero day' vulnerability forever". These spot-on select words come from Tim Rains, who penned a stellar TechNet blog post back in August on the impending XP doomsday. That entry, aptly titled "The Risk of Running Windows XP After Support Ends April 2014" goes into a deep discussion about the underpinning reasons as to why it's so critical that organizations start moving their fleets off the now 12 year old OS.

I've been writing extensively about the end of XP for some time now myself, advocating customers begin their planning well ahead of the support sunset date.

So the bigger question then becomes: what exactly is holding organizations back? I've heard all possible reasons under the sun, and many of them are logical business concerns which have to be addressed. From budgetary gripes about hardware upgrades, to a lack of internal expertise and manpower. But by far, it seems that concern about legacy applications takes the cake, if survey results garnered by IT consulting giant Avanade lend any credence to the discussion.

In fact, of the 200 CIOs and IT leaders that Avanade surveyed in the UK about their post-XP migration plans, 80 percent of them cited concerns about legacy application support. That's huge; it translates to a full 4 of every 5 IT decision makers having solid worries about their legacy apps in a world after XP. Concern of similar proportions stem from the consistent shift towards BYOD -- a full 91 percent of this same group claim that their legacy apps present a big problem for the bring your own device future.

But standing still and letting April 2014 come and go without a plan of attack is on par with committing a prolonged IT suicide. Recent stats have placed Windows XP as being 21 times more likely to become infected compared to Windows 8, and this figure is likely to shoot even higher once next April hits. Right now, at least, Microsoft can keep treading water for customers still on XP when it comes to system security and patching. After next April, the criminals will officially have the upper hand since Microsoft throws in the towel on XP altogether.

The security outlook for Windows XP is deathly grim, according to stats from Microsoft and explained on this blog post. The above chart displays relative infection rates among all Windows releases since XP, compiled as of Q4 2012. The safest OS? Windows 8 by far. Even the universally despised Windows Vista trounces XP as far as security goes. Hopefully these numbers instill some real urgency into those still harboring XP fleets. (Source: Microsoft)

Moving off of XP is nothing less than an arduous journey. It's a painstaking effort, no doubt, that needs to combine excellent planning, precise execution, and a reliance on solid technical expertise (whether it's internal or external, which I touch on later). Before you can even begin to talk about the technical aspects of a move, it's critical to cover your preliminary baselines first. Just like any sizable IT project: garbage in, garbage out.

Here are a few commonsense best practices that any organization looking forward to an XP migration should be outlining before a single system is touched:

Inventory your organization. You can't solve a problem in which you have no information to base decisions from. How many XP desktops are truly still in production? How many of those machines don't have dual core, 64 bit processors? Upgrade vs replace is a large part of the budget discussion, but without solid inventory numbers, you have no recourse for allocating appropriate funds for necessary hardware replacement.

Evaluate your application footprint & stamp out functional overlap. When is the last time your organization actually studied which installed programs are still used? Likewise, which legacy applications have been functionally replaced by other programs? Centrix Software released a study that found this problem is plaguing a lot of organizations these days. Of the small percentage of apps that were found incompatible with newer operating systems, a full 75 percent of those were never actually used anyway. The same study found that a full 50 percent of all applications installed on XP systems weren't being used. This means companies have a lot of "application bloat" that is only coming to the surface now due to a forced spring cleaning.

Perform thorough application compatibility testing. Once you've trimmed down your application footprint on the above recommendation, and found out what your company truly needs to keep moving forward, you can begin moving ahead with compatibility testing. See what will and won't work natively on Windows 7 or Windows 8. You may be surprised in the end. Lots of application vendors that were screaming about their apps not being ready for the new OSes have either introduced patches to make them work by now, or have provided reasonable instructions for getting the apps to work using "Compatibility Mode" settings, for starters. This has been the case more often than not for my own customers -- alleviating the need for any kind of app virtualization or long term XP plans.

Don't forget about your peripherals. Too many organizations become so focused on their legacy apps and computers that they completely overlook the fact that peripheral support could sometimes be nastier than the application front. Printers especially can be a nagging nuisance if driver support is non-existent for newer Windows releases. While built in drivers within Windows 7 and Windows 8 are better than they ever were, the same rule of thumb still applies: the older the hardware, the stickier the driver situation becomes. Common brands like HP and Xerox usually have an easier time than the niche brands like Ricoh and Konica due to installed user base size. If you are performing routine application compatibility testing, it only makes sense to include printers and other external hardware into that lineup as well. It's a tough sell to higher ups if you have to tack on multi thousand dollar MFC printer replacements because your testing rounds completely skipped over basics like printing.

Come up with a multi-faceted migration plan. Again, the simple items like costs and timelines are the easiest parts to get a grasp on. What's your contingency plan for systems that need to be rolled back in an emergency? How will apps that cannot be moved to 7 or 8 be supported after the migration? Will a few mission critical XP machines be allowed to stay running in a secure, locked down manner? Do you have a plan in place to deal with the inevitable influx of post-migration support calls? If you can't answer the qualitative questions on top of the quantitative ones, you clearly aren't ready to make the move.

Migrating from XP doesn't have to be a scary affair. Much of the enterprise sector has been blowing a lot of hot air about nothing, as shown in the study by Centrix. Following some simple principles related to planning and preparation can go a long way in getting your migration plans off the ground.

So ... What About Those Legacy Apps That Just Need XP?

My next 7 points are strictly aimed at organizations who have hit the nastiest brick wall: apps that just won't work natively under Windows 7 or 8. As much as we would all prefer an ideal world with a post-XP workforce running all necessary apps without any crutches, this is not always an option. Instead of holding back your entire migration off XP indefinitely, here are seven solid options you have for safely making the move off XP while retaining application support for the programs critical to your business.

I have ranked my options in order of real-world preference. Mind you, I have not personally used all of these in the wild with customers, but I have done enough research on all of them to make an educated recommendation on their merits and viability. My favorite picks are at the top, moving downward respectively. The bottom of the list are as last resort of options as I can recommend -- and I am merely mentioning them for sake of covering all available bases.

1) Use VLANs, or complete network disconnection, for limited numbers of XP machines

Of all the options I am providing, this is probably both the easiest to implement and also the fastest to take down. It usually also requires zero investment in hardware or software, unless your current switches don't have VLAN capability. But if the rest of your organization is able to make a brisk move from Windows XP to Windows 8.1, for example, and just a few systems need to keep XP for some stickler legacy apps, using network segregation techniques are completely viable options.

Ideally, if these select systems require no interaction with the internet or internal network, then just unplugging them and leaving them in an indefinite state of disconnect is not a bad option. Of course, this isn't doable for everyone. Much of the enterprise world today is running legacy apps that need either supporting internal network resources or the internet. In these instances, use VLANs in combination with firewall rules to either block them off from the rest of the internal network, or conversely, just give them controlled access to specific resources while cutting off internet completely.

This allows for select machines to stay functional in their own self-induced quarantines while your organization either sunsets usage of the given apps, or works towards finding sensible replacements that run on newer host operating systems. This route also subliminally allows for the IT department to wean users off these dinosaur machines and applications faster because their usability now comes with numerous restrictions that didn't used to exist. The business case for finding replacement apps is accelerated and kept on the forefront, instead of allowing this "island of XP" to continue operating forever.

This approach is definitely not without a time and potential hardware cost investment, but if the IT department knows that there will need to be widespread support of XP applications for a long(er) period of time, you might as well centralize the dinosaurs onto a single, easy to manage server. Unlike the above scenario, which merely keeps the old XP physical machines functioning as normal, albeit quarantined, this approach allows you to dump the old hardware and have users connect to their legacy desktops over ubiquitous Remote Desktop. And also unlike physical machines, which could have more emotion tied to them when the hammer needs to come down, virtualized boxes cut the umbilical cord between the user and their desktop - reducing political friction when XP goes away at some point down the road.

You can easily accomplish this with some elbow grease and a spare, leftover server. Type 1 hypervisors do not require much at all in terms of hardware. My hypervisor of choice is Hyper-V Server, which is completely free from Microsoft. While version 2012 is the latest one available right now, I've already begun working on my company's own internal production lab within Hyper-V Server 2012 R2 (available already to MSDN/TechNet subscribers). GA for the final version is October 18 along with the rest of the Windows 8.1 refresh line coming out.

I don't have anything particular against VMWare's competing product, ESXi, but my foray into production-level virtualization started in Hyper-V and I feel comfortable with the product. While I have only used Hyper-V in the field within a Type 2 scenario thus far (where Hyper-V runs as a service on top of a standard Server 2012 install) the product is stable as heck and "just works."

Hyper-V has supported running XP as a guest OS since 2008. Centralizing your XP VHD images on a FREE Hyper-V 2012 R2 server is an excellent way to consolidate your virtualization efforts as a stopgap until your legacy apps are fully moved. My company FireLogic already has customers using Hyper-V for mission-critical needs without any issues. VMWare isn't the only player in town anymore. (Image Source: TechNet Blogs)

Plus, the system requirements for Hyper-V Server 2012 R2 are the same as those of the non-R2 release, which are reasonably lower than what ESXi requires. Microsoft only asks that your processor have a speed of 1.4GHz, be 64 bit capable, have hardware DEP, and have either Intel or AMD virtualization tech (Intel VT or AMD-V, respectively). On the memory front, 512MB is the bare minimum.

VMWare allows for no less than 2GB of RAM for ESXi, but introduces extra requirements including that your CPU must be at least a dual core unit, and that your CPU supports LAHF or SAHF instruction sets (items which are not that common yet on servers). In fact, VMWare has a whole compatibility guide available online which can tell you if your hardware is good enough to host ESXi 5.1 or not. I personally think Microsoft's approach on Hyper-V Server 2012/R2 is a bit more forgiving, and therefore it gets my nod of support over that of the stringent, albeit also well developed, VMWare ESXi.

Setting up a Hyper-V 2012 R2 server is only half the battle. Now that you have your backbone in place, you need to actually go through the process of capturing virtual disks that contain the bits from any XP machines you wish to provide an afterlife for. These images can be easily captured with a free tool from Microsoft called Disk2VHD which converts a physical Windows installation into an encapsulated virtual hard drive file known as a VHD. This blog post goes over the process with enough detail to point you in the right direction.

Windows XP can be a bit picky sometimes, so you may not be successful on the first attempt, and some fine tuning may be needed both on the re-activation front as well as keeping Windows XP's dreaded HAL requirements in check. And before anyone barks at me for suggesting widespread conspiracy to break OEM licensing policy from Microsoft on XP, mind you the purpose of this Hyper-V option is meant to serve as temporary stopgap before retiring all vestiges of XP. I am NOT recommending this as a long term alternative to finding software which works natively on Windows 7 or 8. So take my advice with that stipulation in full focus.

I have not tested such a setup in production yet, as my customers have been able to make clean transitions off XP, but I see no reason why this wouldn't work well. This is really no different than using Hyper-V on a local leve., per machine -- we're merely consolidating the efforts onto a single workhorse so IT can pull the plug swiftly as soon as XP can ride into the sunset.

One word of advice: The easiest way to manage a Hyper-V server happens to have one of the most unintuitive setup processes in Microsoft history. I am not sure why such an excellent product has an overwhelming number of steps necessary in order to establish remote management. In a nutshell, if you want to use the awesome native Hyper-V Manager built into Windows 8/8.1, you need to follow some arcane steps first. But it's well worth the hassle; you can then manage your Hyper-V server from Starbucks or at home without restrictions (given you have VPN connectivity, of course) within an easy to use GUI.

If you don't have the hardware muscle or need to setup a centralized Hyper-V server as discussed above, you can replicate the same functionality on a local PC level. Options are aplenty these days, and all of them have their pros and cons.

If your users will be on Windows 7 Pro or Enterprise after the migration, a perfectly viable and relatively easy option to setup is Windows XP Mode. Microsoft included this nugget in Windows 7 to tide over the initial wave of XP refugees a few years back, and while the tech powering the functionality is aging -- in the form of Virtual PC actually behind the scenes -- the solution works great as a short term solution.

Windows 8 Pro and higher users have a little more legwork to go through, but similar usage can be accomplished through Hyper-V. One benefit that XP Mode provides over the newer Hyper-V option is that Microsoft includes a free Windows XP license with every copy of Win 7 or Enterprise that can be used in Windows XP Mode. Hyper-V users on Windows 8 need to "bring their own license" which, if you are converting old boxes into temporary VMs for users, may not be that much of a concern anyway. Just something I wanted to mention.

Of course, if you don't trust the first party Microsoft solutions, there are always two other great alternatives as well: VirtualBox and VMWare Workstation. Oracle provides the first option as an open source offering, and VMWare Workstation is a paid product from VMWare (that is quite powerful). But again, if your needs for XP virtualization are short term, I would shy away from suggesting heavy investment in supporting technology for our stopgap measures.

A lot of online blogs mention the use of VMWare's free VMPlayer product as a freebie alternative to the paid Workstation product, but keep in mind this product is not meant for commercial usage in any way. Either pay for Workstation or just use one of the other numerous free (albeit still excellent) options.

If I were handling a conversion on a limited scale for just a few users, I would be using Windows XP Mode on Windows 7 boxes, or naturally Hyper-V in Windows 8. If you are doing physical to virtual conversions for Windows 7 users, then VirtualBox may be the best free option.

MED-V is a very neat technology that Microsoft offers, targeted at organizations who definitely have longer term plans on keeping XP legacy applications going. This approach without a doubt has as much, if not more, effort necessary than our Hyper-V server option from earlier, but in the end it does create perhaps the cleanest end user experience on many fronts. For starters, users do not have to remote into true XP VMs to get their work done. If you have any idea of what the power of RemoteApp provides, then you have a notion for what MED-V offers specifically for legacy apps.

The purpose of this tech is to allow end users to get their legacy applications streamed to them at their Windows 7 desktops. The applications are seamless and work just like any other program. Shortcuts can be placed on the desktop; programs can be moved around without the harness of being bubbled into a VM; etc. But Microsoft has made it very clear that MED-V is not being updated to work with Windows 8, and in no way does using MED-V extend your support for XP after EOL. MED-V is a beautifully crafted stopgap for Windows 7 users -- but Microsoft is stern on not allowing this to become the next XP lifeboat forever. Organizations should still clearly be making efforts to get off legacy apps in parallel with deploying MED-V.

When's the last time you saw IE6 running side-by-side next to IE9? Microsoft's MED-V technology allows for these types of frankenstein scenarios in the spirit of easing legacy app pains. It's not geared towards smaller organizations, and cannot be used on Windows 8 sadly, but larger enterprises on Windows 7 may find a niche for this cool tech. Watch the video of how it works to see for yourself. (Image Source: TechNet Blogs)

I have not deployed a MED-V install for any clients yet, and likely won't be pushing the option for the small to midsize realm anyway. Not only does it require significant time and effort to get running, but it's also only available to customers on Enterprise Agreements with Microsoft; something organizations I work with rarely if ever can afford.

As a proof of concept, I highly recommend you check out this demonstration and in-depth dive into MED-V from TechEd 2011 as it provides a much better insight into the tech (and end user experience) than just reading about it conceptually.

5) Legacy IE6/IE7 Apps Still Lurking? Browsium to the Rescue

For organizations that merely have legacy apps running within IE6 or IE7, a company called Browsium is offering an innovative solution to get those apps working within newer IE releases. The product is called Browsium Ion, and is a platform for leveraging legacy IE apps within newer versions of IE without the need to run full XP desktops in order to handle the applications' legacy needs.

The software tool promises that no new infrastructure or PC upgrades are needed, which is a convincing pitch for companies who are otherwise deadlocked against moving off of XP for their client OS situation. Think of it as IETab for newer versions of Internet Explorer in Windows 7/8, but this time, it's for the sole purpose of providing legacy backwards compatibility for the browser only.

I have never tested the product in the field, nor do I know any colleagues who are on the program. But the product has been discussed in more than enough respected blog posts online for it to get a conditional nod of approval as an option. If anyone is using the program for their legacy needs, we would love to get your comments below.

6) Call in the Big Guns - Dell Migration Services or Toshiba VDS

While smaller IT shops like mine can serve the 50 and unders quite easily, if your organization fits the description of a "large business" or greater, you may need some heavy artillery to come in for a helping hand. If your internal IT team isn't big enough, experienced enough, or more likely - doesn't have the time to work on a migration - then options Dell and Toshiba are presenting seem like excellent alternative to insourcing the migration headache.

Dell knows the enterprise well, and they have been touting their migration consulting services option for a little while now. For organizations with up to 5000 machines, Dell is willing to come in and help handle everything from the planning to app testing to image building, and in the end cut down time necessary to move by a fair margin.

Another competitor offering a slightly different approach to migration is Toshiba, which just started advertising their Virtual Desktop Service platform. While all of the details of their offering is not entirely in the wild, it seems that they are not going to reinvent the wheel in any way. Toshiba plans on piggybacking onto Citrix or VMWare powered solutions to bring packaged VDI into the hands of enterprises that otherwise don't have the expertise to handle it internally.

I also poked my head into the speculative debate surrounding Microsoft's first party foray into the DaaS (Desktop as a Service) market, but this still-secret 'Mohoro' program is anything but reality yet. If Redmond can lift the curtain off this program early and offer a potentially solid Azure-backed platform for hosted VDI, Citrix and VMWare will likely see some nice competition in a market they have a large strangle on right now.

For the immediate future, however, Dell and Toshiba are solid bets for third party consulting help. With something as massive as a migration off XP, sometimes calling in the experts is a worthy investment. This way you can carefully craft an approach to keeping any XP lifelines going without sacrificing the entire rest of your workforce moving over to Windows 7 or 8.

7) Microsoft Custom Support: An Expensive Lifeline for Staying on XP

This option is relegated to the bottom of the list, and if I had more choices, I would have preferred to place it around option 9 or 10 -- perhaps lower. This is because while in reality, yes, you can pay Microsoft oodles of money to keep supporting your XP lifestyle after April 2014, most companies outside of the Fortune 500 probably can't afford to do so.

This elite support tier from Microsoft, bundled in with its Premier level of customer service, comes at a disgustingly steep premium which is rumored to cost about $200 per device, and that's only for the first year of coverage. Multiply that times however many systems your organization may support, and you start to get an idea for how grim such numbers become. But hey, if you've got the deep pockets, Microsoft has no problem giving you the fallback you may need.

Would I recommend this to an organization as a primary means of life after XP? Absolutely not. Unless it was the best of a bad set of options to begin with. I'm sure there are corporations out there who are gladly paying these sums to Microsoft in order to give them another 1-2 or more years of breathing room on XP, but I would rather invest the money into ridding my organization of the legacy apps in exchange for viable replacements.

Whichever Route You Decide to Go: Do Your Homework

No matter which option, or hybrid of options, are most sensible for your organization's needs, I can't stress enough that proper forethought is the best medicine against stepping two feet first into a nightmare. Migrations are not an easy affair, which is why smaller organizations call upon companies like mine to lend a hand in the process. From hardware testing to application compatibility down to timelines and budgets, the move from XP is anything but a walk in the park.

However, I'm hoping that having seven solid options as per above at least provides a sound baseline for where your organization should be headed. Ideally, a post-XP world calls for a complete flushing of legacy technology to keep business running. But realistically, this isn't always an option. And luckily there are a bevy of directions you can go in order to provide that stopgap until XP can be fully and cleanly killed off at your organization.

Are you using an XP virtualization strategy that I didn't cover above? Do you have any positive or negative experience with any of the options I wrote about? We would all love to hear about them. Moving off XP is nothing short of a collective learning process, and it's important to hear from IT pros in the field so that the same mistakes aren't repeated perpetually. Best of luck in your own XP migration adventures!

Derrick Wlodarz is an IT Specialist who owns Park Ridge, IL (USA) based technology consulting & service company FireLogic, with over eight+ years of IT experience in the private and public sectors. He holds numerous technical credentials from Microsoft, Google, and CompTIA and specializes in consulting customers on growing hot technologies such as Office 365, Google Apps, cloud-hosted VoIP, among others. Derrick is an active member of CompTIA's Subject Matter Expert Technical Advisory Council that shapes the future of CompTIA exams across the world. You can reach him at derrick at wlodarz dot net.