Neither Are an App Re-Install or a New App Install
There are different approaches to legacy modernization, including an in-place OS upgrade. This blog discusses these approaches and proposes an alternative.
Option 1: Is an in-place OS upgrade the answer?
At first glance, an in-place upgrade of an old operating system like Windows Server 2003 might appear to be the thing to do. An in-place upgrade is “…moving from an older version of the operating system to a newer version, while staying on the same physical hardware.” The installation of the new OS is done “without removing the older version first and without saving any data beyond normal precautions.” This method keeps your settings, server roles, and data intact. Contrast with a “clean install,” where you move from an older version of the operating system to a newer version, deleting the older operating system. However, an in-place upgrade can be problematic, especially if the new version of the OS is very different from the previous one. This approach requires lots of careful planning.
IT teams may contemplate an in-place OS upgrade because it seems like the simpler option, but in reality, it seldom is.
An in-place OS upgrade is a costly, time consuming, error prone, and complex option
For starters, you’ll need a full backup of the original server in case the upgrade goes off the rails at any point along the many steps required in the process. Plan for stepwise approach to the upgrade. If you’re going from Windows Server 2008R2, for example, you can’t go straight to WS2019. You’ll have to go to WS2012 first, then to WS2016 and on to WS2019.
Each step along the upgrade path will require testing, because the chance of something breaking in a step is high. This is because of the baggage associated with your former operating system: old drivers, old desktop profiles, uninstall files of the previous OS patches, as well as file changes, registry changes, or even viruses that were from the previous install. There might be deprecated features and application syntax might be more stringent on the newer version of the OS. File registry changes on the old OS are also pulled forward with an in-place upgrade, and these changes may not provide the same result in the new OS or might simply be clutter in the new OS. Think of all the baggage and clutter you are pulling forward with each OS step. Each step is a possible breakpoint, and there is no easy rollback if you encounter a break partway along the upgrade path.
If you do roll forward successfully with your new OS, you’ll have to reconfigure the name and IP address of the production version of the server manually. All the old baggage we mentioned above takes up lots of space in the new version, so you’ll likely need to clean up and remove the old, unnecessary stuff. This includes apps that are no longer required or used.
Before you start, check for limitations. You should check with your cloud provider to see whether in-place upgrades are supported and what the details are. You won’t be able to perform an in-place upgrade on any Windows Server configured to Boot from VHD. Additionally, an in-place upgrade from Windows Storage Server Editions to Windows Server 2019 is not supported.
Keep in mind that if your application is old, you may have to do an in-place upgrade of the application as well as an in-place upgrade of the OS – and now your possible break points are only compounded.
In-place OS upgrades also occur on production servers. If you run into a problem, rolling back or restoring to earlier working versions is difficult. Upgrades happen step by step, and each step requires thorough testing. Production upgrades need to occur during short down-time windows, which makes completing the many upgrade steps and testing almost impossible.
The last word on in-place OS upgrades
IT teams may contemplate an in-place OS upgrade because it seems like the simpler option, but in reality, it seldom is. With the need for repeated testing in steps, it’s a costly, time consuming, error prone, and complex option.
Option 2: What about re-installing an app?
OK, so an in-place OS upgrade isn’t the way to go. What about simply re-installing an app? Can you use original install script to achieve a native install of an old app on a modern operating system or to install the app into a container? Reusing install scripts, however, has its own set of issues.
First, and most importantly, you’ll likely be working with the original install script and therefore not the current state of a legacy app. You won’t have all the historical patches and configuration data you’ve applied to the app over years of use: client, user, preference, and configuration data, patches, upgrades, to name a few. The historical custom configurations, tailored patches and functions are what make a legacy app so valuable to an organization. Also, you likely won’t know which install options were used during the original install.
Your legacy app will need to run on a modern OS, and therefore the install scripts may need to be modified in some way to do this. For example, you may need to change where app components are on the new OS in contrast to where they used to be on the old OS. Lots of testing and reconfiguration will be required.
An app re-install using old install scripts is also a complex process that involves resolving script changes, cumulative patches, drivers, and COM components. At the end of the process, you’re likely to end up with a completely different version of the application you were using before the re-install
Option 3: What if I install new application software on a new OS?
Maybe simply installing a new software version of your app on your new OS is the way to go. For example, you might decide to ditch obsolete SQL Server 2008 R2 and install SQL Server 2019 instead. The problem with this scenario is that if your organization is attached to the current state of a legacy app, you lose all that state. With a new version install, years of data, configuration, customizations, and business knowledge will be gone.
If the software company that made your app doesn’t provide migration capability, you’re faced with bringing the current state of your legacy app and all its data to the new version of the app in some way. You may need to redevelop custom components that are outside the core app software.
Assuming that you’re able to convert the current state of the old app to the new app, your work is cut out for you. You’ll need to consider:
The cost of the license for the new version of the app.
Manual remapping and reconfiguring the IP address and server name, certificates, permissions, access, user profiles, peripheral drivers, etc.
The learning curve associated with the new app.
Testing requirements to make sure that the new app fulfills expectations.
Careful roll over of the new app.
Option 3 offers a new upgrade scenario, but with many of the same issues that come with the other options discussed above. It isn’t easier, and like option 2 it doesn’t address the current state of your legacy app.
Option 4: The better way, a stateful re-install
A stateful re-install using VirtaMove migration technology and methodology gets your legacy apps to a better place without the need for a stepwise upgrade process and without the risks of an in-place OS upgrade. You get to keep all the valuable historical information that your organization depends on. VirtaMove uses a proprietary, lightweight container as a moving box for stateful apps.
Our intelligent migration software automatically discovers apps across your network, and then packages them and all their components into a container on the new destination server. The containerized application is isolated from the underlying operating system and is portable. Perfect for testing on a new OS and a new server.
There’s no permanent reliance on our container: it 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 then runs natively on a modern Windows Server OS, with all its configuration, patches, and upgrades. If you choose to run an app in a container, it can run on a hypervisor.
You can reconfigure dynamically. Roll out as and where required, and use step snapshots to roll back easily if required.
Benefits of a stateful re-install
Re-installing apps on new servers brings advantages:
A new server and modern OS close known security exposures.
New hardware improves performance.
Apps can be split or consolidated.
Software components, such as IIS and SQL, can be upgraded for new servers.
A re-install reduces clutter and lets you install on modern datacenter VMs or the cloud. You can manage servers with DevOps tools.
A stateful re-install is the best first step in modernizing. It extends the useful life of legacy apps, and redevelopment and a rebuild can still happen over time. You can manage legacy apps using a conventional change management. You’re not forced into redevelopment because you want to run on modern servers, and you don’t need to take on the risks of an in-place OS upgrade.
If you want to understand more about what VirtaMove does, schedule a demo on our website, email us or give us a call. We’re pleased to show you what we do.
