Move AWS accounts to a new organization without losing compliance evidence

Since November 19, 2025, AWS Organizations can transfer an account directly into another organization, without the account first having to operate as a standalone account with its own payment method and support plan. That shortens the move. What the old organization built around the account still does not travel with it, and the CloudTrail history in the old log archive is evidence that has to arrive in the new organization with proof that nothing changed on the way.

We moved about half a dozen accounts for a healthtech AI startup out of an organization that ran Control Tower, IAM Identity Center, StackSets and a HIPAA-aligned compliance program monitored in Vanta. Every account now runs in the new organization under the new landing zone. The log archive moved with its integrity verified, and the Vanta tests are green again.

What stays with the old organization

The AWS Organizations guide to migrating an account has a checklist for before the move and one for after. Read together, they cover most of what has to be handled when you move AWS accounts to a new organization:

• The service control policies and IAM policies the account relies on have to be replicated in the destination. IAM policies that reference the old organization ID, for example through the aws:PrincipalOrgID condition key, need the new ID.
• A delegated administrator account has to be deregistered before it moves.
• Organization-level reports and billing history are deleted once the account leaves, and AWS recommends a full export of billing history first.
• Account and OU tags have to be recreated in the new organization.
• After the move, each account's Support plan has to match the new payer. We covered the per-account side of support plans in our post on the 2027 AWS support plan migration.

Control Tower adds steps of its own. An enrolled account has to be unenrolled before the transfer, which means disabling every Control Tower resource applied directly to it; inherited preventive controls can stay. Someone needs access to both management accounts. Unenrolling removes the account's AWSControlTowerExecution role and adds OrganizationsAccountAccessRole, which the account uses to accept the new organization's invitation. Enrollment on the other side creates a fresh AWSControlTowerExecution role that trusts the new management account.

StackSets with service-managed permissions react when an account leaves a target organization or OU. With automatic deployment on, the account removal behavior decides whether CloudFormation deletes the stacks or keeps the resources outside the StackSet. Where the resources must survive the move, the setting to look for is RetainStacksOnAccountRemoval:

# Returns an operation ID; check it with describe-stack-set-operation
aws cloudformation update-stack-set --stack-set-name my-stackset \
  --use-previous-template --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=true

Identity Center is tied to the organization in a different way. Permission sets are stored in IAM Identity Center, and an organization instance is enabled in the management account. The new organization needs an instance of its own, with its own users, groups and permission sets.

Before touching any of this, we exported the old organization's configuration and cost history: policies, Identity Center, StackSets and invoices. We also scanned the accounts for dependencies. The move itself was split into 14 tracked subtasks, each with its dependencies, an estimate and test steps.

Build the destination before the first invitation

The new organization had its foundation before any account moved: OUs, an organization CloudTrail, budgets, KMS and a log bucket. One timing rule from the migration guide belongs on the calendar here. The destination organization must be at least seven days old before it can receive a migrated account.

On the identity side, we federated Google Workspace into IAM Identity Center over SAML. AWS's Google Workspace tutorial notes that SCIM sync from Google Workspace provisions users only. Groups have to be created another way, such as the Identity Store create-group command or the ssosync tool.

We migrated Identity Center users, groups and permission sets with an idempotent script, run first as a dry run and then applied. Because the script is idempotent, rerunning it after a partial apply changes nothing that is already correct. Our zero trust implementation guide covers the identity controls we would layer on top once the accounts are in place.

A test account that moves twice

The rehearsal ran on a purpose-built test account and covered the whole path: StackSet retention checks, Control Tower unenroll, transfer, validation, a rollback, and a second transfer. It showed SCPs missing in the new organization. We recreated them before any real account moved.

A missing SCP raises no error. The account arrives and its workloads keep running, with fewer restrictions on its principals than the day before. AWS's page on removing a member account says that once an account leaves, "restrictions imposed by SCPs are gone, and the users and roles in the account might have more permissions than they had before." An account that joins an organization without those SCPs ends up in the same state.

Plan the test account early. An account created inside an organization has to be at least four days old before it can be transferred out, according to both the Control Tower and the Organizations guides. Running the rollback and then a second transfer exercises the way back before any real account needs it.

Dev first, production last

The real accounts moved in the order dev, staging, ops and production. Each went through the same sequence:

