You've planned the migration, scheduled the maintenance window, and notified stakeholders. Then you flip the switch in AWS IAM Identity Center, and every user in your organization loses access to every AWS account and application.
This isn't a hypothetical scenario. When you switch from Active Directory to an external identity provider in IAM Identity Center, the platform immediately deletes all users, groups, and their associated assignments the moment you confirm the change. There's no grace period or rollback button. They're just gone.
The issue isn't that migrations are inherently risky. It's that teams consistently make the same six mistakes, each compounding the next.
Why These Mistakes Keep Happening
Identity source transitions sit at the intersection of three organizational silos: the Active Directory team, the AWS platform team, and the identity provider administrators. Each group understands its own domain but rarely sees how the pieces connect. The AD team knows their directory structure, the AWS team knows IAM Identity Center, and the Okta or Entra ID administrator knows SAML federation. But nobody owns the complete picture of what happens when you change the authoritative source that backs every AWS permission set assignment.
This fragmentation leads to predictable failures.
Mistake 1: Skipping the Inventory
Why it happens: Teams assume they know what's in IAM Identity Center because they manage it. They don't run an export because they think, "we only have a few permission sets."
The consequence: After cutover, you discover you had 47 permission sets across 23 accounts with 312 distinct assignments. You're now restoring access from memory while executives ask why they can't reach production systems.
The fix: Run a complete precheck export before you touch anything. You need three artifacts: a full list of users and groups currently in Identity Center, every account assignment with its associated permission set, and every application assignment. Export to CSV and validate referential integrity to confirm that every assignment references an actual user or group. Store these files in version control, not on someone's laptop.
Mistake 2: Trusting Attribute Parity Without Testing It
Why it happens: The new identity provider shows the same users and groups, so teams assume the migration will map cleanly.
The consequence: IAM Identity Center uses specific attributes to match identities. If your Active Directory uses sAMAccountName for the UserName attribute but your external IdP sends mail, the restore script will fail to find matching principals. Users exist in both systems but can't be matched programmatically.
The fix: Before cutover, export a sample of users from both the current source (Active Directory) and the target source (your external IdP). Compare UserName, DisplayName, and email address field-by-field. Fix any mismatches in the target system before you switch. You're looking for exact string matches. The restore process has no fuzzy logic.
Mistake 3: Switching Identity Sources During Business Hours
Why it happens: Someone schedules the migration during a "low traffic" afternoon because a true maintenance window feels excessive.
The consequence: When you switch the identity source from Active Directory to an external IdP, IAM Identity Center deletes all users, groups, and assignments immediately. Users currently authenticated will lose access when their session expires. New authentication attempts fail until assignments are restored. If restoration takes two hours, you've just caused a two-hour outage during the workday.
The fix: Treat this as a full outage. Schedule the migration during an actual maintenance window when users expect systems to be unavailable. Communicate the specific time range to all stakeholders, including executives who might need AWS access. If your organization has global teams, pick a window that minimizes impact across time zones. Accept the reality that the cutover is destructive by design.
Mistake 4: Restoring Assignments Without Validating the New Identity Source First
Why it happens: Teams rush to restore access and run the restoration script immediately after switching identity sources.
The consequence: The restoration script fails because the new identity source hasn't finished provisioning users and groups into IAM Identity Center yet. SCIM provisioning isn't instantaneous. If you switch to Okta and immediately try to restore assignments, the script will report that it can't find the target users and groups because they don't exist in Identity Center yet.
The fix: After switching the identity source, wait for SCIM provisioning to complete. For external IdPs, confirm that all expected users and groups appear in the IAM Identity Center console before you attempt restoration. Run a count: if your backup shows 450 users but Identity Center only shows 120, provisioning is still running. Don't start restoration until the counts match.
Mistake 5: Assuming Application Assignments Restore Like Account Assignments
Why it happens: The backup script exports both account assignments and application assignments to the same CSV format, so teams assume the restore process works identically.
The consequence: AWS-managed applications like Amazon SageMaker Studio maintain their own identity source reference. They store the specific sourceID, UserId, and GroupId from the original identity source. When you switch sources, these applications don't automatically recognize the new identities even if you restore the assignments through the API. Users get permission errors or can't access application resources despite having valid assignments in IAM Identity Center.
The fix: Treat application assignments separately. After restoring account assignments, test each AWS-managed application individually. Some applications require redeployment or manual reconfiguration to recognize the new identity source. Document which applications need special handling before you start the migration, and budget extra time for application-specific restoration steps.
Mistake 6: Not Having a Documented Rollback Plan
Why it happens: Teams focus all their planning energy on the forward migration and assume they can "just switch back" if something goes wrong.
The consequence: Rollback is not a simple reverse operation. If you switch from Active Directory to Okta and then switch back to Active Directory, you trigger another destructive cutover. All the assignments you just restored in Okta are deleted. You're now restoring assignments for the second time, and you've doubled your outage window.
The fix: Document your rollback procedure before cutover, including the decision criteria for when to abort. Your rollback plan should include: the exact commands to switch back to the original identity source, the backup files you'll use for restoration (the original precheck export, not the post-migration state), and the stakeholder who has authority to call the rollback. Test your backup restoration process in a non-production IAM Identity Center instance if possible. Knowing you can restore gives you the confidence to proceed.
Prevention Checklist
Before you schedule your next identity source migration:
- Export complete inventory: users, groups, account assignments, application assignments
- Validate attribute parity between current and target identity sources (UserName, DisplayName, email)
- Confirm SCIM provisioning is configured and tested in the target IdP
- Schedule a true maintenance window, not a "low traffic" period
- Document rollback procedure with specific commands and decision authority
- Identify which AWS-managed applications require special handling
- Test restoration scripts in a non-production environment
- Assign a single owner for cutover execution (not a committee)
- Prepare communication templates for stakeholders (before, during, after)
- Verify you have admin access to both identity sources during the cutover window
Identity source migrations are destructive by design in IAM Identity Center. You can't eliminate the risk, but you can avoid the mistakes that turn a planned cutover into an unplanned outage.
