When migrating your Windows Server 2003 to something more current, you must identify a migration destination for each application and workload. After you’ve gone through the assess phase of the migration process, you should have a catalog of everything that needs to be migrated and its priority in the migration process. Now you must point each application and workflow to its new destination.
There are four possible destinations for migration:
- Windows Server 2012 R2
- Microsoft Azure
- Cloud OS Network
- Office 365
Different workloads and applications will lead to certain targets, while others can lead to a possibility of one or more of these destinations. The choice will be driven by factors such as speed and ease of migration, cost, and functionality.
There are five key server roles to consider for migration from Windows Server 2003/R2:
- File Server
- Web Server
- Active Directory
- Domain Controller
- Terminal Services
Server roles range from very easy to migrate, like file servers, to potentially difficult ones, like active directory migration scenarios. Only a thorough analysis of what exists today and the desired end state will show exactly what effort is needed to migrate these roles off Windows Server 2003/R2.
For file servers, migrate the data to supported file servers like Windows Server 2012 R2, or to a cloud solution like Azure. If you are migrating on premises and running any hypervisor besides Hyper-V, we recommend a migration to Hyper-V at the same time. Hyper-V, a leading enterprise-level hypervisor, is free with Windows Server 2012 R2.
For web servers and terminal services, migrate to Windows Server 2012 R2 running either on premises (note the need for new hardware and the possibility of virtualization) or to Azure.
For active directory, you can migrate to Windows Server 2012, but you should also consider Azure Active Directory and federation or synchronization. Active Directory has advanced substantially since 2003, and you will need to spend some time planning an Active Directory migration if you are still running Active Directory on a Windows Server 2003/R2 infrastructure.
It’s important to note than on-premises supports the full Microsoft Virtual Desktop Infrastructure (VDI), whereas Azure supports Session Host running Remote Desktop Services.
Migrating Non-Web Applications
Windows Server 2003 may also be acting as a server for your non-web applications using .NET, Java, or native platforms. Migration options start with a straight migration to Windows Server 2012 R2 running physical, virtualized, or on Microsoft Azure Virtual Machines IaaS service. Other options include rewriting all or part of the application to take advantage of Microsoft Azure PaaS (Platform as a Service) capabilities or to identify a vendor providing equivalent capabilities in their application offered as a SaaS (Software as a Service).
Custom and third-party applications can be migrated to Windows Server 2012 R2 running either on-premises or on Azure IaaS. You can also potentially migrate to the Azure PaaS offering or to a SaaS replacement for the application. Third-party and custom applications both have similar considerations.
Migrating Third Party Applications
Third-party applications are most likely to be run on-premises. Too many factors exist out of the control of the providers of IaaS solutions for them to support these applications.
Some third-party application vendors also offer SaaS options for their products, which is potentially the fastest and easiest option for migration. Microsoft Azure also offers the ability, through the Certified for Microsoft Azure program, for independent software vendors (ISVs) to certify their applications to run as SaaS offerings on Microsoft Azure.
If you are stuck with a critical application that only runs on Windows Server 2003/R2 and the third-party ISV is still in business, there may be another option. Microsoft recently introduced the ISV Upgrade Campaign. You can explore whether this campaign can help the ISV update the application to run on Windows Server 2012 R2.
Migrating Custom Applications
Custom applications are potentially among the most complex migration scenarios (they can also be the most simple migration scenarios—it depends entirely on the application). They should be reduced in number as much as possible during the discovery and assess cycles. The following are two options:
- Custom applications have a reputation for being poorly documented, which can make them economically unfeasible to update. They may need to be rewritten if there is not a packaged application or service that provides the same functionality and can serve as a migration target.
- One final consideration with custom applications is to virtualize them. On-premises or IaaS (especially Microsoft Azure IaaS) virtualization may enable you to focus on application updates instead of dividing attention between that and the underlying infrastructure when updating the application.
To consider an on-premises migration, you will need to consider which version of Exchange Server you have and if that version will run on Windows Server 2012 R2. You may also want to consider updating Exchange Server itself because substantial new features have been added and improvements made to Exchange Server over the years, including architectural changes for Exchange deployments.
This new architecture, as well as the overall sophistication of Exchange Server, requires planning to achieve the best results. An Exchange Server deployment is not trivial, and planning one requires both infrastructure and Exchange Server expertise. For an Exchange Server on-premises deployment, note that virtualizing Exchange Server is not considered an Exchange Server best practice.
Although targeting new locations for everything in your server may seem tedious, it is much easier to make critical decisions about where and how to move complex applications during the planning phases than during the migration phase.
The next phase of the migration process is the actual migration phase.