1. A pre-flight snapshot.
2. Unenroll from Control Tower.
3. Transfer to the new organization.
4. Guardrails and access re-applied.
5. Service validation.

AWS's side of steps 2 and 3 is short, per the Control Tower transfer guide. With Auto Enroll on, unenrolling means moving the account to the organization root, to an unmanaged OU, or (on landing zone 4.0 and later) to an OU with only preventive controls. Without Auto Enroll, choosing Unmanage in the Control Tower console handles accounts with the Control Tower and Backup baseline. The destination's management account then sends the invitation and the account accepts it.

A migrated account lands in the root of the new organization, and the migration guide recommends checking its organization policies and OU permissions before moving it into an OU. Step 4 starts there. Organizations also leaves behind any IAM role that was created so the old management account could reach the member account; the removal page says it is not deleted automatically, so look for roles that still trust the old management account.

Running dev first and production last means every step in the sequence has run on lower-risk accounts before it reaches production.

Copying the log archive without losing its proof

The legacy Control Tower log archive held about 9 million objects. We copied it into the new log account and validated it with CloudTrail digest integrity checks and a file-by-file comparison before deleting the old buckets.

We ran both because of how CloudTrail log file validation works. The validate-logs command uses the digest files CloudTrail delivered alongside the logs, and one of its prerequisites is that "the digest and log files must not have been moved from the original Amazon S3 location where CloudTrail delivered them." A digest file read from a different bucket fails with INVALID: has been moved from its original location. The digest chain vouches for the files where CloudTrail wrote them, and the file-by-file comparison ties every copied object back to one of those files.

# Example values from the CloudTrail user guide; substitute your trail ARN, account and the trail's Region
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-2:111111111111:trail/example-trail-name \
  --start-time 2015-08-31T22:00:00Z \
  --end-time 2015-09-01T19:17:29Z \
  --account-id 111111111111 \
  --region us-east-2 \
  --verbose

The same page notes that --account-id is required for an organization trail and that the command is Region-specific. It also checks only log files that a digest file references, so anything outside the digest chain rests on the comparison alone. For how audit trails feed a HIPAA-aligned program more broadly, see our post on audit trails in a regulated SDLC.

Landing zone 4.0 after the accounts arrive

The new Control Tower landing zone, version 4.0, went up once the accounts were in. Then we restored Config recording and made the audit account the GuardDuty delegated admin in three regions.

Landing zone 4.0 shipped on November 17, 2025, and it changes what a new landing zone contains. The service integrations for AWS Config, AWS CloudTrail, Security Roles and AWS Backup are optional, and a Security OU is no longer required. Per the 4.0 key changes, enabling the Config integration at the landing zone level deploys recording to the service integration accounts only. Member accounts get a Config recorder and delivery channel when the Config baseline is enabled on their OU, one OU at a time. So restoring Config recording is a step of its own, and it belongs on the plan.

A GuardDuty delegated administrator is Regional. It has to be designated in each Region where GuardDuty is enabled, and it has to be the same account in every Region. Three regions meant three designations of the audit account.

Evidence back to green

We accepted the AWS BAA for the new organization. In AWS Artifact, an agreement accepted on behalf of the organization covers all existing and subsequent member accounts, and accepting one requires the management account and an organization with all features enabled. Coverage follows membership. The removal page says an account removed from an organization is no longer covered by organization agreements, so the new organization needs its own acceptance.

Then we reconnected Vanta and rescanned. Eight failing tests were tied to the migration, in log retention and break-glass admin tagging, and we fixed them.

Object Lock on the CloudTrail bucket

The last change was S3 Object Lock on the CloudTrail logs bucket. Object Lock can be enabled on an existing bucket as long as versioning is on. Once it is enabled, it cannot be turned off and versioning cannot be suspended. A bucket with Object Lock also cannot be a destination for server access logs, which is worth checking before you turn it on for a log bucket. In compliance mode, no user, including the root user, can overwrite or delete a protected object version during its retention period.

# Example from the S3 docs (compliance mode, 50-day default); set mode and days from your retention policy
aws s3api put-object-lock-configuration --bucket amzn-s3-demo-bucket1 \
  --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 50 }}}'

Before any account changes organizations, we would look first at the old organization's SCPs and every policy that names its organization ID, and at the StackSets whose account removal behavior would delete stacks on the way out. The log archive comes next, starting with where its digest files live. Get in touch and we will begin with that review of your organization.