Mobilize
The mobilize phase involves setting up the resources and tools needed for the migration. During this phase, the team impacted by the migration are trained to handle the migration. Have a backup plan ready in case anything unexpected happens.
| MIG-REL-04: Have you reviewed service quotas and constraints for new migrated resources? |
|---|
Service quotas exist to prevent accidentally provisioning more resources than you need, and to limit request rates on API operations so as to protect services from abuse. For more detail, see Manage service quotas and constraints. Migrations can add new resources to existing accounts and therefore affect service quotas. Migration services have quotas which can affect the speed migrations can be performed.
MIG-REL-BP-4.1: Be aware of service quotas and constraints for migration services
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 4.1.1: Review service quotes for AWS Application Migration Service and AWS DMS, as these can affect the sizing of your migration waves and number of operations which can be performed simultaneously.
For example, you can only migrate 200 servers within one job. Hitting limits for these services can disrupt migration plans.
MIG-REL-BP-4.2: Estimate the impact of new workloads on existing service quotas across accounts and Regions
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 4.2.1: Review service quota values that would breach if new migration workloads are added to an account.
For example, adding many new EC2 instances into a VPC can cause the soft limit network interfaces per Region (default 5000) to be reached. Request limit increases for such quotas before your migration events.
MIG-REL-BP-4.3: Be aware of unchangeable service quotas and how you determine which accounts or VPCs workloads use
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 4.3.1: Depending on the migration scope, you may have to split workloads into multiple AWS accounts or VPCs to avoid hitting unchangeable service quotas.
| MIG-REL-05: How do you plan your network topology for migration activity? |
|---|
Workloads often exist in multiple environments. It could be between multiple cloud environments and your existing data center. During the migration planning phase, include network considerations, such as intra-system and intersystem connectivity, public IP address management, private IP address management, and domain name resolution.
MIG-REL-BP-5.1: Provide sufficient bandwidth for normal and traffic from data replication
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.1.1: Replication traffic may need to be throttled so it does not overwhelm network links.
For more detail, see Data routing and throttling and Improving the performance of an AWS DMS migration.
MIG-REL-BP-5.2: Assure that links and equipment to on-premises are highly available
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.2.1: If network connectivity is disrupted, migration replication may need to be restarted. Use multiple AWS Direct Connect connections or VPN tunnels between separately deployed private networks.
Use multiple Direct Connect locations for high availability. If using multiple AWS Regions, ensure redundancy in at least two of them. You might want to evaluate AWS Marketplace appliances that terminate VPNs. If you use AWS Marketplace appliances, deploy redundant instances for high availability in different Availability Zones.
MIG-REL-BP-5.3: Verify that your network design enables communication between on-premises and cloud networks
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.3.1: Design networks to prevent overlapping IP addresses with your on-premises network.
Select new IP ranges to be assigned to AWS VPCs which do not clash with any existing networks. Even though some networks may eventually by freed by the migration, both networks are in use during the migration and difficult to free up until the end of the migration.
Suggestion 5.3.2: Not all networks need to be routable to on-premises.
To preserve routable IP space, non-routable CIDR ranges can be used. For more detail ,see Preserve routable IP space in multi-account VPC designs for non-workload subnets.
MIG-REL-BP-5.4: Use an IP scheme that allows for sufficient growth within cloud workloads and burst auto-scaling
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.4.1: Amazon VPC IP address ranges must be large enough to accommodate workload requirements, including factoring in future expansion and allocation of IP addresses to subnets across Availability Zones.
This includes load balancers, EC2 instances, and container-based applications.
MIG-REL-BP-5.5: Complete a reliable DNS design that enables resolutions to existing domains, plus new domains in AWS
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.5.1: DNS resolution between multiple AWS Accounts and on-premises is fundamental for application communication.
For more detail, see designs for single-account and multi-account hybrid DNS resolutions. During any multi-phase migration, on-premises applications need to talk to migrated applications through DNS, and migrated applications need to talk to on-premises applications. For more detail, see Automating DNS infrastructure using Route 53 Resolver endpoints
Suggestion 5.5.2: Windows workloads require DNS for active directory (AD).
For rehost (lift and shift) migrations, the same AD domain needs to be resolvable in both on-premises and cloud environments. To avoid affecting the production environment during testing windows server migrations, machine password rotation and dynamic DNS updates should be disabled
Suggestion 5.5.3: Plan for how to update DNS records during migration testing and cutovers.
Some systems (like Windows) can update dynamically, while others require manual updates. Provide the migration team access to update DNS records or develop automated processes.
MIG-REL-BP-5.6: Test network performance prior to migration
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.6.1: Network latency has varying effects on applications.
Testing how migrated applications respond to the new networking environment can be performed using distributed load testing and monitoring performance metrics.
MIG-REL-BP-5.7: Test network component failure
This BP applies to the following best practice areas: Foundations
Implementation guidance
Suggestion 5.7.1: Network outages have varying effects on applications.
Testing how applications respond to connectivity events can be performed using AWS Fault Injection Service. For more detail, see Tutorial: Simulate a connectivity event.
| MIG-REL-06: How do you back up data on migrated workloads? |
|---|
Back up data, applications, and configuration to meet requirements for recovery time objectives (RTO) and recovery point objectives (RPO). Backup capabilities of cloud environment will differ from on-premises.
MIG-REL-BP-6.1: Identify and back up all data that needs to be backed up, or reproduce the data from sources
This BP applies to the following best practice areas: Workload architecture
Implementation guidance
Suggestion 6.1.1: Validate that your backup process implementation meets your recovery time objectives (RTO) and recovery point objectives (RPO) by performing a recovery test both before and after the migration.
For more detail, see the following:
| MIG-REL-07: Are your migrated workloads utilizing fault isolation? |
|---|
Your workload must operate reliably despite data loss or latency in these networks. Components of a migrated workload can use AWS capabilities to design the workloads in more fault-tolerate ways. Follow these best practices to ensure your migrated workloads are fault-tolerant.
MIG-REL-BP-7.1: Deploy the workload to multiple locations
This BP applies to the following best practice areas: Workload architecture
Implementation guidance
Suggestion 7.1.1: Follow the best practices (BPs) in the Reliability pillar to distribute workload data and resources across multiple Availability Zones or, where necessary, across AWS Regions.
These locations can vary as required by your business requirements. Always (when possible) deploy your workload components to multiple AZs for high availability. For components that can only run in a single AZ, implement the capability to do a complete rebuild of the workload within your defined recovery objectives.
For more detail, see the following:
