Moving Windows Server Apps Forward to a Better Place

You have a business-critical Windows Server application, and an IT “expert” tells you that the server needs upgrading and the app must move. You instantly feel uneasy. Yes, the server’s old, the operating system is unsupported Win2K, WS2003, or WS2008, so security is a problem. But the app is stable, and you use it every day. It’s critical to your business. Why would you touch it? If it breaks, fixing it will be a problem. The install scripts for the app are probably missing. You’ve been running and patching it for 5-15 years. The original developers are gone, and you may not have source code. You probably inherited the application from a team member, so you’re not sure you understand it completely.

The thought of moving production apps seems risky to everyone. Every day, customers communicate concerns to us about moving apps off old servers. However, getting that application off an unsecure, unsupported server to a faster, secure, and supported modern one is a good move to a better place. How do you move a production app to a better place without impacting your app or business operations?

Options for your app migration journey

Let’s look at how your app migration journey might start.

In-place OS upgrades on production servers

Some customers tell us that they’ve tried in-place operating system upgrades on production servers. Upgrading the OS on a production server is a highly risky step because it leaves the older, slower, and potentially insecure hardware in-place. It can also result in an unstable production application after the upgrade.

Upgrading and installing new versions of applications

Another path may be to configure a modern server or virtual machine and re-install all production applications. After re-installation, you must cut over the production data on the new machine. Re-installing is a risky option because original install scripts are often missing and production systems have been patched and configured many times over their life. It might not be possible to re-configure to the current, stable state of a production application. Upgrading and installing new versions of an application can be costly, forces users to learn new systems, and can cause a data conversion headache.

Faster, more secure server hardware and a modern operating system offer the promise of a better place, but how do you get there and copy the current state of production apps, without risky options?

A stateful re-install

With the help of an automated tool, you can dynamically discover the current “as-is” state of production applications. Capturing and moving the “as-is” state is called a stateful application re-install. Once you’ve discovered the current application state, you can copy out the application to a new, modern server, without modifying the original server or impacting the production system.

The app move can happen while you’re still using your existing server, without impacting daily use of the system. Migration Intelligence software helps by securely sandboxing the application copy on the new, modern server. You can then test it to make sure that it works on WS2012, WS2016, or WS2019 the same way that it did on your old server.

At VirtaMove, we understand that moving apps to modern servers is stressful. That’s why we built our software. VirtaMove also developed a comprehensive methodology to support production application moves. Every day, we successfully discover and automate the stateful re-install of Windows 2000, WS2003, and WS2008 applications on modern servers, virtual machines, and clouds running WS2012, WS2016, and WS2019.

Why a stateful re-install?

Windows Server applications are stateful. Historical data (such as user privileges, preference and configuration data) persists from one session to another. As time passes, application patches are applied. The application evolves, and all those changes become part of the app. A stateful re-install lets you dynamically discover and move your app forward to a better place and inherit, or bring along, state, even if you don’t have source code or install scripts.

The following figure illustrates four stages of a legacy app move. By Stage 3, you’ve moved forward and re-installed your legacy app on a new, modern server. Beyond Stage 3, you can even plan for app remediation or an upgrade if required.

There are advantages to a stateful re-install on new servers with a modern operating system. Benefits include:

  • A re-install closes known security exposures on old W2K, WS2003, and WS2008 servers.
  • Your apps will run on a secure, supported OS.
  • New servers run faster and improve app performance.
  • You can reconfigure where apps run. Apps can be split and installed on separate servers or consolidated on a single server.
  • Once it’s moved, you can easily do an in-place upgrade of the app to a new version without breaking configuration data.
  • Legacy apps can be remediated using the tools and techniques available on a modern platform.

Squeeze more life out of your apps

Moving apps that you rely on to new servers extends their useful life and eliminates the effort to redevelop or learn new systems. An automated, stateful re-install doesn’t impact your existing applications and ensures good performance on new servers. It saves time and money. In one month, automation provides a ten times improvement in the number of applications that can be re-installed and cut-over into production on new servers. If you have the source code, you can plan future functional or security improvements using a conventional change management process.

An automated, stateful re-install is the best first step. It starts your app migration journey safely and provides tangible improvements and benefits. Your apps will be in a better place, and your business along with them. VirtaMove can help you along your upgrade path. If you’d like to understand more about how we give business-critical production applications a second life by moving them to a better place, don’t hesitate to give us a call. We’re pleased to share what we know.

Submitted by