How to transfer applications from one Windows Server to another, including Server 2003, Server 2008, Server 2012

In this tutorial, we’ll learn how to perform Windows Application Server migration, and transfer applications from old server to another new server. This tutorial works for Server 2003, Server 2008, Server 2012, Server 2016 and even Server 2019. Transfer can be physical-to-physical (P2P), physical-to-virtual (P2V), virtual-to-virtual (V2V), as well as transfer to Cloud servers.

The goal of this tutorial is to copy server applications to the new server completely, and generically: any application, even custom or in-house applications, will be moved to the new server, including their configurations, databases and of course files.

Note that the transfer we are doing is native transfer. The applications are really transferred to the new server, becoming installed on it, and retaining their configurations. This does not rely on any containerization or app virtualization processes, and delivers true, native migration.

The tutorial is below, and before that – a video tutorial and a few common questions about Windows Server migration.

Windows Server application migration

Q: Does this work for 2003 as well?

A: Yes. Using a product such as WinServ, you can automatically transfer all applications, profiles, shares and data to a replacement server 2008 or 2012. 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. Of course, the same transfer works for transfers from 2008 to 2012 or from 2012 to 2019.

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:

• MS SQL
• MySQL
• SAP (including SAP Business One)
• Oracle
• Sybase
• DB2
• Java Application Server
• Crystal Reports
• Avaya
• PeopleSoft
• JD Edwards Enterprise One (JDE E1)
• Citrix
• Apache (Windows only)
• WebSphere
• Microsoft Dynamics

How to perform application server migration to a new Windows server

Before the migration:

1. 1. Audit your servers: Make sure you know what the server is responsible for. Which applications are running on the server? (SQL? CRM? Oracle? Other 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.

2. 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.
3. 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!
4. 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 or 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.

Video tutorial – Windows Server application migration

Applications, profiles, shares and data migration

Here is the process for performing a migration for one Windows server to another:

1. Fully update and patch the target server.
2. Add the target server to the domain.
3. Run WinServ on the source server and on the target server.
4. 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.
5. 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.
6. 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.

Dealing with incompatible applications:

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 operation 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.

1. 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.
2. Same goes for login scripts and GPO policy.
3. Launch every application and console you use, and verify they load correctly.
4. 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.