Lessons Learned from a Massive Cloud Migration

By Atos Apprenda Support

Cloud Migration

In a previous blog post, we discussed the success of one of our largest customers migrating 71 .NET applications off Windows Server 2003. Due to end of life for Windows Server 2003, our customer decided to migrate these applications to a supported version of Windows and we helped them every step of the way for nearly 300 applications by the time we finished.

Migration projects are met with reluctance as some people don’t see this adding business value to the organization, but with the introduction of cloud platforms, this thought process is changing. Cloud platforms enable organizations to save on infrastructure by consolidation, making applications secure and scalable.

Traditionally, to make three-tier applications scalable and highly available, application development teams had to code. This code has high maintenance when there is a small change to the environment. Our cloud platform enables applications to scale and be highly available with minimum changes.

Here are several lessons we learned when we helped this customer with this massive migration.

Project Portfolio

The project we worked on involved migrating roughly 300 .NET applications from Windows Server 2003; the application portfolio was combination of plain HTML sites and three-tier .NET applications with Microsoft SQL Server. Project teams were located on four continents: North America, South America, Europe and Asia.

In addition to migrating the applications, the project goals were to reduce their server foot print by using cloud technology and make code changes to cloud-enable applications.

Assess the Application Portfolio

The first thing we did was to assess what applications needed migration. This included identifying and finalizing the scope of new application development. The existing application portfolios should be assessed for cloud enablement and, based on the assessment, the amount of change required with schedule for implementation can be identified. The below list provides an idea of what was assessed:

• Technology (programming language, database) and third party libraries used in the applications
• Types of applications (e.g., web applications, COTS applications, web services)
• Content publishing applications: In the early 2000s, .NET applications were used for managing content like newsletters, videos, and audio files. This type of application should be updated to work in the cloud environment or should be deployed in content management solutions like SharePoint.

Identify Scope and Effort

Based on the data collected from the application assessment exercise, it was then important to identify the following:

• Applications that require code changes (like removing hard-coded paths, changes to the connectivity to external systems, and external library upgrades)
• Effort needed to make the changes
• Applications that are not suited for a cloud environment and would require a separate environment for migration (mostly commercial off-the-shelf products will fall into this category)
• Applications that are not used by business users and need to be decommissioned. (In our project, we identified close to 100 applications to decommission.)

Monitoring the Project

We had three monitoring paths for this project to make sure the tasks are getting done right on time and not causing delays in the project execution.

• Infrastructure Path: The infrastructure build out and security review was monitored and managed by a project manager who made sure the environment build out was done on time and helped clear any hurdles
• Application Development Path: We managed application code changes, business testing, code deployment coordination, and production cutover
• Product Support Path: We had a project manager coordinate product implementation for the customer and solution architects to help our customer with migration tasks

Information Security

Involving the information security team early enough in the project to review the cloud platform from the security perspective and getting guidance will help the implementation. In our case, there were scenarios that required special permission for implementing authentication for existing applications in the cloud platform; having information security involved early helped to address them quickly without impacting timelines.

Non-Production Environments and Testing

Having non-production environments is critical for doing the migration project. Our customer had Development, Test, User Acceptance, Staging, and Production Environments. Having multiple environments helps reducing bottlenecks in code changes and testing. In our scenario, we were able to multitask activities to achieve the schedule goal.

One critical lesson we learned from the testing perspective is enterprises should account for performance testing in addition to the functional testing. Most of the time performance testing is overlooked for the migration project and, from our experience, performance testing is one of the critical factors for success.

Business Stakeholders

Generally, migration projects are executed as an IT internal project and business users are involved only to provide status of the project. From our experience, business users were actively involved in testing of the application in User Acceptance Environment and available to discuss requirements if there is a change required in the application for cloud migration.

Migration projects are a good time to review how actively the application is used and can provide an opportunity to reduce the footprint of the applications in case the users are not actively using the application.

Availability of Application Developers

Server migration projects are mostly dominated by IT staff to manage infrastructure-related work and have minimum developers assigned to the project to help with code remediation. Resource allocations are done this way so that core application teams can concentrate on new application functionality development.

From our experience, we learned that during the course of the project we required support from core application development for making code changes to applications that used external libraries, machine-based encryption used in database connection strings and testing of the applications. Accounting for this work in resource allocation will help reduce the friction between the teams and reduce impact to the project timelines.

Final Thoughts

We know the task of migrating your cloud applications is not an easy one, and that’s why we’re here to help. If you are planning to modernize your application portfolio and looking for guidance, our client services team can help with the implementation. Get in touch today and let’s chat.

Atos Apprenda Support