Practical Advice for Moving Your Windows Server Apps
TORONTO (PRWEB) January 31, 2018 -- At AppZero, we’ve moved thousands of Windows Server applications from WS2003 to new OS versions and servers for hundreds of large customers like Glaxo, TD Bank, CIBC, Metlife, Clorox, IBM, and many others. Read on for some practical advice on how to make moving legacy applications to new versions of Windows Server easier.
The Problem is Big
More than 3 years ago, Microsoft announced the end of support (EOS) for Windows Server 2003. The extended service period for WS2003 ends in 6 months, in July 2018. When EOS was originally announced by Microsoft, approximately 22 million WS2003 servers were in use worldwide. Since then, approximately 40-50% of those servers were decommissioned, and an estimated 3 million servers were upgraded and their applications ported to new operating system versions (quite a few of them were upgraded using AppZero). Based on AppZero market surveys, we estimate that there are still more than 7 million WS2003 servers, more than 1 million WS2000 servers, and many legacy Windows NT servers in production worldwide.
In 2017, Microsoft announced extended support for WS2008 Servers (under certain pre-paid terms) until 2026. AppZero estimates that there are more than 40 million WS2008 servers in production use. The number of WS2012 servers is estimated to exceed the number of WS2008 servers.
Almost 50 million servers will need to roll forward during the next 5 to 8 years – by which time many of the WS2012 servers will also roll forward to newer servers. The scale of the problem is significant. If you need to modernize your servers to take advantage of the new security and management features of WS2012 or WS2016, then you’re facing the remediation and migration of many applications. Most large corporations will need to undertake this with careful planning and budgeting. While you can turn to manual upgrades and re-installation to move some of the easy applications, solving the problem in scale may require you to consider automation tools.
If you’re struggling with the problem of moving legacy WS2003 applications to new servers, you should know two key things:
1. The problem is widespread, so you’re not alone.
2. Rolling applications forward to new servers isn’t a one-time exercise. It won’t end with EOS for WS2003.
Lots of Reasons to Upgrade
Operating systems eventually reach EOS, prompting many reasons to upgrade applications. One reason may be audit and compliance requirements. If you’re operating in a regulated business, running on an unsupported OS won’t meet these requirements.
Security exposures may be another reason. Older OSs such as WS2003 and WS2008 have security holes that hackers can exploit, as demonstrated by recent ransomware such as WannaCry and Petya.
Perhaps you want to address both compliance and security issues; however, you want to defer or avoid the cost of developing new applications or retraining staff, which happens all too often when applications need to be completely redeveloped in order to move them.
You might also want to run on better, faster hardware or on a scalable Cloud service that supports only newer OS stacks. Maybe you want to take advantage of newer application management tools that are available on a new OS, or use technical innovations such as Windows Containers, which are available only on WS2016. New stack or database features can also drive the need to move applications forward. Maybe you just want to declutter your applications.
For these and many other reasons, standing still and running on legacy servers is rarely a wise or long-term strategy when it comes to computing platforms.
Monitoring Helps
With thousands of application migrations under our belt, we know that application monitoring provides the best, first step for any app migration project. Application monitoring can help you:
• optimize server resources based on actual usage factors
• determine application dependencies
• reduce security exposures
Who’s using which apps, and how?
Detailed application usage tracking data helps you make business decisions about when, where, and how to move applications, based on:
• which applications are being used, which users are using them, and when they’re using them
• which functions or features of an application are used and how they’re being used
Usage tracking data shows when apps are gathering dust. Perhaps those applications are candidates for decommissioning. It doesn’t make sense to spend money on migrating or upgrading unwanted apps. Knowing which apps are not being used is an easy way to eliminate work and save time and money.
Application monitoring also helps determine which apps are experiencing expanded usage. Perhaps you should upgrade in-demand apps or prioritize moving them to new servers to accommodate user demand and improve application performance.
Some applications experience seasonal or periodic growth in demand. Such applications might be good candidates for Cloud migration or may be better hosted on in-house servers based on these factors. Application monitoring is key to determining usage trends and variables.
If you know which application components need to be moved based on actual usage, you won’t need as much application owner involvement in both the discovery phase and the application user acceptance phase. That’s a significant time saver.
What do all these apps depend on?
Intelligent application monitoring can provide insights on application dependencies. When it’s time to move applications to new servers (both on the Cloud or inhouse), you’ll know ahead of time about all the dependencies and stack components that need to move too.
Knowing which application components need to be built and moved means that the application can be built dynamically on the fly, based on actual past application usage. This simplifies migration and often eliminates user testing post migration. More time saving.
Less exposure is a good thing.
Application monitoring can also reveal security issues, such as re-used common admin passwords, unusual off-peak EXE calls, and other potentially serious security exposures.
Putting detailed monitoring in place before you undertake a Windows Server application migration project is a best practice for most migration projects. It helps you greenlight and determine when you know enough about an application to move it to new servers. With application monitoring, the entire migration process gets simpler, faster, cheaper. In other words, smarter.
Use a Migration Methodology
In any application migration project, you need to discover applications and determine all application dependencies. Then the applications need to move in isolation, with appropriate re-configuration on the fly. Finally, you’ll need to verify the migration, then cut over users to the new server after testing is completed. Having a migration methodology will help you achieve all these steps effectively and efficiently, each time.
Hand Migration Won’t Do it All
Many companies attempt to solve the Windows modernization problem by migrating applications by hand, using in-house resources or a combination of internal resources and contractors. However, hand migration suffers from a shortage of skilled resources, missing developers, missing installation scripts, unknown authorization and security codes, incompatibility of development libraries, and a host of other technical issues, many of which are anything but obvious. Planning, executing, and testing hand migrations is expensive, time consuming, and highly resource intensive for application owners and users.
All too often, customers discover that ISVs don’t provide an affordable or practical way forward for their applications. Also, many vendors focus on upgrading only their portion of the application stack, and omit all the tools and software that may be part of a complex application.
So, I’ll just re-install the app on a new server. Simple, right?
Not so simple, actually. Moving always involves database upgrades and migrations, porting user profiles, OS changes, and detailed new platform acceptance testing and cut-over. Each step needs to be executed and implemented in a reliable, timely way.
Consider Automation
Your migration methodology can benefit from automating many of these critical steps. Automation can help you scale the problem of moving a large number of applications from outdated operating systems such as WS2003 to WS2012 or WS2016 in a way that manual migration just can’t. In fact, with the right automation tool, you can simply script many steps at the command level.
Application migration benchmarking shows productivity improvements of 100 to over 1000% for automated migration methods versus manual efforts.
Procrastination Hurts
We tell our customers that the second-best time to upgrade your Windows Server 2003 applications is Now. The best time, unfortunately, was 36 months ago. Many Microsoft customers believe that procrastination is easy – when in reality procrastination wastes time and energy, and holds you back from embracing change and creating a future.
Running on operating systems that have reached end-of- support is risky business. If you want Microsoft’s new security and operating system features, you’ll need to move your applications forward, and not just off Windows Server 2003 to 2008. After nearly a decade of use, we’re finding that many AppZero customers are migrating from WS2008 now and moving forward to WS2012 or WS2016 to avoid excessive extended support fees.
If you’re still running WS2003, you need to get to work. You need to modernize. We’re here to help.
To learn more about how automation can help drive your application migration projects, give us a call. We’re always happy to help and eager for even the toughest challenges.
Alex Topitsch, AppZero, http://www.appzero.com, +1 (613) 254-5432 Ext: 4310, [email protected]
Share this article