Contact us anytime to know more — Amit A., Founder & COO CISIN
This guide presents an overview of a phased migration approach consisting of three stages: assess, mobilize, migrate and modernize.
This document's primary goal is to explain the migration part of this third stage; initialize and Implement are also covered within it.
Stage 1 Initialize involves getting your platform prepared for migration. Standard Operating Procedures or Runbooks (SOPs) and automation should also be created and defined at this point to assist with the implementation of large migration activities during Stage 2.
Stage 2 involves large-scale migrations of servers while monitoring progress toward continuous improvement.
Guide for Large Migrations
Large migration projects involve migrating 300 servers or more, and most enterprises do not understand how best to approach such an undertaking in terms of people, processes and technologies.
AWS Prescriptive Guidance Series documents offer guidance for large migrations onto AWS Cloud by outlining best strategies and practices to simplify the cloud journey.
Figure 2 presents all the documents in this series of Large Migrations to AWS Cloud Migration Documents. Initially, review your strategy document followed by guides and then playbooks - see Large Migrations to AWS Cloud for all available series documents.
The tools
The guide also contains a matrix for assessing the overall health of your migration project, providing an effective means of measuring its efficiency and progress from beginning to end.
You can apply best practices as you measure its progress during its entire lifetime - using this playbook, templates and tools are provided that enable each workstream.
The Phases Of A Major Migration
AWS organizes the migration of large workloads in three steps.
- Assessment phase: You will construct your business case for migration.
- Prepare the organization and gather resources in advance of migration.
Phase of Migration and Modernization: At this stage of modernization and migration, your plan and strategy come into effect to implement.
There are two stages to this phase: Initialize and Implement.
Figure 1 depicts three phases of any major migration project: Assess, Mobilize, Migrate and Modernize (AMSM MOM).
Each of these four processes should occur sequentially until completion, requiring two distinct methods (initially and executed). Although this document set is focused on migration alone, completing all three is highly encouraged. Doing so provides a strong basis for further work on that migration initiative.
Assessment Phase
Step one of your large migration starts here! In this phase, you will create your business case, assess your organization's cloud readiness, review portfolio components and ensure all key stakeholders are aligned - please see Evaluating Migration Readiness on AWS for further details about this phase.
Mobilize Phase
Once your business case is in place, use your readiness assessment from phase one to identify and fill any gaps.
As part of phase 2, mobilize the organization by setting up workstreams in preparation for migration; building an AWS landing area, conducting more comprehensive portfolio assessment processes, creating your operating and security model and prepping teams to change are also key aspects. See Mobilize Your Organization to Accelerate Large-Scale Migrations for additional details regarding mobilization stages.
Phase Of Migration And Modernization For A Large Project
After mobilization, your organization should have an excellent foundation to begin migration and modernization efforts.
The first step should be assessing foundations such as people and aws solutions architect platforms to determine whether they can support large-scale migration; automation/simplification of standard operating procedures to form repeatable patterns (The Migration Factory is often called this approach) are also required - these processes must all take place smoothly to begin modernization efforts successfully.
When creating a factory for migration, initialization, calibration, standard operating procedures (SOP), performance measurements, and ongoing improvement must be in place, continuously improving tools and processes.
Initialization marks the first stage in large-scale migration projects. At the same time, implementation involves running and optimizing your factory with server migration in waves as workstreams focus on specific aspects.
Here is what this section includes:
- Initialize and Implement Stages
- Workstreams Initially and Implement Steps on Stages as Part of their Development
Workstreams
Your migration project involves multiple work streams that each focus on specific tasks to fulfill particular functions as the migration progresses from initialization to implementation.
Although each workstream operates independently, they work collaboratively towards one common objective - migrating servers on an expansive scale.
Add additional supporting workstreams as necessary if desired.
- Workstream Foundation - This workstream's primary objective is to prepare the platform and people for an imminent migration project.
- The Project Governance Workstream oversees the migration process, facilitates communication among project participants, and concludes it within budget and on schedule.
- Workstream Portfolio - Teams in this workstream collect metadata for migration support, prioritize applications and plane waves.
- Teams in the migration workstream use metadata collected through the Portfolio workstream to migrate servers and applications efficiently and seamlessly.
The Foundation Playbook for AWS Large Migrations offers more detailed guidance regarding creating and utilizing work streams within your project.
Initialize and Implement Stages
Migration and modernization should typically come before migration; thus, the process consists of two stages.
- First Step in Large Migration Prep. Your team and platform must be adequately prepared to handle large migrations. For instance, reviewing and testing landing zone designs might ensure sufficient bandwidth, or designing and implementing effective training programs can all aid in planning a migration of this size. Standard Operating Procedures will then be created according to organizational policies and processes. At the same time, runbooks or automation may help speed up implementation in stage 2.
- Stage 2 of large migration. Here, servers will be moved at scale with runbooks established during stage 1. Stage 3: Implement large migration. Here, servers are moved at scale using runbooks created during Stage 1.
Want More Information About Our Services? Talk to Our Consultants!
First stage: Starting A Migration Of Large Numbers
Establishing runbooks (standard operating procedures) is critical when undertaking scale migration projects. By automating, connecting, and outlining procedures in advance of large migrations, efficiency will increase dramatically.
In contrast, migration processes may become complex or fail altogether if runbooks aren't adhered to - this guide offers help starting right by reviewing playbooks and workflows, which provide useful templates that you can adapt into creating your runbooks.
Playbooks are created to assist with finishing the initial phase and initializing and prepping for stage two: Implement.
- The Foundation Playbook for AWS Large Migrations guides personnel and infrastructure during large migration projects.
- Playbook of project governance for AWS migrations - This playbook will assist in developing project governance tools and processes to effectively oversee large migration projects, with templates provided as starting points.
- The AWS Large Migrations Portfolio Playbook - This guide can assist in building runbooks to plan waves and assess portfolios using the templates provided. It may help when starting.
- Playbook to Create Runbooks for AWS Migration Patterns - The playbook will assist in building runbooks tailored specifically for each migration pattern on AWS, featuring templates of these migration techniques and more.
- A health-check matrix can provide you with an invaluable way to monitor the progress and efficiency of any project from its inception through completion.
Start By Using The Foundation Playbook
This playbook will assist in building the infrastructure necessary for success and equipping your people.
Here are a few examples of how you can prepare your employees:
- Make sure that all stakeholders involved with migration have pledged their support.
- Prepare to undertake an international migration. Define the work streams associated with such an undertaking.
- Launch and manage a Cloud Enablement Engine team or Center of Excellence.
- Create a matrix of responsibility assignments using the RACI methodology (Responsible, Accountable, Consulted and Informed).
- Make a training plan for all resources involved with migration.
Here are a few platforms you could build for your organization:
- Prepare the AWS landing zones to accommodate large migrations.
- Assess the state of readiness in your infrastructure.
- View the Foundation Playbook for AWS Large Migrations to gain more insights.
Step 2: Use A Project Governance Playbook As A Guide To Set The Rules
Step one involves setting out the rules and boundaries for migration. Here, it is important to identify key processes and plans for this endeavor:
- Benefit Tracking Office, Communication Plan
- Process Escalation on Migration and Cutting Over
- Tools and strategies for effective project management
Further resources can be found in both Introduction to Governance for AWS Large Migrations and the Project Governance Playbook for AWS Large Migrations.
Create Portfolios Using The Portfolio Playbook
Now that your scope and strategy are clearer, this step involves following a playbook for portfolios to develop comprehensive runbooks for migration factories.
Specifically, ensure they possess adequate servers as raw material and all required information for a smooth transition. Tasks may include:
- Revamp the migration strategy you conceived during mobilization; please refer to Understanding Migration Strategies for more details.
- Establish the metadata requirements for every migration pattern.
- Set out an effective process and repository to collect metadata. This should serve as the authoritative source of facts.
- Establish prioritization rules.
- Establish and apply deep diving regulations.
- Establish your wave planning process.
- Portfolio Playbook for AWS Large Migrations provides more details.
Step 3: Build A Migration Guide For Each Pattern Using The Migration Playbook
Step two of this migration process may run concurrently with Step three. Utilizing the Migration Playbook, create your runbook that addresses each migration pattern; for instance, re-platforming storage system storage to Amazon Elastic File System with AWS Cloud Migration Factory or hosting the application on AWS Elastic Compute Cloud (Amazon EC2) using AWS Cloud Migration Factory are just a couple of examples.
Runbooks should be tested until there are minimal or no errors and complete checklist tasks are included within it - these might include charges like:
- Understanding migration patterns.
- Integrate your processes and tools into the templates.
- Test runbooks to increase efficiency.
- Automate as many runbooks as you can.
See AWS Large Migration Playbook.
The Health Check Matrix Is A Great Tool To Help You Evaluate Where You Are
Verifying that the previous steps have been completed successfully by your team and identifying any gaps is essential in maintaining alignment with best practices and migrating smoothly.
aws trusted advisor Evaluating migration progress as well as process enhancement is paramount here.
The Health-Check Matrix can be used to evaluate the state of migration concerning people, processes, and technologies.
It should be remembered that evaluation should occur continuously to maintain effective migration management practices.
Step 4:Is To Implement A Migration On A Large Scale
Stage two's goal is to migrate servers incrementally and manageable. If your goal is to migrate 1,000 servers over six months, start migrating five per week before increasing it to 50-100 per week as your timeline permits.
Now, you can use the runbooks you developed in Stage 1 to migrate your servers. Initial waves tend to be small as workstreams for migration and portfolio continue adapting their runbooks; the success of large-scale migration relies on the quality and efficiency of runbooks being updated frequently.
After each changeover, you must review, revise and enhance them so they evolve with time, thus speeding up waves as time goes on.
These components will enable you to run an immigration factory successfully during Stage 2.
- Rules for Project Governance - To successfully govern projects, one needs to follow certain processes such as controlling waves, communicating effectively, managing timelines and making cutovers. Tools and techniques ensure people do the appropriate activities at the right times.
- Portfolio Runbooks: Portfolio runbooks serve several functions, from prioritizing applications and planning waves to gathering metadata necessary for migration - these raw materials form the backbone of every factory.
- Migration runbooks offer an effective means for moving apps and servers between platforms. Load metadata into migration tools before performing cutover after each wave plan in the portfolio runbooks' wave plans, using metadata from their portfolio runbooks.
- Health-Check Matrix for Large Migrations - Use this matrix regularly and frequently to evaluate your status to ensure everything remains on track.
This figure illustrates an immigration factory typically seen during mass migrations.
These runbooks form the backbone of the factory and create an information flow between two major workstreams - portfolio and migration - as detailed by AWS migration Foundation Playbooks.
However, rather than seeing waves move through all areas at the same time, most teams tend to focus on certain parts of migration factories while work streams flow freely; their duration varies based on project scope and timeline - migration could last two to five weeks while portfolio three weeks respectively;
ensure you have adequate server waves available before beginning migration by setting aside five server waves in advance of migration workstream.
To ensure optimal supply chain issues don't occur within migration factories, it is best that your migration factory works by having sufficient server waves available before starting the migration. Workstream 3.0 will cover every possible contingency that should arise from this workstream process!
This figure illustrates an average migration factory. Migration work streams usually last 3-4 weeks, while portfolio workstreams take between one to two weeks per wave to complete planning.
There are typically five waves between workstreams; once stage one initialization completes wave planning for all locks, there should be five waves between portfolio and migration workstreams before entering stage 2 implementation; migrating apps indicate you have entered stage two performance, where both continue processing waves with buffers to prevent running out of servers before migrating apps can continue as scheduled.
Read More: Aws Cloud Application Development Is The Top Choice For Businesses Why?
Migration Strategies
Migration Strategies refer to methods employed for migrating workloads on AWS cloud servers. The 7 R Methodology outlines seven migration approaches businesses use to move applications onto cloud environments.
- Retire
- Retain
- Rehost
- Relocate
- Purchase
- Replatform
- Refactoring or re-architecting
Rehosting, replatforming, relocation and retiring are popular approaches for large migrations. Refactoring should only be utilized on applications that already use modernization while migrating; otherwise, it becomes one of the more complicated strategies and can become impossible to manage with many apps requiring migrations.
We advise clients to use any one of these four strategies first before modernizing an app after migrating it if desired.
Migration strategies must be chosen carefully when embarking on any large-scale migration project. You should carefully consider each migration strategy during mobilization or initial portfolio analysis.
In this section, we explore each migration approach in detail and their most prevalent uses.
Retire
Migration strategies offer a versatile method for archiving or decommissioning applications, retiring them by switching off all servers involved - these are some common applications of the retire strategy.
- Maintaining or moving an application does not represent good value to the business.
- Are you seeking ways to lower an application's hosting and maintenance costs?
- If you want to reduce the security risks when using applications that use outdated components or OS versions, Software mustn't utilize them.
- Under certain conditions, it may be desirable to delete applications based on performance considerations. You could consider retiring apps that use less than five percent of CPU or memory usage on average over 90 days (Zombie apps); you might also decide to retire applications that average between five and 20 percent usage rate on average over this same time frame (idle apps); usage and performance information from your tool can help identify both zombie and inactive apps for removal from your system.
- Since September, no one has used our application.
For more details, refer back to Best Practices to assess applications that will be retired during an AWS migration into the Cloud.
Retain
Use this strategy to migrate applications you do not intend to resettle in their entirety or would prefer to keep in their source environment.
However, they could potentially be moved later.
Below are a few common applications of retention strategies.
- Security and Compliance - To adhere to data residency laws, you may be required to store applications.
- Risky - you should carefully evaluate whether keeping an application requires extensive evaluation or migration planning before deciding.
- If migrating other applications first is necessary before migrating one application, it might make more sense to keep its original format than migrate from scratch.
- Recent Upgrades - It may be advantageous if you recently upgraded your system to wait until the next migration to make any adjustments.
- Migrating applications used by only internal users into the Cloud may not be a wise business decision.
- Planning Your SaaS Migration. When considering moving to Software as a Service (SaaS), you have options. One option could be waiting until a vendor releases its SaaS release before keeping what you currently use until their version becomes available; vendors often utilize this approach when offering SaaS releases.
- Physical Dependencies That Need Resolving - For example, you might choose to keep an application that relies on hardware unavailable through cloud hosting, such as machines in a factory.
- Before migrating these applications into the Cloud, they must undergo careful assessment and planning. Before migration, mid-range examples such as Oracle Solaris or IBM AS/400 should also be assessed.
- Performance - Performance may be of primary concern when selecting applications to keep. Perhaps zombie or inactive applications need to remain within your source environment.
Rehost
Lift and Shift migration strategies allow for smooth migrations from source environments into AWS Cloud without modifications, for instance, moving an app stack directly.
Rehost provides an efficient method to seamlessly migrate multiple computers across platforms (physical or virtual) into AWS Cloud without worrying about compatibility issues, performance disruptions, lengthy cutover windows or data replication across long distances.
As part of your migration effort, users will continue using your application as usual - thus limiting downtime and disruption during this phase.
Your cutover strategy will determine its exact duration.
Strategy 3 allows you to expand the scale of your application without incurring costly or time-consuming cloud optimizations, potentially saving both money and effort.
When running applications on AWS, optimizing or redesigning their architecture as necessary becomes much simpler and faster.
- Use one or more of these services to automate the rehosting process:
- Amazon Web Services Application Migration Service.
- Factory Solution to AWS Cloud Migration.
- VM Import/Export Rehost is an AWS Prescriptive Guidance website offering migration patterns.
Relocate
Relocating servers containing several applications from an on-premises version to the cloud platform - each hosting one or more apps - using this strategy allows for large-scale server migration from on-premises versions into cloud platforms like AWS.
Relocating can move objects or instances between virtual private clouds (VPC), regions (AWS Region), accounts and accounts (VMware Cloud on AWS is one example); you could even transfer an Amazon Relational Data Service Database such as RDS into another VPC/Account altogether!
Relocate allows you to move workloads quickly without purchasing new hardware or rewriting applications, eliminating downtime and disruption for users while minimizing downtime during migration.
Furthermore, Relocate doesn't impact application architecture, so it can speedily relocate them onto cloud servers. See Relocate on the AWS Prescriptive Guidance site to access migration patterns.
Purchase
Drop and Shop refers to replacing an application or product with another version or version that offers more value to the business than currently, such as accessibility from anywhere and no infrastructure maintenance expenses required, with pay-as-you-go pricing models that make life easy for companies.
Repurchasing can save costs associated with infrastructure licensing maintenance expenses or expenses related to IT software licensing maintenance contracts, etc.
Here are a few possible scenarios of repurchase migrations:
- SaaS provides an attractive alternative to traditional licensing arrangements, reducing costs while eliminating infrastructure management responsibilities.
- Upgrades or equivalent applications from third parties - You can use new features by updating to a vendor release or equal application available online, giving your on-premises version access to cloud services and taking advantage of cloud integration features.
- Replace an obsolete application. Instead of recreating, custom-coding or redesigning one yourself, purchasing an off-the-shelf SaaS vendor app may provide the required solution.
- Before purchasing an app for business use, its requirements must meet specific security and compliance criteria.
Step two is purchasing your application.
- Train both staff members and end users on your new system.
- Migrate Data into New Application
Integrate the application with authentication services like Microsoft Active Directory for centralized authentication.
- Configuring your network to secure communications amongst applications purchased, users and infrastructure components.
- Application providers usually assist their users to ensure a seamless transfer.
Replatform
Lift, Tinker and Shift or Lift and Shape describes an approach for migrating applications to the Cloud which involves moving an application there and making some optimizations to run more efficiently, reduce costs or take full advantage of all its capabilities - for instance, re-platforming Microsoft SQL Server databases onto Amazon RDS SQL Server as part of this migration strategy.
Your app changes can depend upon its business goals and target platform. You have complete freedom in tailoring the amount and scope of changes accordingly.
Here are a few scenarios of Replatform Migrations:
- If you want to reduce costs and save time, serverless or fully managed services on AWS Cloud may be your perfect solution.
- Upgrade to ensure compliance and enhance security by upgrading to an operating system version that meets compliance and improves security standards. Using the End-of-Support Migration Program for Windows Server to migrate legacy apps without making code modifications or consult the AWS User Guide for Windows Server EMP to assist in assessing workload needs for EMP environments.
- Graviton processors from AWS can help your organization lower costs significantly.
- Moving away from Microsoft Windows and onto Linux could save money. Your Framework app could easily be converted to run on a Linux OS using Porting Assistant's tool to do just this.
- Virtual machines and containers can be seamlessly migrated seamlessly using AWS App2Container to convert.NET or Java applications into containerized apps.
- Replatforming provides an effective method to keep legacy apps operating while adhering to security and compliance measures, improving performance and decreasing costs through managed services, virtual machine containerization and licensing fee elimination. Replatform is an online database listing migration patterns available for your platform strategy.
Re-architect or Refactor
This strategy offers businesses an approach that allows them to move their applications to the Cloud, adapt their architecture as necessary and utilize all available cloud-native features - to aws cloudfront increase agility, performance and scalability, ultimately meeting business requirements such as faster product releases with lower costs.
Here are a few common use cases of the Refactor Migration Strategy:
- Your current solution may either be too expensive for your business needs or have limitations to meet them.
- Your legacy application may already thwart your efforts to meet customer demands or deliver products quickly.
- An older application's source code has gone missing, or no one can maintain it.
- Test coverage or difficulty may be low for an application you are testing, which could compromise its delivery and quality of fixes and new features. You can increase test coverage through automation testing and redesigning it to run in the Cloud.
- As part of your cloud migration for security or compliance reasons, some tables may need to be deleted - including customer info tables, patient tables and diagnosis databases. You will also need to redesign the database to distinguish those that will move versus those that will stay behind on-premises.
- See "Re-architect" within the AWS Prescriptive Guidance site to review migration patterns.
Want More Information About Our Services? Talk to Our Consultants!
Conclusion
Assess and mobilize are at the core of every large migration. They help prepare an organization for migration. This guide offers a summary of these two initial phases and references to additional resources.
Its primary goal is to explain migration in terms of Modernize (phase three of Migration & Modernize), with two stages (Initialize & Implement). To maximize efficiency when migrating workloads to AWS first and upgrading later. Note: this documentation does not cover modernization for large migrations - for more details, visit AWS Prescriptive Guidance site.
