Introduction
At first glance, moving an AWS member account between different AWS Organizations doesn’t seem like a big deal.
Is it really worth writing a blog post about it? Maybe not — at least that’s what I thought initially.
But over time, I’ve seen many AWS Partners and customers struggle with this seemingly simple task. So clearly, it’s more challenging than it should be.
Yes, AWS provides extensive documentation, but it can be time-consuming to navigate — and easy to miss crucial details hidden in the fine print.
There are also a lot of small but important steps that need to be considered beforehand.
In this blog post, I’ll walk you through how I typically approach these migrations.
Since AWS Organizations often rely on Consolidated Billing, we’ll also look at some specific hurdles in that area that require special attention.
Official AWS documentation
There isn’t a single source of truth when it comes to moving AWS accounts between Organizations.
AWS provides multiple pieces of documentation — not just within the AWS Organizations section, but also scattered across various service guides.
To get a solid foundation, I highly recommend reading these three posts from the official AWS Cloud Operations Blog:
- Part 1: Moving an organization member account to another organization
- Part 2: Considerations for delegated administrator accounts
- Part 3: Trusted access and service integrations
Part 1: Organizational features & pre-move checklist
In Part 1, AWS covers the various features of AWS Organizations that require review when moving an account from one organization to another.
The main focus is on Organization Policies, AWS Resource Access Manager (AWS RAM) shares, and global condition context keys.
While the official documentation primarily walks through the process via the CLI, this blog post takes a more visual approach using the AWS Console.
This is especially helpful for one-time migrations, for partners and customers with less AWS experience, or for those who only occasionally work with the CLI.
#1 Prepare before removing an account
⚠️ What you need to know from the AWS guide before detaching an account. The documentation points to the following AWS page: Removing a member account from an organization with AWS Organizations.
Let’s focus on the most relevant ones. I will skip some entries which have never had real relevance to me. These are things like “Tags attached to the account are deleted” on AWS Organization level. I also won’t delve into detailed permission requirements as admins often work with AdministratorAccess rights.
a) IAM access roles created by the management account are not automatically deleted
We need to be careful that IAM roles, especially the OrganizationAccountAccessRole, are not automatically deleted or modified.
b) You can remove an account from your organization only if the account has the information that is required for it to operate as a standalone account
This section is critical. AWS does not support directly moving accounts from one organization to another. Instead, the account must first leave its current organization and become standalone. It is mandatory to choose a support plan, provide and verify the required contact information, and provide a current payment method.
c) The owner of the account that leaves becomes responsible for all new costs accrued
Typically linked accounts use Consolidated Billing, and if the AWS account was created from within AWS Organizations (not being invited as a standalone account), then with taking them out of the old AWS Organization, the new owner (who also provided a current payment method - see section above) has to pay the costs separately. But we’ll note later that this is just half true, as billing typically takes place monthly. Only in some cases (Route 53 Domain Renewal or purchasing Saving Plans) does this occur out of order.
d) The account no longer has access to cost and usage data
This is very important. Some partners have complained as all the historical cost and usage data gets lost.
#2 Compare Feature Sets: Current vs. target Org
🔍 You need to understand the enabled features in both source and destination AWS Organizations. The AWS blog post describes the way via the AWS CLI, but this can also be looked up in the GUI.
In the AWS Console navigate to AWS Organizations, click in the left-hand menu bar to Settings.
There you’ll see if your AWS Organization is running only in Consolidated billing features or in All features mode.
This link provides further details: Enabling all features for an organization with AWS Organizations and describes the migration possibilities.
#3 Check Organizational Policies & Permissions
🛡️ The task is to review Organizational policies like Service Control Policies (SCPs), IAM policies, and auth settings tied to the account.
Organizational policies only apply if the current AWS Organization has the all-feature mode enabled (which is most often the case).
When the AWS account is removed from the AWS Organization, all the policies no longer take effect.
This applies to often used Service Control Policies (SCPs), but also to the new kind of resource control policies (RCPs). Besides these authorization policies, other management policies like declarative policies, Backup, Tag and Chat application, and AI services opt-out policies fall into this section.
The AWS blog post itself and the following link provides further information around this topic: Managing organization policies with AWS Organizations
Keep in mind that all of the different/target policies from the new AWS Organization will apply once the AWS account has joined the new organization.
#4 AWS RAM resource shares
🤝 This section could fill a whole blog post alone.
Before you move an AWS account, it’s important to verify if it’s part of any resource shares via AWS Resource Access Manager (RAM). If you have enabled AWS Resource Access Manager (RAM) and AWS Organizations, and have shared certain AWS resources, your account can be an owner, consumer, or both of shared resources.
The AWS blog details this section further. As in the SMB market AWS RAM is often not used at all, I’ll shorten this section.
Besides checking via AWS CLI as described in the blog post, it can also be checked by AWS Console:
In the AWS Console navigate to AWS Resource Access Manager, click in the left-hand menu bar to Resource shares in the section Shared by me:
If there is nothing mentioned like in the above screenshot, proceed with the next step.
Click in the left-hand menu bar to Resource shares in the section Shared with me.
If this is also empty, nothing to consider or worry about - you can safely proceed.
#5 Audit CloudWatch Events Configuration
📡 It’s required to ensure event routing between AWS accounts is understood. Often this is not exactly known, thus we have to find this out.
In the AWS Console navigate to Amazon EventBridge, click in the left-hand menu bar to Rules in the section Buses.
Analyze all existing rules and see if cross-account rules are involved.
The following post (including a video) details this further: Sending and receiving events between AWS accounts in Amazon EventBridge
#6 Understand Global Context Keys Impact
🔐 It’s also required to check usage of global condition context keys affecting any policies. This might sound complex and confusing to AWS non-pros, but basically what is meant: AWS Identity and Access Management (IAM) allows you to control access to AWS resources by filtering also per AWS Organizations fields, like the AWS Organization ID.
You have to review the authorization policies that use the following Organizations related condition keys before you remove the member account. If you do not update the policies, users and roles of the account may lose access to resources when the account leaves the organization.
- aws:PrincipalOrgID
- aws:PrincipalOrgPaths
- aws:ResourceOrgID
- aws:ResourceOrgPath
Some of the keys support multiple values, so you can add the info from the current and from the target AWS Organization.
#7 Review AWS Organizations Quotas
📊 It’s important to know the target org’s quotas before adding another account. Especially consider the Number of AWS accounts in an organization. Also throttling limits are considered there as well.
#8 Understand the Role of the Management Account
🧭 This is a very rare and special situation. If the management account of an AWS Organization needs to be shifted, the organization needs to be deleted. Before an organization can be deleted, all linked member accounts need to be removed from the organization. The AWS account needs to be a normal standalone account before it can be invited into the new AWS Organization.
Attention: If the whole AWS Organization (including many member accounts) needs to be transferred e.g., in case of switching from AWS direct to an AWS Reseller or AWS-Distributor like Ingram Micro, we are not talking about moving an AWS account. All that’s mentioned in this blog post is not valid. The process which is then required is called AWS Consent to Assignment (CTA). Reach out to me if you need further information.
Part 2: Delegated Admins & Service Ownership
#9 Consider Delegated Administrator Roles
👥 The second part of the AWS blog series discusses key considerations when the AWS account being moved is registered as a delegated administrator for AWS services. It outlines how these roles are handled during the move and what to review in both the source and destination organizations. They have outlined what to expect when deregistering a delegated administrator for an AWS service and included guidance to help you plan accordingly. Additionally, the blog post covers considerations for moving an account into an organization where a delegated administrator is already in place for the same service.
The following doc outlines all AWS services that support a delegated administrator: AWS services that you can use with AWS Organizations.
Background on delegated administrator AWS accounts
In smaller AWS setups, the management account usually does it all — and that might work fine for a while. But once you start scaling, or you’re working with multiple teams or partners, that centralized approach quickly hits its limits. That’s where delegated administrators come into play.
Instead of having one account juggle everything, you can assign certain AWS services to other accounts in your organization. This doesn’t mean giving away full admin rights — it just means that specific accounts can manage specific services like AWS Config, GuardDuty, or CloudFormation StackSets on behalf of the organization. And yes, that’s officially supported by AWS.
This setup helps you distribute responsibilities across your org without losing control. The management account still holds the top-level power, but you can offload day-to-day operations where it makes sense. It also means less cross-account access fiddling, and fewer bottlenecks when someone needs to configure a service.
Verification if this affects you
There are two views existing: the view from the AWS Management account, where the AWS account which should be moved is a member account. The other option is to check this from the AWS member account itself.
Perspective of the management account
If you have access to the old AWS Organization (you need at least organizations:ListDelegatedServicesForAccount permission, but that’s included in AdministratorAccess policy) you can check this quite easily.
Besides checking via AWS CLI as described in the blog post, it can also be checked with the AWS Console:
In the AWS Console navigate to AWS Organization, click in the left-hand menu bar to Settings:
If there is any AWS account listed, verify that the AWS Account ID (of the account to be moved) is not listed. (Maybe you have hundreds of AWS accounts in the old organization and the one that needs to be moved is not causing any problem.)
Inside view from the member account
If you don’t have access to the management account of the old organization, there is unfortunately no single place to verify if the account is assigned as delegated administrator for the whole AWS Organization or any AWS service. You have to navigate to all the services mentioned here and check in the settings page if this account is set as AWS delegated administrator.
If your screen looks like the first screenshot and no delegated administrator is listed, you’re done with this section. If it’s listed, or if it is the delegated administrator for any AWS service - like in my 2nd screenshot - follow the official AWS blog - part 2 (with the further links inside) to proceed.
Part 3: Trusted Access & Service Integrations
#10 Check Trusted Access for Services
🪪 In part 3 of the official AWS blog post, they identify behaviors, provide guidance and actions when you move an account where one or more AWS services is enabled for trusted access in the current and target organization.
This section really considers advanced AWS techniques and it cannot be performed from the member account itself, but only from the old AWS Organizations management account. If you have a delegated administrator in place (section above), this also enables in most cases the trusted access for you.
What is trusted access?
Trusted access is a mechanism, available for a selected number of AWS services for accessing AWS accounts in one AWS Organization.
When you turn on trusted access for a supported AWS service, that service can perform tasks (as explained in its documentation) across all AWS accounts in your organization. If you remove an account from the organization, the trusted service will no longer be able to work with that account. Before moving an account out of one organization and into another, make sure you understand how this affects the trusted service and whether you need to take any steps beforehand.
Even though I want to focus on the AWS Console in this blog post, the following command is only supported in the AWS CLI. This AWS CLI command retrieves a list of all AWS services that have trusted access enabled in my organization:
~ \$ aws organizations list-aws-service-access-for-organization
{
"EnabledServicePrincipals": [
{
"ServicePrincipal": "aws-artifact-account-sync.amazonaws.com",
"DateEnabled": "2022-06-06T13:22:18.455000+00:00"
},
{
"ServicePrincipal": "backup.amazonaws.com",
"DateEnabled": "2024-02-17T20:39:34.879000+00:00"
},
{
"ServicePrincipal": "securityhub.amazonaws.com",
"DateEnabled": "2023-04-16T10:23:35.467000+00:00"
},
{
"ServicePrincipal": "storage-lens.s3.amazonaws.com",
"DateEnabled": "2022-03-14T13:57:00.682000+00:00"
}
]
}
~ \$
I would recommend verifying all enabled trusted accesses in the old and in the target organization, and if they match: Proceed. If there are differences, try to understand how they affect the account migration by reading the AWS blog post part 3.
In my case backup.amazonaws.com and securityhub.amazonaws.com are also enabled in the new organization. AWS Artifact as well as S3 Storage Lens are enabled in the old org but not enabled in the new organization, but they were just used for demo and test purposes and are not used in production or in any automation or deep integration. So I can proceed.
Final Steps & Considerations
This last section contains the remaining points to be considered.
#11 Know the Side Effects of Leaving an Org
💣 Understand indirect effects described in the AWS documentation. See Before removing an account from an organization. For instance, you have to wait at least 7 days after AWS account creation before it can leave the AWS Organization.
#12 Follow Official Removal Procedures
📋 I’d like to spotlight that there are two possibilities for how the AWS account can leave the current AWS Organization. In the first option, the admin removes the AWS account from AWS Organizations. I call this the external version, as I can also do this without looking at/having permissions inside the member/linked account. The 2nd option is to leave the AWS Organization from the member/linked-account itself. This is the internal, active leaving. Removing a member account Leave an organization from a member account with AWS Organizations Understand your options and decide how to proceed.
#13 Inviting an Account to a New Org
✉️ Now it’s finally time to invite the standalone AWS account to join your new AWS Organization. Review the official documentation to understand the considerations: Inviting an AWS account to join your organization.
#14 Use AWS’s Account Assessment Tool
🛠️ If you have to do this at large scale for many AWS accounts, the assessment effort is very high. For that, AWS created an AWS Account Assessment Tool that assists you in the assessment process. A future blog post will examine this tool.
Final Thoughts
Migrating AWS accounts between Organizations isn’t something most teams do regularly — and that’s exactly why it often becomes a trap.
There are dozens of details, some obvious, some well hidden in AWS documentation. This guide tried to bridge that gap by combining official AWS guidance with hands-on experience and highlighting edge cases that are easy to overlook.
If you’re moving just one account: take your time, follow the checklist.
If you’re planning a larger migration with dozens or even hundreds of accounts: automate what you can and evaluate tools like AWS’s Account Assessment Tool.
And remember: a successful migration is not just about moving the account — it’s about ensuring that everything works the same way after the move as it did before.
Feel free to reach out if you’ve got questions or feedback.
Further reading: