# Platform foundation
This section focuses on assessing the readiness of the on-premises infrastructure, preparing the AWS landing zone or reviewing the existing landing zone design, and identifying the migration tools needed. You review the common infrastructure, operations, and security questions that you should consider for building a platform. You document your answers and decisions as migration principles. As a result, you have a solid platform to achieve the scale and velocity required for large migrations.
This section includes the following topics:
+ [Landing zone considerations for a large migration](landing-zone.md)
+ [On-premises considerations for a large migration](on-premises.md)
+ [Document your migration principles](document.md)
# Landing zone considerations for a large migration
A *landing zone* is a well-architected AWS environment that is scalable and secure. By establishing standards for the landing zone, such as defining the number of accounts and designing the subnets and security groups, you build a solid foundation. This foundation gives you the ability to enable, provision, and operate your environment for both business agility and governance at scale while accelerating your cloud adoption journey. For more information about landing zones and strategies for building them, see [Setting up a secure and scalable multi-account AWS environment](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/).
In addition to the standard business, operational, security and compliance considerations for your landing zone strategy, you must consider how to facilitate a large migration. You must design the landing zone to support existing, on-premises workloads during the migration and after, in cases where some workloads remain on premises. This guide provides additional landing zone considerations that affect the migration velocity and overall migration timeline.
Typically, landing zones are designed and deployed to support new workloads in the AWS Cloud. This is because organizations are adopting AWS before making the decision to migrate a large number of existing applications. The benefit of this approach is that the organization gains valuable knowledge and skills in AWS before the large migration, but it can also lead to conflicts between the various stakeholders. Some stakeholders might want to modernize the application during the migration because they want to take advantage of cloud-native features. However, the common goal of a large migration is to achieve maximum migration velocity and ease the transition by migrating as many applications as possible without modifying the workload. You then modernize these applications after the migration is complete.
Some key factors of the landing zone that can affect your large migration program project are:
+ Network bandwidth availability and management
+ Account strategy for workload isolation and resource management
+ Security and administrative controls for migrated workloads
This section reviews the infrastructure, operations, and security questions that you should consider when building your AWS landing zone. It also contains recommendations for how to design and deploy your landing zone to support a large migration project. As you answer the questions in this section, these decisions become migration principles, which you document according to the instructions in [Document your decisions as large migration principles](document.md).
## Infrastructure considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| How much data will you migrate per day and per week? | The desired migration velocity dictates the type of network connection and network throughput requirements. It also can affect the wave planning selection criteria. | After you have completed the portfolio assessment, determine the total amount of storage needed for all migrated resources in the cloud. Use this value to calculate the amount of time required to migrate the data using the current network bandwidth. You might need to increase the bandwidth to meet the migration timeframes, or you might need to use alternatives, such as AWS Snow Family solutions. In the [foundation playbook templates](samples/foundation-playbook-templates.zip), you can use the *Data replication calculator* (Microsoft Excel format) to calculate the required bandwidth for each migration wave. |
| What is the average write speed of the source servers in each wave? | The bandwidth required to transfer the replicated data is based on the write speed of the participating source servers. The amount of bandwidth required for server replication is the average write speed of your source servers multiplied by the number of servers in the largest wave. | During portfolio assessment, you need to determine the average number of data writes performed per by each server. In the [foundation playbook templates](samples/foundation-playbook-templates.zip), you can use the *Data replication calculator* (Microsoft Excel format) to understand the bandwidth required for migration traffic. The bandwidth required for migration traffic is in addition to the bandwidth used for normal business activity. After the migration is complete, you no longer need the additional bandwidth to support the migration activities. |
| Could additional network activities or existing infrastructure limit or reduce the replication speed? | If the network bandwidth also supports other business functions, these activities can reduce the amount of bandwidth available for replicating servers during the migration. | Early in the project lifecycle, carefully assesses and calculate the network bandwidth required to support all business activities. Consider the bandwidth needed for normal business activities, server replication, and new migration-related activities, such as syncing on-premises file shares with data on AWS. Providers might have long lead times to increase the network capacity, and you might need to upgrade the existing on-premises infrastructure. Consider whether any additional upgrades would be required as a consequence of upgrading the network infrastructure. Assessing bandwidth requirements early in the project provides time to make any necessary changes. |
| Does your current AWS subnet strategy meet the IP addressing requirements for migrating the on-premises workloads? | The number of servers and workload isolation requirements dictates the subnet strategy for your landing zone. Large migrations might require larger subnets than you expect. In a large migration, you group workloads in subnets similar to their setup in the on-premises infrastructure. To simplify the migration, larger, flatter subnet designs are preferred initially, and then, during modernization, you redesign the subnets as needed. | When the portfolio assessment has enough information about the infrastructure inventory, assess the on-premises network structure and incorporate it into the landing zone design as early as possible. |
| How many servers do you plan to replicate and migrate in parallel? | The size of the largest migration wave affects the subnet requirements and [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). | Review the high-level migration plan, and use that to design your subnet. For example, if you have a plan to migrate 200Â servers into one subnet, the Classless Inter-Domain Routing (CIDR) range for that subnet should have enough IP addresses to support the target number of servers. Also, increase the AWS service quota for each target account as needed. |
| Have you identified the security group strategies for your migration resources? | Security groups are used to manage the inbound and outbound traffic for AWS resources. It is important to design security groups early in order to avoid delaying the migration. | In your runbook for application prioritization, review the migration strategies, and then design the security groups based on the migration strategies. For example, if the migration strategy is to rehost most of the workloads, consider a temporary, generic security group that supports migration cutover instead of refactoring the network and applying application-specific security groups. |
| Are there load balancers in use? | Typically, when migrating servers in an environment with load balancers, you need to assess the configuration of the load balancer and then migrate the load balancer. Migration options for the load balancer include using Elastic Load Balancing (ELB) or a partner appliance-based solution. | Assessment of load balancers needs to start early in the discovery phase in order to account for any custom configurations. In most environments, load balancer configurations are fairly standard, but some might have complex logic that determines whether you can migrate to ELB or a partner appliance-based solution. |
| Do any servers need to retain their source IP address? | The safest and easiest way to migrate servers to the cloud is to allocate new IP addresses to the migrated instances. In some situations, you might need to keep the same IP address as the source server. For example, a legacy application might have a hardcoded IP address that no one knows how to change. | Keeping source IP addresses affects how you form move groups when wave planning. The most common approach is to migrate a whole subnet to AWS in a single move group because this makes routing and switching straight-forward at the network level. The following are key actions for keeping IP addresses: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html) |
| How much latency is acceptable between the source and AWS? | It is common to start the migration with VPN links because they can be set up quickly and then transition to a direct connection established using AWS Direct Connect. VPN links generally have higher and more variable latency, which affects data throughput and, more importantly, application response times. | If you are using a high or variable latency connection type, review each application’s requirements and plan the migration waves accordingly. Plan to put applications that require low latency connections in later waves, when alternative connection types are available. |
## Operations considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| Have you identified an AWS account strategy for your landing zone? | AWS best practices for a well-architected environment recommend that you should separate your resources and workloads into multiple AWS accounts. You can think of AWS accounts as isolated resource containers: they offer workload categorization and can reduce the scope of impact in the event of a disaster. | In your runbook for application prioritization, review your selected migration strategies and use them to determine your account strategy. For example, if you want to migrate as quickly as possible and rehost is the most common migration strategy, fewer accounts is easier to manage. However, if your migration strategies require modernizing applications and you need to separate business units for compliance reasons, you should include one or more accounts for each business unit in your account strategy. |
| Do you need to switch monitoring tools during the migration? If so, is this part of the migration process, or does it occur before or after the migration? | Monitoring tools are critical for cloud operations. Your existing tools might not work in the cloud because of compatibility or licensing reasons. As part of the design, you need to decide which monitoring tools to use for the workload in the AWS Cloud. | Select a monitoring tool before starting the migration. Make sure the migration team incorporates instructions for setting up monitoring in the migration patterns. We recommend building an automation script that replaces or reuses the monitoring tools, as needed. |
| Have you identified application owners, and are they aware of any changes that must be made to the application so that it functions properly in the cloud? | Large migration is a transformation rather than just an infrastructure project. Include application owners early to support the migration. For example, application owners validate the wave plan, create test plans, and participate in the cutover. | Work with a project management office and Cloud Enablement Engine team to align with application team leaders and make sure that communication is clear across all application teams. For more information about communication and project transparency, see the [Project governance playbook for AWS large migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/). |
| Have you selected a backup and recovery solution, and does it work with migrated workloads? | Backup and recovery tools are critical for cloud operations. Your existing tools might not work in the cloud because of compatibility or licensing reasons. As part of the design, you need to decide which backup and recovery tools to use for the workload in the AWS Cloud. | Select backup and recovery tools before starting the migration. Make sure the migration team incorporates instructions for setting up backup and recovery in the migration patterns. We recommend building an automation script that replaces or reuses the backup and recovery tools, as needed. |
| Have you identified all shared services and deployed them in the landing zone? | *Shared services* are services that support multiple applications, such as email, Active Directory, or shared database environments. You typically need to deploy shared services in the cloud before the migration so that migrated applications perform as expected. | Schedule a deep dive with the infrastructure team and application team leaders before completing the landing zone design. Review and confirm the list of shared services that you must deploy in the cloud before starting the migration. The most common shared services are Active Directory, network devices, Domain Name System (DNS), and infrastructure software. |
| Have you reviewed AWS service quotas for your target AWS Region and account? | Every AWS service has a service quota. Some of these quotas can be increased. It is important to review quotas before cutover. If insufficient resources are available, the cutover might fail. | Review the migration plan. For any target account that requires an increased service quota, request an increase. For more information and instructions, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). |
| Do you need to upgrade your AWS Support plan? | AWS Enterprise support plan offers 24/7 phone support and faster response times than other plans. Because the cutover window is usually very short, having access to an experienced engineer to help resolve cutover issues can be critical to the success of a large migration. | Contact your AWS account team to discuss different support options and select the appropriate support plan for your large migration project. |
| Have you notified your AWS technical account manager (TAM) about your large migration plan? | The AWS Enterprise On-Ramp support team assigns a pool of Technical Account Managers (TAMs) who coordinate access to proactive programs, preventative programs, and AWS subject matter experts. Your TAMs can schedule availability of support resources as needed. | Notify your AWS technical account manager of your upcoming large migration project and share your migration plan. Your TAMs will make sure AWS support resources are available when needed. For example, your TAMs can schedule a support engineer during cutover, and the engineer can help mitigate technical issues and streamline the cutover. |
## Security considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| Have you identified AWS Identity and Access Management (IAM) roles and policies for access management? | Manage identity and access for all members of your large migration project. By attaching IAM roles to the migrated resources and defining access policies, you control who can access the migrated resources in the cloud. | Work with the migration team to identify the roles and responsibilities. Determine which roles can access which AWS account, and identify the level of access that each role has. Work with the security teams to validate that the IAM roles are correct for each target AWS resource. |
| Are there any compliance requirements for your workloads? | Workloads might have different compliance requirements, such as the Health Insurance Portability and Accountability Act (HIPAA) or payment card industry Data Security Standard (PCI DSS). You must identify these requirements before the migration and plan for how to meet them. | Work with compliance team and portfolio team to identify the compliance requirements for each application, and design your target AWS account accordingly. For example, you might need to migrate some workloads to AWS GovCloud (US) or to a specific AWS Region. We recommend that you document the compliance requirements for each application so that you can use this information later in the application prioritization and wave planning process. |
| Does your security team need to review and approve any tools or services that you plan to use during the migration? | A large migration project to the AWS Cloud uses many services, such as AWS Application Migration Service, AWS Database Migration Service (AWS DMS), AWS DataSync, and portfolio discovery tools (such as Flexera One). Some organizations require that all new tools and services are approved before use. | Work with the migration team to identify all of the tools, services, and applications that you expect to use in the migration. Work with the security team to review the company policies and approve these tools accordingly before the migration starts. |
# On-premises considerations for a large migration
On-premises infrastructure that supports your business operations must also be prepared for the large migration. By preparing the current infrastructure, you can help reduce the impact of the large migration to the business operations and application users.
This section reviews the infrastructure, operations, and security questions that you should consider when preparing your on-premises infrastructure for the large migration. As you answer the questions in this section, these decisions become *migration principles*, which you document according to the instructions in [Document your decisions as large migration principles](document.md).
## Infrastructure considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| Have you designed the on-premises DNS and routers to support traffic to and from target AWS accounts? | Because of the large number of servers and target AWS accounts, it is important to confirm that different networking components are configured correctly to support the migration strategies and scale. | Review the design of routing tables, and make sure there are correct routes between the AWS accounts and on-premises data centers. Also, make sure the DNS server is able to support DNS queries from both on-premises servers and AWS resources. |
| How will the migration team access both the on-premises and AWS environments? | The migration team needs to access the source and target servers to perform migration activities, such as install a replication agent on a source server or uninstall old software on a target server. | Review the existing authentication and authorization mechanisms and build a strategy to grant access. You can use an Active Directory group, IAM role, and Security Assertion Markup Language 2.0 (SAML 2.0) federation to allow single sign-on to the AWS account. We recommend creating a local admin user in case there are any authentication issues with Active Directory. |
| Are there any known congestion points in the current network configuration that would slow data throughput during the migration? | A large migration requires lots of bandwidth to replicate the data from on-premises data center to the cloud. Understanding any existing congestion points or limitations helps you better plan the migration. | Review the network configuration with the networking team to better understand the network path from the source machines to the target AWS accounts. Identify potential congestion points, such as a connection that is shared between the migration and production workloads. |
## Operations considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| Do you have any scheduled blocked days, also known as *change freezes*, that could impact the migration? | A change freeze during migration can take critical resources and time away from an ongoing migration project. | Review the change management process with the operations team, and take blocked days into consideration when you plan cutover windows. |
| Have you reserved change days for the migration? | Change management processes can be complex, and some organizations allow changes only in certain maintenance windows. | According to your change management process, schedule changes at least five waves in advance. This helps prevent delays |
| Have all of the servers in scope for the migration been recently rebooted? | System changes or uninstalled patches might cause issues during the migration, which would necessitate long cutover windows or rolling back the server. The best practice is to confirm that the server has been recently rebooted on the target side before migrating. | Review the dates of the last server reboots. If a server has not been restarted within the last 90 days, schedule a restart before migrating the server. |
| How does the disaster recovery and business continuity plan work today, and has this been factored into the landing zone design? | Disaster recovery and business continuity plans are critical components of meeting the recovery time objective (RTO) and recovery point objective (RPO) of the application. You need to make sure these plans work for both your on-premises and AWS workloads during the transition period. | Review the existing disaster recovery and business continuity plans and make sure the plans work for your target AWS account. If not, design new plans before moving workload to the AWS Cloud. |
## Security considerations
| Have you considered? | Description | Actions |
| --- | --- | --- |
| Have you created firewall rules to support the large migration? | Depending on the processes in your organization, it can take a long time to complete a change request for firewall configurations. | Review the existing firewall change process with security team, and design a strategy for large migration firewall changes accordingly. You might need to design a custom process for the large migration project, or you might need to submit changes early in the project. It is recommended that you consider using an AWS virtual private cloud (VPC) as an extension to your data center and avoid building firewall rules that are too complex, which could significantly delay the large migration. |
| Have you set up Active Directory in the AWS environment? | Active Directory is used for authentication and authorization. You need to make sure the target account workloads are able to connect to the domain controller for authentication and authorization. You can either add a new domain controller in the target VPC, or you can allow the AWS workload to connect to the on-premises domain controllers. | Review the Active Directory design with your security and infrastructure teams. Make sure the target AWS account has connectivity to the correct domain controller. Make sure that the target AWS subnet CIDR blocks are in the correct Active Directory sites so that the workloads in AWS are able to connect to the nearest domain controllers. |
| Have you identified third-party connections and application interdependencies? | Third-party connections and application interdependencies require that you modify the firewall rule, network access control list, and security group. | During the deep dive session with the application owners, review the external dependencies for each application. Submit a request to modify firewall rules and the network access control list and change security groups accordingly, based on the third-party dependency requirements. |
| Does your on-premises environment have any additional security tools that control access and processes running on the systems, such as CyberArk? | You might need to assess and update these security tools in order to allow the migration tools to function in the AWS landing zone. | Review the access policy in your source environment. If a security tool is being used in the access policy, confirm that the tool functions in the AWS Cloud, and then make sure that the migration team has access to both the source and target environments. If any changes are required, add these steps into your migration runbooks. |
# Document your migration principles
After reviewing the landing zone and on-premises considerations, you should document your answers and decisions. These become the migration principles that guide the rest of the project.
Do the following:
1. In the [foundation playbook templates](samples/foundation-playbook-templates.zip), open the *Migration principles template* (Microsoft Word format).
1. Review the infrastructure, operations, and security considerations in the [Landing zone considerations for a large migration](landing-zone.md) and [On-premises considerations for a large migration](on-premises.md) sections of this guide, and discuss the questions with the recommended teams.
1. Document the infrastructure, operations, and security decisions in your migration principles document. For examples of how to record these decisions, see the following table.
1. As needed for your use case, add new categories, items, and principles. For example, you might want to record migration principles for portfolio assessment or project management decisions.
The following is an example of how you might record your decisions to some of the questions in this guide.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)