Anyone who has tried to move applications by hand knows it’s hard. There are many reasons why, as follows.
Applications are installed on a version of a Windows operating system (e.g., Windows Server 2008) using install scripts. The scripts distribute the EXE files, drivers, and other application artifacts across the library and directory structure. Applications change over time. They get new features and patches, integrations, and new applications are added to the stack. Application owners and developers leave, install scripts are lost or not maintained, and run-books get out of date. Eventually, an application needs to move to a modern server. There are many reasons to move an app, such as a datacenter move or moving to the cloud.
How do you move apps?
If the OS stays at the same release level, engineers might try to migrate using P2V tools. But the application stack needs to run on a new OS instance, and the rework involved in P2V reconfiguration can make it seem faster to re-install applications by hand.
Even if the OS release level stays the same, IT may not want to move all the applications running on an OS to a new server. Apps can have problems running on new servers, and when you move to modern OS instances, they can be even more troublesome.
What makes moving applications by hand difficult?
Moving applications by hand involves several steps, which means that projects can take months to plan, execute, and test:
- Re-installing applications on new servers (with or without original install scripts)
- Complex reconfiguration
- Data migration
- Testing
- Production cut over
How do you know what needs to move?
How do you determine which applications on a server need to move? Moving all the apps doesn’t work well, because some are used more than others, some may not work, and some get replaced by the new capabilities of a modern OS. Plus, not every application on a new server will appear on the Add/Remove Programs list. If install scripts are missing and IT lacks knowledge about applications on a server, re-installation can seem daunting.
When you move old applications to new servers, you shouldn’t move all their clutter. You should move only required applications and workloads, but it’s hard to determine which apps are important and the computing resources they need. Often, IT support spends time and effort trying to make applications work on new servers when they didn’t work properly on the old server.
How does it all work together?
Even if IT knows the core applications on a server, they may not know their dependencies and artifacts. The applications were probably installed on a server and distributed across the directory structure in a complex way. Without documentation, it’s difficult to know what belongs to an application and needs to move too, and how it all needs to move to work correctly. Using trial and error troubleshooting is painstaking and risky.
So much reconfiguration
Moving applications involves reconfiguration. You’ll need to reconfigure IP addresses, network connections, drive mappings, and database connections. You may need to modify or replace peripheral drivers to support physical hardware. Server names and the number/types of network interface controllers often change. Application licensing might be tied to hardware IDs. You need to move user profiles and privileges and upgrade stack components like databases and web servers. Doing this manually is tedious and error prone.
So much time
Moving applications by hand requires lots of time for planning and testing the results of the move. The reconfiguration and rework can make it challenging to sync with original production servers during a maintenance window.
The more complex a migration project is, the more likely it is to encounter wait states and delays.
A technical team may eventually manage to re-install applications on a new server and OS, but a few hand moves later, they’ll want to find a way to make application moves faster and easier.
You don’t need to move applications by hand
Using automated migration software to move applications from legacy servers saves over 80% of the time and over 70% of the cost compared to manual migration. VirtaMove intelligent migration software automatically discovers apps across your network, and then packages them and all their components and dependencies into a container on the new destination server. The containerized application is isolated from the underlying operating system and is portable.
The container can be removed at the end of the migration. When the container is removed, the app is re-installed on the new destination server. It runs natively on a modern OS, with all its configuration, patches, and upgrades.
Reconfiguration can be done dynamically and automatically. You can roll out thoughtfully as and where required, and step snapshots allow you to roll back just as easily.
Give us a call, register for a free demo, or send us an e-mail. We’d love to show you what we can do.