Here's a pattern I keep running into: a company started with a single AWS account years ago, deployed their production workloads there, and eventually created an organization around it. That original account became the management account — and it's still running workloads.
Sometimes it's worse. The company has five, seven, or ten accounts scattered across a loosely structured organization and a handful of standalone accounts with no centralized governance at all. The management account runs production. Service control policies (SCPs) don't apply to it. There's no unified security baseline. The standalone accounts have no guardrails.
If this sounds familiar, you're not alone. It's one of the most common multi-account anti-patterns I see, especially in small and mid-sized companies that grew their AWS footprint organically. The good news: there's a clean path forward. The less obvious news: restructuring your existing organization in place usually isn't it.
This post walks through when and how to create a new AWS Organization, migrate your existing accounts into it, and establish the governance foundation you should have had from the start.
Why running workloads in the management account is a problem
The management account in AWS Organizations has a unique property that makes it a poor home for workloads: SCPs don't restrict it.
This means any guardrails you implement through SCPs like restricting regions, preventing public S3 buckets, requiring encryption don't apply to the management account. If your production workloads run there, they operate outside your governance boundary. The management account should only handle your AWS Organization management, billing, and Identity management through IAM Identity Center.
Beyond SCPs, running workloads in the management account creates additional risks:
Blast radius. A compromised workload in the management account has implicit access to organizational operations. The management account can create accounts, attach policies, and modify the organization structure.
Billing confusion. Workload costs in the management account are harder to attribute and track. Separating workloads into dedicated accounts enables cleaner cost allocation.
Audit complexity. Compliance frameworks expect separation of duties between administrative and workload accounts. Mixing them complicates audit evidence collection.
Why you can't just restructure in place
The intuitive fix is to move workloads out of the management account and restructure the existing organization. For some environments, that works, but there's a structural constraint that often makes it impractical: you cannot demote a management account to a member account.
If your management account runs production workloads and you want it to become a regular member account in a properly structured organization, you can't do that within the existing organization. The management account is the management account — permanently, for that organization.
You also can't transfer the management account role to another account. The only way to change which account is the management account is to create a new organization with a different account at the top.
This is how I think about which option to use:
| Scenario |
Approach |
| Management account is clean (no workloads) and you just need to restructure OUs |
Restructure in place — move accounts between OUs, add SCPs |
| Management account runs workloads but you can easily migrate them out, or the organization heavily uses features like AWS RAM |
Migrate workloads to member accounts, then restructure in place |
| Management account runs workloads that are tightly coupled to the account (VPCs, databases, IAM roles with hardcoded ARNs) |
Create a new organization with a clean management account |
| Standalone accounts exist outside any organization |
Create a new organization and invite all accounts into it |
Before making a final decision, I recommend reading the excellent blog series Moving an Organization member account to another organization to ensure you are not using any organization features that can break applications.
The migration: four phases
Phase 1: Stand up the new organization
Create a new, dedicated AWS account that will serve as the management account for your new organization. This account should have:
Create the organization from this account with all features enabled. Then deploy AWS Control Tower as your landing zone foundation. Control Tower automates the creation of a Security OU with dedicated Log Archive and Audit accounts, establishes baseline controls, and provides a framework for ongoing governance.
Design your OU structure based on the AWS Security Reference Architecture (SRA). At minimum, separate security, production workloads, non-production workloads, and sandbox environments.
Phase 2: Establish the security baseline
Before migrating any accounts, establish the security services that will apply organization-wide. Enable these from through delegated administrators:
Enable these at the organization level so every account that joins the organization automatically inherits the baseline. This is the key advantage of establishing the baseline before migration — you don't have to retrofit security into accounts after the fact.
Phase 3: Migrate accounts
Account migration follows a specific sequence. The order matters because of how AWS Organizations handles the management account.
Step 1: Migrate standalone accounts first. These are the simplest — they aren't in any organization, so there's nothing to leave. From your new management account, send an invitation. From the standalone account, accept it. The account joins the new organization and immediately inherits your SCPs and security baseline.
Step 2: Migrate member accounts from the old organization. This has recently gotten easier with the new feature allowing direct account transfers between organizations. Simply invite your accounts to the new organization, and accept them in the old organization.
Step 3: Migrate the old management account last. The management account can only leave its organization after all member accounts have been removed and the organization is deleted. Once the old organization is dissolved, the former management account becomes a standalone account and can accept an invitation to join the new organization as a regular member account.
This sequence ensures continuity — the old organization continues to function for remaining accounts while you migrate them one at a time.
Before migrating each account, review:
IAM policies that reference the old organization ID or management account ID
SCPs from the old organization that the account depended on (you'll need equivalent policies in the new org)
Billing — Reserved Instances and Savings Plans transfer with the account, but verify cost allocation tags and billing preferences
Service integrations — CloudTrail, Config, and other services with organization-level configurations may need reconfiguration
Phase 4: Harden with governance controls
With all accounts in the new organization, implement the governance layer:
Service control policies (SCPs) — Start with deny-list SCPs that prevent the most dangerous actions: disabling CloudTrail, deleting GuardDuty detectors, creating public S3 buckets, or launching resources in unapproved regions. SCPs now apply to every member account — including the account that used to be your old management account.
Resource control policies (RCPs) — A newer complement to SCPs. While SCPs restrict what IAM principals in your accounts can do, RCPs restrict what external principals can do to resources in your accounts. Together, they form the identity and resource boundaries of a data perimeter.
Control Tower enrollment — Enroll all migrated accounts into Control Tower to apply the full set of preventive and detective controls. This provides continuous compliance monitoring and drift detection.
Centralized logging — Verify that CloudTrail organization trails, Config recordings, and VPC Flow Logs all route to the Log Archive account in your Security OU.
Common concerns
"This sounds disruptive — will my workloads go down during migration?"
With proper planning, no. Moving an account between organizations is an administrative operation. It changes the account's organizational membership and billing relationship. It does not affect running resources, VPCs, EC2 instances, databases, or any other infrastructure within the account. Workloads continue running uninterrupted, provided you aren't relying on resource shares in RAM or other organization-specific configuration.
"Can I do this incrementally?"
Yes, and you should. Migrate one or two low-risk accounts first — a sandbox or development account — to validate the process. Confirm that the security baseline applies correctly, billing works as expected, and no IAM policies break. Then migrate production accounts with confidence.
"What about consolidated billing?"
Billing follows the organization. When an account moves to the new organization, its charges appear on the new management account's consolidated bill. Reserved Instances and Savings Plans sharing transfers with the account. Review your billing configuration after each migration to confirm cost allocation tags and billing alerts are intact.
Cleaning up
After all accounts are migrated and the old organization is dissolved:
Delete the old organization's management account if it's no longer needed, or repurpose it as a workload account in the new organization
Remove any stale IAM roles, policies, or cross-account trust relationships that reference the old organization ID
Update any automation, CI/CD pipelines, or scripts that reference the old management account ID or organization ID
Verify that all accounts appear in Control Tower and that no accounts are in a "not enrolled" state
Conclusion
In this post, I walked through why running workloads in your AWS management account creates a governance gap, why restructuring in place often isn't viable, and how to migrate to a properly structured organization.
The core pattern: create a new organization with a clean, dedicated management account. Establish your security baseline (Security Hub/Security Hub CSPM, GuardDuty, Inspector) before migrating accounts. Migrate standalone accounts first, old organization members second, and the old management account last. Then harden with SCPs, RCPs, and Control Tower enrollment.
If you're operating with a management account that runs workloads or standalone accounts with no governance, this migration is the prerequisite for everything else — cost optimization, security hardening, compliance programs. You can't govern what you can't see, and you can't enforce what doesn't apply.
If you have questions or have gone through this migration yourself, leave a comment — I'd like to hear how it went.
