Let’s begin at the beginning: at the start of the life cycle of a Windows Server application. Applications begin life for a specific version of the Windows operating system; for example, WS2003 or WS2008. They’re installed on a server using an install script, which distributes the EXE files, DLLs, COM components, drivers, and other application artifacts across the library and directory structure where the original application builder wanted them installed, on that specific version of Windows. Straightforward enough.
However, nothing stays the same forever. In time, new application features are added, patches occur, integrations happen. New applications are added to the stack. Application owners move on, developers leave, install scripts get lost or aren’t maintained, run-books get out of date. The passage of time leads to entropy and corporate amnesia.
In time, applications need to move to a modern server. There are many good reasons to move workloads and applications. For example, datacenter moves and consolidation, moving to virtual machines on in house servers or a cloud, upgrading servers to a secure, supported operating system, and scaling servers to deal with growth or seasonal demand.
If the operating system can stay at the same release level, engineers will often try to make the move using P2V tools or backup and recovery software. Except that P2V tools don’t work well. We’ve covered the many shortcomings of P2V approaches in earlier blogs and won’t repeat them here. Under the scenario described above, the application stack needs to run on a new OS instance, so P2V adds no value. Additionally, all the rework involved in P2V reconfiguration often makes IT support believe that it would have been faster in the end to just reinstall applications by hand.
For good reasons, IT normally doesn’t want to move all the applications running on an OS to a new server. For starters, it’s not easy, and apps can have problems running on new servers. Moving applications is a challenge, even if the OS release level doesn’t change. When applications need to move to servers running a modern OS instance, the job becomes even more troublesome.
What makes hand migration so difficult?
Moving apps by hand usually involves several steps: reinstalling applications on new servers (with or without original install scripts), which is difficult and time consuming; complex reconfiguration; data migration; testing; and production cut over.
If install scripts are missing, re-installation can seem like an impossible task, given that IT may lack knowledge about the applications on a server. Hand migrations can take months of effort to plan, execute, and test.
The first challenge: what to migrate?
The first challenge is determining which applications on a server need to move. The answer might seem obvious: just move all the apps. But that rarely works, and here’s why:
Applications get installed on servers over an extended period, some are used a lot, some are rarely used, others are never used, some may have never worked, some are replaced by new capabilities of a modern OS. Not all the applications on a new server are well behaved and show up neatly on the Add/Remove programs list. Who knows the difference? Rarely IT, and often not the application owner.
The objective of a move is not to move the clutter and chaos of all the applications on an old server to a new server. Rather, it’s to move the applications and workloads that people still need and care about. It’s not easy to do the manual detective work involved in determining which apps are important and how much computing resources they need. All too often, IT support spends a great deal of time and effort trying to make applications work on new servers – only to find out that the apps didn’t work properly on the old server in the first place.
Understanding dependencies
Even if IT knows the core applications on a server, they may not understand all the dependencies and artifacts that these applications need in order to run. Often, many different applications have been installed on a server and distributed across the directory structure in a complex way. Without complete and current documentation, it’s difficult to know exactly which EXEs, DLLs, COM components, user data, drivers, files, and artifacts belong to a specific application and need to move. Sometimes apps are interdependent and both apps need to move together to run properly. Making an app run on a new server via trial and error troubleshooting is painstaking. Not uncommonly, IT support might put in weeks effort only to give up in frustration.
Complex plans lead to wait states
Configuring new servers and moving apps takes time. You need to:
▪ Plan
▪ Contact app owners and secure their buy in to the change
▪ Provision servers
▪ Determine production cut-over time frames
▪ Plan and complete testing
▪ Evaluate results
Inevitably, complex plans lead to wait states.
A wait state is a period during which a processor is waiting for the completion of an event before resuming activity; for example, it might be waiting for data to be unlocked or retrieved. Concerning moving applications and workloads to new servers, a wait state means that a person must wait to finish a task. People find wait states boring and inefficient.
Reconfiguration makes hand moves difficult
Moving applications involves reconfiguration, because the server to which apps are moving are never identical to the server and OS instances from which they’re moving. To make applications work on new servers, you’ll have to undertake a complex reconfiguration of IP addresses, network connections, drive mappings, and database connections. You may need to modify or replace peripheral drivers needed on the original OS to support physical hardware. Server names may change and the number and types of network interface controllers (NICs) often change. Application licensing might be tied to a hardware ID and will need to be resolved. You need to move user profiles and privileges, as well as upgrade stack components like databases and web servers. All this reconfiguration and setup make hand moves difficult.
Time, time, and more time required
You need lots of time from app owners and IT support just to plan for a by hand migration.You need lots of time to test the results of the move and then cut over production to the new server. Not surprisingly, hand moves suffer from delays that come from the learning curve associated with understanding applications and from other project issues.
You need an identical state or quiescence point to cut over from legacy production servers. However, all the reconfiguration and other rework involved in hand migrations can make it a challenge to sync with original production servers during an available maintenance window.
Most IT shops are highly skilled in Windows Server management, so with enough time and effort a technical team will eventually manage to reinstall applications on a new server and OS – but not without a struggle. A few hand moves later, they’ll probably be looking for a way to make application moves faster and easier.
There is a better way: Migration Intelligence can help
Perhaps you’ve struggled with the challenge of moving complex Windows Server applications by hand? If you’d like to learn how Virtamove can help with application migration and why Virtamove’s Migration Intelligence has become the system of record for moving Windows Server applications in Fortune 500 companies, 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.