Invite, don't leave-then-join: governing AWS accounts after an organization move

A hands-on walkthrough on dev.to argues that moving an AWS account between organizations is the easy part of the job: the account shows up in the new organization, the Control Tower dashboard reports it as enrolled, and users sign in through the new portal, while behind the scenes the old organization can still administer it and the destination's own guardrail policies may not reach it at all. The post, written from a multi-account governance engagement involving production accounts, lays out both the migration route that works and the follow-up steps that decide whether a moved account is actually governed.

The leave-then-join route stalls

The classic approach — have the account leave its organization, run standalone for a while, then accept an invitation — breaks down on standalone prerequisites. Accounts created inside an organization typically lack a payment method, and according to the dev.to post, adding a card still did not satisfy AWS: the leave operation kept refusing without spelling out what else was missing. The author also notes that no public API exposes whether a payment instrument exists — billing, account, budget and cost-explorer surfaces all came up empty — leaving the console's Billing and Payment preferences pages as the only place to check.

One caution stands out: a refused leave call is harmless, but the same call succeeds and detaches a production account on the spot once prerequisites are met. The author's advice is to never use that call as a readiness test.

Invite from the destination instead

AWS announced direct account transfers on 19 November 2025. The destination organization's management account sends an invitation, the member account accepts, and the account moves across without ever leaving its old organization or running standalone in between. The author flags a documentation wrinkle: the InviteAccountToOrganization API reference still lists ALREADY_IN_AN_ORGANIZATION as a failure reason, but that list sits under a caveat that some reasons may not apply to the operation, while the account migration guide describes the direct transfer. When the two disagree, the author sides with the user guide.

Mechanically it is two short calls:

in the destination management account

aws organizations invite-account-to-organization --target Id=123456789012,Type=ACCOUNT

in the member account

aws organizations accept-handshake --handshake-id h-examplehandshakeid111

Prerequisites from the guide include rules on the age of the account and the organization, a Seller of Record that must match, and the fact that the account lands in the root of the new organization. Per the invitations documentation cited in the post, invitations expire after 15 days, and the destination's policies apply the moment the account joins.

The Control Tower sequence

With AWS Control Tower in the destination, per the post, a move only counts once the account is enrolled into the right organizational unit. The order of operations:

1. Register the landing OU with Control Tower while it is still empty — about two minutes in the author's run, though AWS advises planning for ten or more. Control Tower attaching its aws-guardrails-* service control policies is expected, not drift.
2. Associate security monitoring with the OU before any account arrives.
3. Send the invitation from the destination and accept it in the member account.
4. Create the AWSControlTowerExecution role in the member account, trusting the destination's management account and carrying the AdministratorAccess managed policy — without it, enrollment fails.
5. Enroll the account through Control Tower the same day; until enrollment, the account sits in the root under whatever policies are attached there.

The author deliberately avoids the aws organizations move-account command for the final step: with automatic enrollment off, a manual move into a Control Tower OU does not enroll the account and causes inheritance drift. Landing zone 3.1 and later can auto-enroll instead. The post also recommends staggering migrations rather than moving everything at once, ordering accounts by access risk, and holding back any account whose permission sets do not yet exist in the destination.

The three checks that matter

A finished-looking move still needs verification on three fronts, according to the post: whether people can sign on as intended, whether the destination's own guardrail policies actually apply to the account, and whether the old organization's administrative access has been cut off.

Why it matters

Multi-account AWS environments are governed by exactly the mechanisms this post warns can silently drift: SCPs inherited from OUs, Control Tower enrollment, and IAM trust relationships tied to the management account. A moved account that looks healthy on the dashboard but sits outside the guardrail set is a compliance gap with no error message attached. The invite path also removes a practical blocker — hand-entering payment cards into every member account — and eliminates the billing gap of a standalone period outside consolidated billing. For teams planning migrations, the checklist value is concrete: prepare the landing OU and its security monitoring first, enroll immediately after the move, and verify sign-on, guardrails and stale administrative access before calling any account done.