How to migrate applications, data, settings and profiles from Windows Server 2003 to Server 2012 / 2016 (or 2008)
Windows Server 2003 support has ended on July 14, 2015. If you still have 2003 servers in your environment, now is the time to get rid of them – migrating to newer 2008, 2012 or 2016.
Since 2003 servers are quite old, and since there is no direct upgrade path from Server 2003 to Server 2012 or 2016, the recommended way to eliminate Server 2003 is to transfer to new hardware – not an in-place upgrade.
In this article, we’ll learn how to perform a Windows Server Migration for a typical application server, while making sure no applications or files are lost in the process.
Using this tutorial generally allows to complete a server migration in less than 24 hours (although complicated cases may require more time).
The tutorial is below, and before that – a video tutorial and a few common questions about Windows Server 2003 EOL and migration.
The tool used in this this tutorial – Zinstall WinServ – is also available from IBM Services, as part of their full service package for large scale deployments. Contact your IBM account team in your region for more information.
Video tutorial – automatic server migration
Q: Can I transfer the applications I am currently running on Windows Server 2003 to a new Server 2012 / 2016?
A: Yes. Using a product such as WinServ, you can automatically transfer all applications, profiles, shares and data to a replacement server 2012 / 2016. Note that a small part of legacy 2003 applications may not be natively compatible with newer servers. For those, the WinServ package can perform a virtualized migration.
Q: What if my applications are no longer supported, or I no longer have the installation discs?
A: Even if you have no way to install your applications on the new server, you can still transfer them from the old one – using a dedicated migration tool, such as the WinServ package discussed in this tutorial. WinServ is application-generic, and here is a partial list of what it migrates:
SAP (including SAP Business One)
Java Application Server
JD Edwards Enterprise One (JDE E1)
Apache (Windows only)
Q: What happens if I just stay with Windows Server 2003 after July 14, 2015?
A: It won’t explode. However, Microsoft will no longer provide support, and will charge up to $600 per incident if you do ask them for assistance.
Q: What are the benefits of transferring away from Windows Server 2003?
A: A new server is incomparably more secure and more powerful than the old one you’ve had running for many years. It can utilize more than 4GB of memory, which means that a much higher load can be put on a single physical machine, including virtualized server. Along with the security aspect of up-to-date OS, overall performance is expected to be much better.
How to migrate from Windows Server 2003 to Windows Server 2008 / 2012 / 2016
This tutorial is divided into two primary sections, representing the two types of migration tasks on any server: 1) Applications, profiles, shares and data migration and 2) Server Roles migration.
The first part can be automated using dedicated server migration tools such as WinServ, as we will show in the tutorial. The second part requires manual work, for which guidance will be provided – or hiring a service that performs that.
For an application server, you only need the first part.
Before the migration:
Audit your servers: Make sure you know what the server is responsible for. You need to make two lists:
Which roles is the server running (is it a DC? Does it run DNS/DHCP? IIS? Print?). For roles migration, the only way is a manual migration, or a Server Migration service. In this tutorial, we’ll focus on automatic migration of server applications.
Which applications are running on the server? (Oracle? SQL? CRM? 3rd party applications?). These can be migrated automatically using an appropriate tool, which will be covered further in this tutorial.
Tip: If your organization is not using a centralized management tool (e.g. Microsoft SCCM) to monitor your servers, you can download the free Microsoft Assessment and Planning (MAP) Toolkit here. You can also use Zinstall’s free server diagnostic at this link. It allows for quick check-up of server’s entire software and hardware list.
Schedule your migration time slot: Migrations take time, and during that time, your users may be affected to some extent. If possible, try and schedule the actual migration to be performed after hours or during a weekend. Note that you don’t actually have to stay there yourself at that time: application migration can be performed remotely or launched in advance in unattended mode.
Verify your backups are up to date, and are actually restorable: Any major upgrade may go wrong, and without a valid up-to-date backup, you risk losing everything you’ve had on the server. Make sure to verify that the backup you have is not damaged and ready to be restored if needed!
Decide on replacement type: Once you have decided to replace a server, you have several options regarding what the replacement will be. It may be a physical Windows 2012 / 2016 server, a virtual server running on premise, or even a Cloud-based server running off premise. WinServ supports any of those transfers, so migration difficulty does not vary significantly with your choice.
Applications, profiles, shares and data migration
Here is the process for performing a migration for a source Windows 2003 Application Server to a target Server 2012 / 2016:
Fully update and patch the target server.
Add the target server to the domain.
Run WinServ (or a similar tool) on the source (2003) server and on the target (2012 or 2016) server.
At this stage, you can either transfer directly over the network, or perform an indirect migration – capturing the source server to a container on network storage / cloud storage, and then deploying from that container on the new server.
Before you start the transfer, you also have an option to pick and choose applications and data that you want to transfer. Or, just run the transfer to migrate everything.
Press “Go” on the target server in order to initiate the transfer.
Depending on the amount of transferred data and applications, the actual transfer may take several hours to complete. You will see progress indication throughout the process.
IIS migration: If all you have running on IIS 6 are basic HTML pages or Active Server Pages (ASP), you can copy the content to the IIS version running on Server 2012 or Server 2012 R2, then update the DNS records to point to the new IIS server. However, organizations typically have more complex configurations. The good news is that you can use a migration toolkit named Web Deploy 3.6. If you need to migrate websites to Microsoft Azure Web apps, see Azure Web App Migration Assistant.
DC and AD migration: Providing you have followed best practices, your domain controllers (DCs) don’t run any other software, which means the existing domain and forest will be prepared for Server 2012 or Server 2012 R2. In this case, you need to create new DCs running Server 2012 or Server 2012 R2, migrate the Flexible Single-Master Operation (FSMO) roles, migrate any certificates or other items, then decommission the Server 2003 DCs. To introduce Server 2012 DCs, the forest (and therefore the domains) must be Windows Server 2003 mode. For detailed guidance on migrating DCs, see Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012.
DHCP migration: DHCP scopes provide the IP addresses given to clients, along with their IP configuration (e.g., gateway, DNS server). To migrate DHCP scopes, the best option is to export the scopes from the Server 2003 instance, then import them to the Server 2012 or Server 2012 R2 instance. Full details on this approach are available in the TechNet Networking Blog post “Steps to move a DHCP database from a Windows Server 2003 or 2008 to another Windows Server 2008 machine.” If there is any delay in the DHCP scope export and import and a risk of IP address reuse, you can configure the DHCP server to check if an IP address is being used before it’s allocated by enabling address conflict detection.
DNS migration: If you’re hosting DNS on Windows, you’re likely integrating it with AD and your DNS servers are DCs. Therefore, when you migrate AD, the DNS configuration will move as well. It’s important to remember to migrate any DNS server configurations, such as forwarding. If the DNS servers will be hosted on new IP addresses, you need to make sure that you update any static IP configurations and all DHCP configurations. To avoid this time-consuming task, most organizations will change the IP addresses of the new servers to that of the old servers once the old servers are retired.
Print services: Like file services, printer configurations and shares must be migrated from the source server to the target server. In addition, you’ll need new printer drivers that are 64-bit and compatible with Server 2012 or Server 2012 R2 as well as with modern clients. Microsoft has a print migration wizard and command-line tool you can use for migrating printer services. You can download these tools from the Migrate Print and Document Services to Windows Server 2012 web page.
Some legacy 3rd party applications running on Windows Server 2003 may be incompatible with Windows Server 2008 or Windows Server 2012. Such applications are generally legacy DOS, 16-bit or 32-bit only software, which has not been updated for newer OS versions. It is strongly recommended to eliminate these applications from the production environment as soon as possible.
If these applications cannot be eliminated immediately, and are mission-critical for continued operation of the organization, the recommended option to preserve them operational is to perform a virtualized migration of those applications, into a virtual Server 2003 instance running on newer replacement server. Then, continue to take the steps required to phase those applications out and stop running the virtualized 2003 instances.
Such P2V (physical to virtual) migration should be done using WinServ as well.
After the migration:
Once the migration process is complete, it is time to verify the results.
You may need to adjust your domain’s DNS to point to the new server where needed. For example, changing the CRM-SERVER DNS entry to the new server’s address.
Same goes for login scripts and GPO policy.
Launch every application and console you use, and verify they load correctly.
Using a client workstation, verify that clients can access the migrated server correctly and their applications run without issues.
Congratulations! Your application server migration is now complete.
Ready to migrate your Windows 2003 servers to 2016/2019?