On January 14, 2020, support for Windows Server 2008 and 2008 R2 ended. Among other things, that also translates into an end to the regular security updates from Microsoft. What’s the impact? Infrastructure and by extension the applications residing on them are now vulnerable. This blog highlights the journey that we went through for a leading financial organization in migrating their Windows Server 2008 workloads to current Windows Server versions for greater security.
Considering the fact that Microsoft takes ‘product lifecycle’ management seriously, the following options were suggested when end of life for Windows Server 2008 and 2008 R2 was announced:
- Migrate the Windows Server and SQL Server applications to Azure to accelerate innovation with improved cost savings and security
- Upgrade on-premise and stay protected
Option 1 basically means:
Rehosting Windows Server 2008 and 2008 R2 workloads to Azure. You also get an extended security updates at no additional charge for three years. You can use your existing licenses and save costs by using Azure VMs and Azure Hybrid Benefit.
Option 2 means:
Upgrading the on-premise servers to Windows Server 2019 for greater innovation, built-in security, and container support. However, the client will have to pay for the three years extended security support until the application migration is completed and the servers are decommissioned. Another quick and easy option provided on Windows server 2019 is running the application on windows container using docker engine.
Below are the migration options considered for this program.
This blog predominantly focuses on the automation aspects of the program brought in for ‘Discovery Assessment’ and ‘Design’ phase.
The most vital element to kick-starting the migration journey was ‘Discovery and Assessment’. We were awarded a seemingly impossible task for the discovery of 500+ applications spread across 25000+ server portfolio. The client had multiple stakeholders from across business, technology, product vendors, support background, and the information required to perform migration assessment was segregated across different ITSM tools such as CMDB, BMC ADDM, Service now, and Tech-Connect etc. The anti-incumbency and outdated information in CMBD also added to the challenge.
The migration-as-a-service (MaaS) program was proposed to run in the New Ways of working (NWOW) – scaled agile model for the bank environment. The migration phases below were proposed with granular activity level details to be performed by different stakeholders in the program.
Automation of Discovery Phase:
The discovery phase was the foundation element of the MaaS program. It involved identifying server inventory along with the applications associated with the Windows 2008 servers. The 500+ application portfolio of 25,000+ servers were distributed across multiple environments such as Dev, SIT, QA and PROD hosted on multiple data centres and geos. The next step involved gathering information related to the application stack, 3rd party dependencies and it’s upstream/downstream. The discovery process is always challenging as the required information for the servers and application is segregated amongst different ITSM tools and incomplete.
Our initial discovery and assessment approach indicated that we cannot rely on the information provided by ITSM tools and the design documents shared by domain and other vendors. This required us to introspect by listing down the current challenges for our discovery process and get a customer buy in to adopt an automated discovery tool.
Below are the challenges which led us to conclude for automated discovery exercise.
We initially proposed Cloudscape to fulfil the Automated Discovery requirement. However, due to access and licensing issues this idea was shot down by the program sponsors. This gave us an opportunity to ideate a Custom Discovery Tool which could meet the regulatory standards for banking environment. Hence, it was decided to create a self-contained, portable and custom built “Discovery and Validation” Tool which could be easily deployed as per the banking standards.
Below are the key features of the ‘HCL Automated Discovery Tool’.
- Application Stack Details
- Development technology framework and their versions
- Database technology with versions such as SQL Server 2005, SQL Server 2012, MongoDB
- Operating system with versions such as Windows server 2008 r2 , Windows Server 2016
- Server Specification Details
- Extract details for the server specifications such as Number of cores, allocated RAM and disc space allocated for different drive such as Intel Core i7-6500U CPU @2.50GHZ, 32Gb RAM C:\ disk space :50GB
- Server Configuration Details
- Details related to Service Accounts configured for the discovered application.
- Extract Group Policy Objects defined on the server
- Fetch details on the standard and non-standard packages installed on the servers along with their versions.
- Provides details on the pplication folder structure and permissions allocated for each group /user for each folder and file inside the application folder tree.
- Target Build Validation
Compare the source server (windows server 2008) with the newly built servers (Windows server 2019) for the application being migrated on-permise or cloud.
- Compare the specification of the server to make sure it is built as per the ‘Treatment plan’.
- Compare the configuration details such as packages and policies for both source vs target and provide the differences on the tool.
- Provide the differences on the folder permissions for the ‘Application Folder’ Tree.
All the above details provided in the tool can also be extracted in the form of .CSV files to be consumed externally.
Automation of Design Phase
Once the initial assessments were done, the applications were assigned to the migration delivery team. This team started with validating the documented existing environment details and then started identifying the targeted environment, deployment architecture, windows components, libraries to be installed/ supported into an excel file template called ‘Treatment Plan’. The application treatment involved finalising the hosting platform, any changes that were needed to the technology stack/ versions, Services, Jobs, Reporting stack and Database tier. Once the design is finalized the treatment plan is shared with the Infrastructure (IaaS) Team for a Target Server Build.
Upon receiving the target build from the IaaS Team, we utilized the Build Validation module tool to validate servers on various aspects such as specification, and installed packages and group policies. Below is an example of the applications migrated to Windows server 2019 and validated on different criteria.
Key Benefits from Automated Discovery Tool
- The tool enabled an agentless discovery without any additional installation required on discovered servers
- 50% faster discovery turnaround with better accuracy
- We were able to save close to 1000+ man hours’ effort for on discovery and design for the first tranche of migration
- Automated target server validation provided the exact comparison on the build difference between source and target servers helping us identify potential issues at an early stage to avoid application triages during migration
- Better program control with less dependency on other team for discovery information
- Reduce margin of error due to automated discovery and artefact creation