How is Migration to the cloud performed?

AWS provides a large 3-phase approach for a Migration Acceleration Program (MAP):

• Assess,
• Mobilize
• Migrate & Modernize

Assessment (evaluation of the ability to perform migration)

This inventory and analysis phase of the existing situation lasts from 1 to 3 months, and the following issues must be addressed as a matter of priority: 

1. Identifying the TCO (Total cost of ownership) on AWS (generally, Migration Evaluator is used) and confirming that it meets the MAP access conditions. 
2. Confirming the budget and human resources to perform migration.
3. Identifying the project required before migration, via a Migration Readiness Assessment (MRA). Here, the ability to perform Migration must be assessed along the following lines:

• The ability of the cloud platform (Landing Zone) to host applications at scale
• The ability of the security solutions and processes to provide the expected levels of security across the portfolio and operate at scale
• The ability to provide cloud financial management for a large volume of applications, and AWS accounts
• The skills of the teams to perform cloud migration and operations activities
• The organisation and cloud governance to make the right decisions on a large volume of applications
• The level of control over the application portfolio
• The ability to manage complex programs

4. Confirming the sponsorship

This is also the time to frame the Mobilise phase in terms of resources (internal and external), management, budget and duration with key milestones, and to set up contracts with external suppliers.

Mobilise (mobilisation of resources for migration to the cloud) 

This phase typically lasts between 3 to 9 months. 

It allows the gaps identified during the Migration Readiness Assessment to be bridged, practise on a few pilot applications (3 to 5), and mobilise the teams that will be involved in the migration program. 

In the case of the above-mentioned priorities, there is therefore work to be carried out that has not been considered completed. There is also:

1. A specific project on the detailed analysis of the application portfolio in order to identify the scope of the migration, migration path for each application and migration schedule.
2. A project on implementing the methodology, organisation, tools, KPIs and governance required for the migration phase with the associated contractualisation.
3. A project on the target operational model (TOM)
4. A specific project on skills progression, implementing community building and designing the communication plan.
5. A project to manage all of these subjects and in particular the numerous dependencies between them.

Migration and Modernization

In reality, the migration phase at scale takes place over a period of 1 to 3 years, in which the planning is performed by applying the methodology and governance prepared in the Mobilise phase. Migrating a portfolio of 200 applications means managing 200 projects in parallel, of different complexities, with different teams. These migrations rely on 4 major organisational pillars:

1. The development teams that, ideally in a DevOps mode, ensure all the development, testing and operations activities of the application and whose application owner manages the entire migration cycle (“accountable” for migration).
2. The “Migration Factory” that will support the development teams in the migrations at several levels: 

• Guarantor of the migration methodology of templates and associated tools (that industrialises the migration activities as soon as possible) 

• Program manager to provide a consolidated view of the planning, budget and scope of the migration 

• AWS architects to support the development teams developing the designs on AWS 

• Global budget guarantor by consolidating all information on the costs associated with migration and detecting drifts 

• Experts on migration technologies (data migration tools, VM migration tools, large storage migration tools, etc.) and the mechanism to trigger the credits provided by AWS.

• Developing automated discovery tools • Developing and enriching the migration cockpit (control panels that will enable the migration to be managed at scale) 

• Moderating the migration community

3. The CCOE (Cloud Centre of Excellence) that manages the cloud platform and the configuration to meet the needs of the various applications and business owners to be migrated.

4.

The complementaryshared technology services entities that manage: 

• IT security 

• The network infrastructure 

• Build and operations tools 

• Transversal infrastructure services (DNS, NTP, AD, file transfers, management of patches and system images, etc.) The efficiency of the collaboration model between these pillars is a major guarantee of the success of the migration project. The governance model and ability to strengthen teams, trigger alerts within a short cycle, and involve complementary expertise is another ingredient of success.

Migration Execution

The migration cycle is a standard application cycle that must capitalise as much as possible on the release management practices of the various development factories. It’s based on the following phases: 

Discover : During this phase, the business owner presents the following to the members of the migration factory who will be supporting migration: 

• the business issues associated with the application, design of the existing application, 

• different incoming and outgoing flows 

• service contracts 

• different environments and their roles 

• capacities used 

• variations in the level of use on a typical day, week and year 

• and the different stakeholders involved in the application. This phase can be sped up by using automated discovery tools based on exploiting structured technical data (firewall rules, backend-frontend links in load balancers, infrastructure configuration files, application configuration files, DNS records, etc.).

Design: during this phase, the design of the application once migrated to AWS is developed according to the type of migration pattern envisaged (Rehost, Rebuild, Replatform, Refactor – see the chapter “Application transformation”).

Technical and Financial Design Validation: design validation and financial evaluation to check compliance with the business case and define the budget that will be implemented 

Implement and Deploy: this involves deploying the infrastructure of the environments based on infrastructure as code, and transforming the application to make the most of both the cloud and the tests

Pre-cutover: during this phase the capacities and performance of the application on AWS are validated, the operating tools are integrated and the operating instructions are adapted. Then, the operability is validated, the inter-application flows (internal and external) are tested, the service owner acceptance is obtained, and the detailed plan for the switchover with the associated rollback plan is defined.

Cutover: transfer cross-user and cross-application data streams to the instances deployed on AWS. In this phase, the correct load increase and behavior should be validated with standard error rates and standard performances.

Post-cutover: an observation phase in which the applications operation is monitored. At the end of this phase, the decision is made not to go back to the original instance.

Decommissioning: these are the operations for decommissioning the original application and all associated settings. This phase may include destroying data in accordance with security instructions and recovering equipment by a broker.

Assessment: based on an agile retrospective model, it enables the identification of practices that are to be retained, improved or abandoned and also new practices that are to be adopted. An overarching exchange makes it possible to benefit from best practices.