It is likely you will need to manage a number of Line of Business ("LOB") applications as part of a Windows Server 2003 End of Life programme. When thinking through a Windows Server migration (or decommission) you will need to discover and remediate business applications.
Unlike a new technology programme, a Windows Server 2003 EOL (WS2003EOL) project is likely to be seen as not implementing anything "new". This means that the resources are often not seen as architects - they are more demolition men and therefore not seen in the same light. Job titles might be "Server Engineer" or "Server Migration Lead". But there are elements of "design", simply because you need to find a new home for the old services.
As part of our overall series on Windows Server 2003 End of Life, this blog post outlines some of the steps you might take when migrating a single application. There are application virtualistion solutions available which can help avoid some of these steps but you will not eliminate interaction with the end-users, customers and stakeholders - areas that will take most of your time.
Web Application Example
Take a simple web app. It resides on a old IIS server and legacy SQL 2005 machine. It seems like the best thing to do is to upgrade and migrate the SQL database and move the application to a new IIS farm but that is only the technical perspective and more is required in order to perform an effective change for the business.
Application Discovery and Packaging
A Windows Server 2003 elimination program can often mean server-oriented teams need to branch out to different skill sets. It is worth noting the disciplines outlined here are usually associated with application packaging and may be undertaken by seperate application-focused resource or (in our experience) absorbed by the Windows 2003 decommissioning team. Either way, the application work needs to be done.
Initial Application Discovery
It is certainly worth tracking down the application owner and application developer (if they still work for/with the business) to find out as much as possible in regards to the application, data and architecture. Hopefully these conversations save a lot of legwork.
It is necessary to evaluate every application, service and workload under the same risk factors:
- Is the application externally-facing?
- Does the application have other interfacing applications or services running on Windows Server 2003?
- What would happen if this application was unavailable?
It is important to assess the business criticality and any data that is part of the application. How is that data stored - how sensitive is the data?
Line of Business applications tend to involve a device, so it is worth visualising how the user accesses the application. Seems really simple but as Windows Server 2003 legacy applications were installed years before the project it might have been well before the company deployment standards were put in place.
Whilst modern applications might be deployed via management tools such as SCCM and made available on a desktop or via a web portal there is a risk legacy applications will not be as easy to track down. This will immediately bring up questions:
- What do they do to access the web app?
- Maybe a shortcut, portal app or a terminal server session.
- Maybe that shortcut isn't managed, possibly a saved shortcut on the machine?
If possible, and to save time, it's worth visiting a user onsite to see if they (really do) use the application and what steps they take to access the app.
Application compatibility between the legacy app and new platform may take some time to establish and the ins and outs of establishing compatibility is too detailed to be documented here. In this simple example of a "Web App" the application could be running on .NET Framework 1.1 whereas your new web farm servers may only be running .NET 2.0 onwards. What, on the surface, seems quite simple will take some time to establish. If you have resource on your team that are both experienced with server/infrastructure and application development you will save a lot of time across the project because they can identify roadblocks and propose solutions.
A conversation with the software developer in regards to compatibility should be had with all details and concerns recorded.
Licensing and Media
Before spending time and resource investigating the fine detail of the LOB / service being managed it is worth looking into licensing implications of moving the application to a new platform. Moving from a physical to virtual server may add considerable cost for a COTS product so it is essential to know this before you embark on migration or decommission work. It is worth arranging to locate the relevant media for the software.
A critical step is to look at the security changes and requirements for the application.
- What accounts are the users using?
- What groups they exist in and do both of those exist in the Active Directory Domain where the application will be moved to?
- If the accounts / groups are not in the target Active Directory domain what is the best thing to do - migrate as-is or restructure the security in-line with the current business security standards?
- Is any of the security hard-coded in the application or data / SQL databases? Will either need to be amended in the target domain?
The next stage is the application itself - is it working as intended on the original Windows Server 2003 machine or are there known faults and work-arounds? When was the last time the relevant servers were rebooted? Is it worth re-starting the servers to ensure the application still works before you propose any changes?
Devoting some time for User Acceptance Testing will be necessary to document the right steps to test all or critical functionality. Formal end-user and business sign-off will be required and formal records for future reference. When running multiple server and multiple application workstreams this is critical.
In regards to IT Operations - What do they monitor on this system? What do they backup? If the application is being decommissioned are there any archive requirements? How will archive information be recorded?
- What monitoring and back-up systems need to be changed to stop management of the legacy servers?
- Will downtime be incurred during the switch-over?
Third Party integration
Rarely does an application run in isolation. Having established a baseline profile for the application is is necesary to determine how the application interfaces to other applications or products.
- Does the application use any third-party tools or software?
- Are the third party tools / software available on the new platform?
In order to deliver services many organisations (ignoring Microsoft Best Practice) installed Microsoft Office or related DLLs in order to deliver their applications. Since Windows 2003 a lot of effort has been made to reduce attack surfaces on servers by limiting applications and services running on each server. Therefore it might not be possible to recreate the same application using the third party componenets without breaking current security standards.
Proof of Concept
A PoC is critical to gaining confidence in the proposed solution and your migration plan. It will help you identify potential problems and establish and confirm your requirements for a successful migration.
Ensure your PoC has a well-defined scope and objectives so that when it complete you can be confident that you have all the information needed to migrate to the intended target. It is important to put time restrictions on the PoC simply due to the volume of change that will occur as part of this project and it is very likely the Windows 2003 project team will be leading and driving this to completion. Some contingency may be required to address any issues encountered.
But most importantly, you need to keep track of your project progress by monitoring both at the application and server activity. See this post on KPIs for further information.
You team will need to follow company standard CAB procedures to implement the new solution. You will also need to follow your organisation's process for decomissioning the servers. If you do not already have one, defining a formal Windows server decommission process is essential - because many activities within a server elimination are non-linear due to complexities and often workarounds are needed on an ad-hoc nature. Keeping track of change in this sort of environment is essential if you have hundreds or thousands of servers to be shutdown.
CONCLUSION:Initially a server decommission can appear deceptively simple . By looking at the just the application layer alone it becomes obvious this is not the case - the technical inter-dependencies is compunded by stakeholder management, communication, testing and any potential re-education that may be needed. And these take time to execute effectively. Therefore we recommend:
- meet with end users and application owners as soon as possible
- Map-out application stakeholders and owners
- Visualise the end user experience prior to the change
- Document what you discover
- Keep track of server decommissions from both a server and application perspective
There's a lot of investigative work needed for each and every application workload you are replacing. It is likely each workload is setup differently so you need to think on your feet - about the server workload and the infrastructure as a whole.