On July 14 Microsoft will terminate extended support for Windows Server 2003. This means that there will be "no more patches fixing security vulnerabilities, non-security defects," etc. If Windows Server 2003 and the applications running on it play a critical role in your infrastructure, you need to start migrating to a new server platform now (if you haven't already).
While migration begins with the physical or virtual server and the operating system, it doesn't stop there. Ensuring a smooth upgrade path for applications will minimize downtime. It's important to understand the ramifications of migration up and down the stack, from operating system to database to application to Web front end. There are plenty of places to break the stack during migration, so careful planning and testing are requirements that need to be built into your project timeline.
Here's a brief overview of the migration process:
1. Discover–catalog your software and workloads
2. Assess–categorize applications and workloads (and dependencies)
3. Target–identify destinations and migration paths
4.Migrate, Upgrade, and Test–make the move, then ensure it's all working
No matter your workload, upgrading and migrating is not going to be straightforward. You can't upgrade the underlying operating system without upgrading the application. Chances are you won't be able to download a migration tool that will automate everything for you. Some vendors have tools that help, but none of them automate it all for you. Whether you're running Exchange, SharePoint, SQL Server, other Microsoft applications, or third-party apps, this is going to be a planning-intensive and time-consuming process.
A great place to start is Microsoft's Windows Server 2003 Migration Planning Assistant, which will guide you through the four major steps listed above. There's also the Microsoft Assessment and Planning Toolkit (MAP) for Windows Server 2003 and SQL Server 2005 migration (the latter reaches end of support on April 12, 2016). MAP will also discover third-party applications to get you started on migrating those as well.
This is a very good time to rethink your systems architecture. As far as migrating Exchange, SharePoint, and SQL Server, you could move to another physical Windows Server, a virtual Windows Server, or a combination of cloud services. You may want to partially move to the cloud (or fully) with Microsoft Azure and Office 365 or with some other provider. You may want to consolidate multiple physical servers as virtual machines running on a single physical server. As far as which software version to purchase, it's best to consider upgrading to the newest version of everything, for example, choose Windows Server 2012 R2 over Windows Server 2008 R2, if only to maximize the time that will pass before you have to go through this again.
It's Tricky
The migration path gets tricky with third-party and custom applications. Assessment needs to begin by understanding the value of the application, especially how critical it is to the smooth functioning of the business. What remediation options are available and how simple are they? Knowing how migrating an application will affect the business is a critical component of the decision making process. Plus, it isn't just about each individual application, it's also about the relationships between them. And since we're talking about applications that may have been in place since 2003, it may be difficult to find some of these answers. Understanding the applications you're running and how they integrate will go a long way toward a smooth migration.
The most important thing to understand about third-party and custom applications is that you'll need to determine if they will run on your next server. For example, if the application is a 32-bit application without any 16-bit code or reliance on 16-bit drivers, then it is likely that it will run on Windows Server 2012 R2. If it does run, does the vendor support the application on Windows Server 2012 R2? If it is supported, do you have the installation packages and the knowledge to perform a reinstall and data migration? If the vendor doesn't support running the 32-bit application on Windows Server 2012 R2, then you'll have to upgrade or find an alternative.
There are a few third party tools such as AppZero and Vision Software that can help migrate third-party and custom applications. AppZero identifies, extracts, and moves existing Windows server applications to another Windows server, either in your datacenter (physical or virtual) or in the cloud. Vision Software performs a near-zero downtime migration of applications and data to another physical or virtual server, capturing all changes users make during migration and replicating them to the new server.
Conclusion
Upgrading and migrating applications is going to be much more difficult than merely upgrading to a new version of Windows Server. The more complex your environment, the more complex your code base is likely to be, and the more difficult this process will be. This is where careful planning and testing is mandatory in order to avoid breaking business-critical applications. Understanding the apps themselves, their dependencies on other applications, on a database back-end, and on system components is critical. Prepare yourself for the unthinkable – you may not be able to migrate some code and it may have to be rewritten.
For more, see the first three parts of this series: The Procrastinator's Guide to Windows Server 2003 Migration, Windows Server 2003 Migration Guide: Choosing a Replacement OS, and Why You Should (or Shouldn't) Make the Move From Windows Server 2003.