Introduction

Have you struggled to restructure your cloud infrastructure during a business transformation? As Technical Account Managers (TAMs) from AWS Enterprise Support, we’ve successfully guided many enterprises through complex cloud migrations. We’ve also seen firsthand how migrating AWS Organizations accounts between different organizational structures can be both challenging and transformative. Our approach stems from lessons that we learned from migrations across industries, where understanding the nuanced challenges is as important as knowing the technical steps. With the right approach, you can minimize disruption and optimize your cloud strategy.

In this article, we discuss the considerations, recommendations, and approaches for migrating AWS accounts between organizations. This includes how to assess your current organization architecture to determine the best approach for migrating to the new organization. It also includes how to plan the necessary steps and changes, and how to run the migration. These steps require collaborations with the internal and external teams that start 90 days before the migration.

AWS Organizations helps you centrally manage and govern your AWS accounts. You can manage your organization structure, use policies to define configuration and governance, handle consolidated billing, and control features of integrated AWS services. As your business evolves, your AWS environment might need to adapt for several reasons. These reasons include response to mergers, acquisitions, or divestitures, separation of production and non-production workloads, introduction of new architectural patterns, or new policies for management and governance.

Solution overview

Assess

Before you plan your migration, review the following foundational AWS Organizations concepts:

• An organization includes two types of accounts: a single account designated as the management account, and one or more member accounts. The management account is used to create the organization, and member accounts are linked to only one organization at a given time. An AWS account that doesn't belong to any organization is a standalone account.

• You can't migrate a member account directly from one organization to another. First, you must remove the account from the source organization and make it a standalone account. Then, you can accept an invitation to join the destination organization. 

• If you need to migrate the management account from the source organization, then you must delete the organization. Before doing this, make sure to close or remove all the accounts from the organization. The organization must not include any accounts before its deletion. The management account must be the last account that you migrate. For more information, see Migrating an account to another organization with AWS Organizations.

• Historical AWS Cost Explorer reporting for the source organization is lost. Before you start the migration, make sure to export reports.

• Some services might offer billing in increments as small as seconds. However, bills are calculated hourly. If an account leaves one organization (for example, at 11:04) and joins a new organization within the same hour (for example, 11:13), then all costs for the hour are charged to the destination organization. The standalone account doesn't incur any charges.

• Reserved Instances (RIs) and Savings Plans are often attached to the management account and shared within the organization. RIs and Savings Plans are applied to the accounts hourly. To reduce your charges, migrate the source management account during the same hour as the accounts with the highest spend. After the account is migrated to the destination organization, share the RIs and Savings Plans discounts with the accounts in the destination organization. For more information, see Reserved Instances and Savings Plans discount sharing. 

• If RIs or Savings Plans expire during the planning phase, then you can renew them within dedicated Financial Operations (FinOps) accounts. This is covered in detail in the next section of the article.

Plan

Make sure that you have the appropriate landing zone in place to support your migration:

• Follow best practices to protect the management account in your destination organization.

• Set up a landing zone in the destination organization manually or with AWS Control Tower.

• Consider creating a dedicated Organizational Unit (OU) within the destination organization. Make sure that you attach Service Control Policies (SCPs) to this OU that either allow all actions or are similar to the source organization's SCPs. During the migration, AWS accounts can be initially included in this OU to minimize the risk of SCPs adversely affecting the recently migrated AWS account.

• Be aware of SCPs that are applied to the organization root and how they affect the migrating accounts. Ideally, SCPs are applied at the OU level. This is to make sure that an OU receives the migrating accounts without conflicting SCPs. When you migrate the account to the new organization, all account-level SCPs aren't attached to the account. You can attach a maximum of five SCPs to root, OU, or account. If you need to attach more SCPs, then consider nesting OUs.

• Apply these foundational SCPs where appropriate. For more examples of SCPs, see service-control-policy-examples on the GitHub website.

  • Restrict member accounts from leaving the organization.
  • Restrict member accounts from turning off services, such as AWS CloudTrail, Amazon CloudWatch, and Amazon GuardDuty.
  • Restrict Regions and instance types.
  • Restrict the ability to modify or assume elevated AWS Identity and Access Management (IAM) roles.
  • Restrict the ability to add an internet gateway to a virtual private cloud (VPC).

