When AWS Organizations Change
AWS accounts don’t stay in one Organization forever. Organizational structures change:
- Acquisitions: A company is acquired, and its AWS accounts need to move into the acquiring company’s AWS Organization.
- Divestitures: A business unit is sold, and its accounts are transferred to the buyer’s Organization.
- Restructuring: A company reorganizes its AWS footprint — consolidating multiple Organizations into one, or splitting a monolithic Organization into smaller ones.
- MSP transitions: A managed service provider relationship ends, and accounts move from the MSP’s Organization to the customer’s own.
In each scenario, accounts physically move from one AWS Organization to another. And everything attached to the old Organization — IAM Identity Center configurations, Service Control Policies, CloudFormation StackSets, and any third-party tooling connected to those accounts — needs to be re-established in the new Organization.
For teams using JIT access, the question is: how do you maintain access governance continuity during the migration?
The Problem: JIT Is Connected to an Organization
Cloudanix JIT connects to your AWS Organization through:
- A CloudFormation stack in the management account (or member accounts).
- IAM Identity Center data (users, groups, permission sets, account assignments).
- EventBridge for real-time sync of Identity Center changes.
When accounts migrate to a new Organization:
- The old Organization’s CloudFormation stack no longer applies.
- The old IAM Identity Center no longer governs the migrated accounts.
- The new Organization has its own Identity Center (possibly with different users, groups, and permission sets).
- Cloudanix needs to be re-connected to the new Organization context.
If this transition isn’t managed deliberately, there’s a window where:
- JIT isn’t operational for the migrated accounts (access requests can’t be fulfilled).
- Fallback to manual access management (standing privilege, bypasses).
- Audit trail has a gap (no JIT records during the transition period).
The Pattern: Disconnect → Migrate → Onboard
The clean approach to maintaining JIT continuity across Organization migrations follows three phases:
Phase 1: Disconnect from Old Organization
Before migration begins:
- Inventory active JIT sessions. Are any engineers currently elevated on the accounts being migrated? If so, coordinate timing to avoid mid-session disruptions.
- Disable JIT for migrating accounts. Remove them from the JIT configuration in the old Organization context so no new requests are processed for accounts that are about to move.
- Offboard accounts from Cloudanix. Delete the CloudFormation stack in the accounts being migrated. This removes the IAM cross-account role that Cloudanix uses.
- Document the current JIT configuration. Which groups had access to which roles on the migrating accounts? This becomes the template for re-configuration in the new Organization.
Phase 2: Migrate Accounts
Execute the AWS Organization migration:
- Remove account from old Organization (or accept the invitation from the new Organization).
- Account moves to new Organization’s management structure.
- New Organization’s SCPs, IAM Identity Center, and governance structures now apply to the migrated account.
During this phase, the migrated accounts have no JIT coverage. This window should be minimized — ideally measured in hours, not days.
Phase 3: Onboard to New Organization
Once accounts are in the new Organization:
- Run CloudFormation stack in the migrated accounts (or via StackSet from the new management account). Creates the IAM cross-account role for Cloudanix.
- Connect the new Organization to Cloudanix (if not already connected). The new Organization’s Identity Center becomes the identity source.
- Sync Identity Center data from the new Organization. Users, groups, and permission sets from the new Organization are now available for JIT policy configuration.
- Re-configure JIT policies. Map groups (from the new Organization’s Identity Center) to the migrated accounts with appropriate permission sets. Use the documentation from Phase 1 as a starting point, adjusted for any group/permission set naming differences.
- Test end-to-end. Engineers request access to the migrated accounts through the new Organization’s JIT configuration. Verify the flow works.
Practical Considerations
Test Migration First
Don’t migrate all accounts simultaneously. Pick one non-critical account (ideally a test or development account) and run the full Disconnect → Migrate → Onboard cycle. Validate:
- JIT works on the migrated account from the new Organization context.
- Group mappings are correct.
- Permission sets are available and functional.
- Approval workflows route correctly.
- Engineers can successfully assume roles via the SSO portal.
Once the pattern is proven on one account, apply it to the remaining accounts in batches.
Scope Restrictions in Large Organizations
When migrating accounts into a larger Organization (e.g., a parent company with 120+ existing accounts), you likely don’t want Cloudanix to manage all 120 accounts — only the ones you’re migrating.
Two approaches to scope restriction:
OU-based restriction (recommended):
- Create a dedicated OU (Organizational Unit) for the migrated accounts.
- Deploy the CloudFormation StackSet only to that OU.
- Future accounts migrated into the same OU automatically onboard.
- Clean separation: “Cloudanix manages accounts in this OU; everything else is untouched.”
Account-number-based restriction:
- If OU creation isn’t possible (organizational policy or structural constraints), specify individual account IDs for onboarding.
- Manual: each new account needs to be explicitly added.
- Less scalable but works when OU creation is blocked.
Group Filtering
If the new Organization has hundreds of groups (from the parent company’s Identity Center), you likely don’t want all of them appearing in Cloudanix:
- Filter by group prefix or naming convention. Only sync groups matching “Team-” or “JIT-” or your company’s naming pattern.
- Limit sync scope. Cloudanix can restrict which groups are imported, ensuring only relevant groups appear in the JIT configuration interface.
- Groups without JIT mappings are inert. Even if a group syncs into Cloudanix, it can’t request access unless explicitly mapped to accounts and permission sets. Unmapped groups have no JIT functionality.
Identity Provider Changes
Account migrations often coincide with IdP changes (e.g., moving from Google Workspace to Okta when joining a parent company that uses Okta). This means:
- Users in the new Identity Center may have different email addresses or user IDs.
- Group names and structures may differ.
- SSO authentication flows change.
For Cloudanix: Update the SSO configuration to the new IdP. Users authenticate with their new identity. JIT policies reference the new groups.
For AWS Identity Center: The new Organization’s Identity Center is the source of truth. Permission sets, users, and groups come from there. The migration includes ensuring the relevant users and groups exist in the new Identity Center (either via SCIM sync from the new IdP or manual creation).
Timeline Expectations
| Phase | Typical Duration |
|---|---|
| Disconnect (per account) | 15–30 minutes |
| AWS Migration | Hours to 1 day (AWS process) |
| CloudFormation deployment (new org) | 5–10 minutes per account |
| Cloudanix sync (new org Identity Center) | 10 minutes – 1 hour (depending on size) |
| Policy re-configuration | 30–60 minutes (based on complexity) |
| Testing and validation | 30 minutes |
| Total JIT downtime per account | 4–8 hours (can be scheduled off-peak) |
Minimizing the Gap
Pre-Configure Before Migration
If you have access to the new Organization before migration day:
- Connect Cloudanix to the new Organization early.
- Set up the OU structure.
- Pre-configure JIT policies (using placeholder accounts if needed).
- When accounts actually migrate, the only remaining step is onboarding and testing.
This reduces the “JIT unavailable” window from hours to minutes.
Communicate the Timeline
Engineers should know:
- “From 2 AM to 6 AM on Saturday, JIT will be unavailable for Production accounts.”
- “If you need access during this window, request before the migration starts.”
- “After 6 AM, use the new JIT workflow (same Slack commands, new Organization context).”
Clear communication prevents workarounds during the planned maintenance window.
The Outcome: JIT Survives Organizational Changes
AWS Organization migrations are disruptive enough without losing access governance. The Disconnect → Migrate → Onboard pattern ensures:
- Access governance never depends on a specific Organization structure.
- Migration is a planned operation with a defined timeline, not an emergency.
- Audit trail continuity: pre-migration events are in the old Organization’s JIT records; post-migration events are in the new Organization’s records. Together they provide complete history.
- Engineers experience minimal disruption: same Slack commands, same approval workflow, potentially different SSO portal URL.
Planning an AWS Organization Migration?
If you’re moving AWS accounts between Organizations — due to acquisition, restructuring, or consolidation — and you’re running JIT access on those accounts, the migration doesn’t have to mean losing access governance. Plan the Disconnect → Migrate → Onboard cycle, test on one account first, and keep JIT operational with minimal downtime.
Learn more about multi-account JIT or book a demo to discuss your migration scenario.
