The Complete Guide to Windows Server 2003 End of Support
Phase II: Planning
Now that you’ve identifed your Windows Server 2003 systems and collected pertinent information about them, you can more accurately plan how to migrate them. If you have many systems that need to be migrated, the process can become quickly complicated. I’ve provided a checklist below to help you organize the planning phase. You may not need all of these checklist items for your own Windows Server 2003 migration, but you’ll have at least examined all the major facets of a migration by looking through this list and crossing off items that aren’t relevant. And just maybe you’ll encounter some items you haven’t thought about.
Hardware upgrade planning
Next, review new hardware technologies. In all likelihood, your Windows Server 2003 systems are physical, and you should be migrating to virtual machines (VMs). If you don’t have an existing virtualization environment to host the VMs, then this is the time to start one. Even if you have an existing virtualization infrastructure, it’s still important to examine what Windows Server 2012 / R2 capabilities require new hardware technologies (for example, RDMA). By going through this process, the hardware will be there to support new technologies when you’re ready to turn on new features.
Be sure to include hardware deployment lead time into your project plan. Remember that hardware is unlike software, where it requires significant lead time for spec’ing out, purchasing, shipping, powering, networking, and more.
Base operating system upgrade planning
This part of the planning phase is where you’ll determine migration paths. The single most important rule to keep in mind for this migration is that Windows Server 2003 is Microsoft’s last 32-bit server operating system. Upgrades from Windows Server 2003 to Windows Server 2008 and 2008 R2 are supported, but upgrades to Windows Server 2012 / R2 are not. If you’re contemplating upgrading from 2003 to 2008 because it’s easier, keep this in mind: Windows Server 2008 R2 has already exited mainstream support in January of this year. If you’re going to the trouble of moving forward, go all the way forward and take advantage of what the latest technology has to offer. If you take my recommendation and migrate to Windows Server 2012 R2, then you must reinstall applications on the target system.
A couple of useful TechNet articles on this are:
Evaluation downloads of the currently offered Windows Server versions are also available.
Workload planning
Workloads are the roles a server is performing; we use “workloads” instead of “roles” to distinguish it from Microsoft’s technical description of a role as a function that can be installed from Server Manager. For example, a server running a SharePoint workload may have several roles installed in addition to platforms, such as SQL Server.
Determine workload end of lifecycle. First, try to simplify the migration by eliminating systems that don’t need to be migrated in the first place. Perform an impact analysis of the system and workload. How much of an impact would decommissioning the system have versus the cost of migrating and maintaining it? Can this workload simply be retired and its functions moved to another system?
Workload configurations. This is an opportunity to standardize and reduce the number of configurations you must support. Group the remaining Windows Server 2003 workload types together as much as possible into what we’ll call workload configurations. You’ll end up with several configurations, each with multiple instances, and a random collection of one-off systems.
Consider the following for each workload configuration:
Physical vs. Virtual
- Does the workload reside on a physical server? If yes, plan for P2V (physical to virtual) conversion unless there is strong technical or security data otherwise. And there probably isn’t a technical reason.
- Using the utilization data you collected in Phase I, scope the target VM for the usage the workload is getting — not the hardware it’s on now.
- There are a number of good P2V utilities available, depending on your virtualization vendor. VMware has its free vCenter Converter, and Microsoft the free Disk2VHD utility or P2V capability in System Center Virtual Machine Manager.
On premises vs. Cloud
- Should the virtualized workload remain on premises or might it be moved to the public cloud as a SaaS app? For example, there may be a good business case to move an Exchange Server 2003 installation to Exchange Online.
- Could the virtualized workload be moved to an infrastructure as a service (IaaS) offering, such as Amazon Web Services or Microsoft Azure? For the workload to continue to interact with on-premises applications, this strategy requires a VPN link to tie on premises and cloud networks together.
- If the workload was built in house, can it be re-architected as a web service running on a platform as a service (PaaS) offering, such as Microsoft Azure? This is probably a very long-term strategy.
Workload Migration Paths
Every workload or application has its own upgrade or migration path, which Figure 4 shows in more detail. Many workloads or applications are dependent on each other, so you must always keep dependencies in mind. For example, Exchange upgrades depending on Active Directory domain and forest-functional levels.