• Create one or more FinOps accounts in the new organization. You can attach RIs and Savings Plans to these accounts. This provides the flexibility for any future account migrations between organizations. If the plan calls for a phased approach to member account migration, then you can migrate one or more of these FinOps accounts in each phase to maximize the application of RIs and Savings Plans.

Migrate

Make sure that you have sufficient time to properly stage and complete your migration activities.

Complete the following actions 90 days before you start the migration:

• Use the Account Assessment for AWS Organizations solution to identify organization dependencies, such as delegated admin accounts, trusted access, and resource-based policies that use the PrincipalOrgID condition key.

• Check with your integration partners to confirm if they're using your source organization's ID. Work with the partners to update the configuration of any affected integrations during or after the migration.

• Check AWS service and policy dependencies. For more information, see the AWS Organizations Trusted Access section in AWS Organizations, moving an organization member account to another organization: Part 3.

• Check if any AWS services use a delegated administrator. For more information, see the AWS Organizations Delegated Administrator section in AWS Organizations, moving an organization member account to another organization: Part 2.

• Audit network configurations for services that are shared through AWS Resource Access Manager (AWS RAM), such as AWS Transit Gateway, shared VPCs, and Amazon Route 53 Resolver. If services are shared, then follow the guidance in the AWS RAM resource sharessection in AWS Organizations, moving an organization member account to another organization: Part 1.

• If AWS CloudFormation StackSets are deployed within accounts in the source organization, then see the AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com section in AWS Organizations, moving an organization member account to another organization: Part 3.

• If your source organization uses AWS IAM Identity Center, then see the AWS IAM Identity Center (successor to AWS Single Sign-On): sso.amazonaws.com section in AWS Organizations, moving an organization member account to another organization: Part 2.

• Audit and update the contact information for all member accounts, as needed. For more information, see How do I move an account from an existing organization to another organization in AWS Organizations?

• Evaluate policies that you use in the source organization, such as SCPs, resource control policies (RCPs), AI services opt-out policies, tagging policies, chatbot policies, and backup policies. For more information, see the Management policies section in AWS Organizations, moving an organization member account to another organization: Part 1.

• If required, create a new management account. Then, notify your AWS Account Manager so that they can add the new account number to any existing agreements.

• Determine the number of total accounts in the destination organization. An organization can only include a default maximum of 10 member accounts. If the sum of the number of accounts in the destination organization and number of accounts that you're migrating from the source organization exceeds your current quota, then use the Service Quotas console. Or, contact AWS Support to request an increase to the Number of AWS accounts in an organizationquota.

• Determine if you must migrate all accounts at one time or in a phased approach. Consider trade-offs based on risk, staffing levels, cost, and impact to other projects.

• Confirm that you have access to all accounts. Make sure that you can access the AWS Management Console through root user credentials and the inbox of the root user's email address.

• Don't close any member accounts. The account closure process requires a 90-day waiting period and affects your ability to migrate accounts between organizations. If you must close accounts, then remove them from the organization before closing. Or, migrate the account to the new organization, and then close the account.

• If you're currently enrolled in the AWS Migration Acceleration Program (MAP), then follow these steps to make sure that you continue to earn MAP credits:

  • Gather information about the new management account.
  • Inform your AWS account team of the upcoming change.
  • Create a new Cost and Usage Report in the new management account 48 hours before the migration.
  • Activate tags from the new management account.
  • Tag resources with the new server ID that you generated from the new management account.
  • Plan to migrate at the beginning of the quarter to maximize your MAP credit.

Complete the following actions 60 days before the migration:

• If you're an Enterprise Support customer, then submit a Billing support case from the management account of the source organization. Provide information about the migration to a new organization, and request to move all member accounts to invoicing in anticipation of migration. Include information, such as the company name, contact name, address, city, state, postal code, country, contact phone number, and email address. The email address must be unique for the account.

• If you aren't an Enterprise Support customer, then you must provide a valid payment method (for example, credit card) before removing a member account from an organization. For more information, see Removing a member account from an organization with AWS OrganizationsandHow do I create and activate a new AWS account?

• Validate that the Tax Registration Number (TRN) is set on all accounts, where applicable. Accounts with the same TRN and billing address receive a consolidated invoice. Accounts that don't have a defined TRN, and accounts that have a unique TRN or billing address, receive separate invoices. If the destination organization doesn't use TRN inheritance or contains multiple tax settings, then make sure that the member accounts have the correct tax settings before they join the organization. Check the TRN Inheritance settings of the source and destination organizations in the AWS Billing and Cost Management console. By default, inheritance is turned off for all accounts. For more information on how to update the TRN for your accounts, see How do I add or update my tax registration number or business legal address for my AWS account?

  • If the source organization has inheritance turned off, then the member accounts continue to use account-level tax settings when they leave the organization and become standalone accounts.
  • If the source organization has inheritance turned on, then the member accounts use account-level tax settings when they leave the organization and become standalone accounts. This indicates that the member account doesn't have a TRN associated with it.
  • To configure tax settings at the account level in the source organization, open the AWS Billing and Cost Management console, and then turn off inheritance. Then, choose Tax Settings, choose Manage tax registration, and select Edit all. You can then specify the tax settings for all accounts.
  • If the destination organization has inheritance turned off, then the member accounts continue to use the account-level tax settings after they join the organization.
  • If the destination organization has inheritance turned on, then the member accounts inherit and use the organization's tax settings after they join the organization.

• If you're an Enterprise Support customer, then discuss with your Technical Account Manager (TAM) if an AWS Countdown or AWS Countdown Premium is appropriate.

Complete the following actions 30 days before you start the migration:

• Make sure that you have the required permissions to complete the migration. To do this, create a role in the management account that's used to remove member accounts from the organization. Or, grant a role in each member account the permissions to leave an organization. For more information, see Removing a member account from an organization with AWS Organizations.

• Consider preparing a script to programmatically remove an account from the source organization and accept invitations to the destination organization. For more information, see LeaveOrganization and AcceptHandshake.

• Migrate at least one test account, identify gaps, remediate, and then retest.

• Conduct pre-migration baseline testing on critical workloads.

• Suspend new account creation before the migration. Accounts that are created through an organization can't leave the organization for 7 days after they're created.

To migrate the accounts and validate the outcome, follow these actions:

• Review the rate limits (throttles) for migration activities. Note the throttling limits for InviteAccountToOrganization, RemoveAccountFromOrganization, LeaveOrganization, and AcceptHandshake. For more information, see Quotas and service limits for AWS Organizations.

• To make sure that you have maximum time before bill calculation, initiate the migration of accounts early in the hour. For more information, see the Assess section of this article.

• To make sure that all systems function as expected, repeat the pre-migration baseline testing on critical workloads.

After you complete the migration, complete the following actions:

• Review and accept any appropriate agreements, such as the HIPAA BAA, in AWS Artifact. For more information, see the AWS Artifact: aws-artifact-account-sync.amazonaws.com section in AWS Organizations, moving an organization member account to another organization: Part 3.

• If you used an incoming OU, then set a timeline and plan to migrate member accounts to their permanent OUs.

• If SCP guardrails are minimal or absent, then implement appropriate guardrails. Also, set up a periodic review of SCPs.

Conclusion

This article guides you on how to successfully migrate accounts between organizations in AWS Organizations. It covers information about how you can assess your current organization architecture to determine the best approach to migrate to the new organization, plan the necessary steps, and run the migration.

Support Engineers and TAMs can help you with general guidance, best practices, troubleshooting, and operational support on AWS. To learn more about our plans and offerings, see AWS Support.

---

About the authors

Sara Sheridan

Sara is a Senior TAM at AWS who works with global financial services customers. She has more than 15 years of industry experience and currently holds two CCIE certifications: one in Routing & Switching, and the other in Voice Technologies.

Michael Dobson

Michael is a Senior TAM at AWS who works with global financial services customers. He specializes in technical operations and information security, and enjoys providing strategic guidance to Enterprise Support customers as they move to and operate within AWS.