CIAM Decommission: Retiring an Old Identity Platform Safely

The migration from an old CIAM to a new one isn't done at cutover, it's done when the old CIAM is fully retired with no operational dependency, no security exposure, and a documented compliance posture for archived data. Decommission usually lands 30-60 days after cutover, once the JIT bridge is complete. This playbook covers the safe wind-down.

Phase 1, Migration completion verification (7 days)

Before retiring anything, confirm the migration is actually complete.

JIT migration coverage. What percentage of users have migrated to the new CIAM via JIT? Active users typically reach 80-90% within 30-45 days of cutover. Below 80% means there's still a meaningful population that needs the old CIAM bridge.

Long-tail forced reset. Users who haven't signed in since cutover need a forced password reset campaign. Email them with a reset link via the new CIAM. Two-week observation; track reset completion rate.

Application code audit. Search the codebase for old CIAM references, SDKs, JWKS URLs, JWT issuers, OAuth client IDs, webhook endpoints. Every match needs to be either removed or replaced. Common misses: error logging that mentions the old CIAM, status pages, internal documentation, monitoring dashboards.

Service-to-service tokens. Backend services with M2M client credentials issued by the old CIAM need to be reissued by the new CIAM. Audit each service.

Federation provider audit. External IdPs (Google, Apple, Facebook, SAML federations) configured to redirect to the old CIAM's callback URLs need to be updated to point at the new CIAM. Each provider's admin console.

Phase 2, Read-only quiesce and final snapshot (14 days)

Once migration is verified, put the old CIAM in read-only mode and capture the final state.

Read-only mode. Disable user sign-ups, password changes, and admin operations on the old CIAM. New writes are blocked; reads are still served (the JIT bridge may still be querying).

Final snapshot. Export the complete user database from the old CIAM:

• User records (email, attributes, custom fields, status)
• Credentials (password hashes, for compliance retention only, not for re-import)
• MFA enrollments (TOTP secrets, WebAuthn metadata, device records)
• Federated identity bindings (provider, subject, linked email)
• Audit log (last N years per retention policy)
• Configuration (realms, clients, roles, themes, custom code)

The snapshot is the canonical archive.

JIT bridge cutoff. With migration coverage validated and the snapshot taken, disable the JIT bridge. New sign-ins to users who haven't migrated yet now hit a forced reset flow on the new CIAM rather than a JIT lookup against the old.

Quiesce verification. Confirm zero traffic to the old CIAM for two weeks before proceeding to decommission. Watch logs for unexpected calls, usually a forgotten internal tool or a stale webhook.

Phase 3, Compliance archive and retention (14 days)

The old CIAM data has retention obligations. Archive correctly so the data remains accessible for compliance but isn't sitting on operational infrastructure.

Retention requirements review. What does the compliance team require?

• Audit logs: typically 365 days minimum, often 7 years for regulated industries
• User PII: defined by GDPR/CCPA, minimum necessary, with deletion on request
• Authentication events: tied to audit log retention

Document the retention period for each data category.

Archive storage. Move the snapshot to long-term archive storage (S3 Glacier, Azure Archive Storage, GCP Coldline). Encrypt at rest with a key managed by your KMS. Document the access procedure for compliance queries.

Data minimization. Before archiving, review what's actually needed. If audit logs contain debugging fields with no compliance value, drop them. If user records contain custom attributes that have no retention requirement, drop them. Smaller archives cost less and reduce breach exposure.

Deletion of GDPR-erased users. If users requested erasure under GDPR/CCPA before the migration, those records should not be archived. Confirm the deletion policy was applied and the snapshot excludes erased users.

Access policy. Who can query the archive? For what reason? Document the access procedure: ticket required, dual-approval, audited access, time-limited. The archive is sensitive; treat it like backup data.

Phase 4, Infrastructure retirement (10 days)

With the data archived and access policy in place, retire the operational infrastructure.

Service shutdown. Stop the old CIAM service:

• Kubernetes deployments scaled to zero
• Stateful services (databases, caches) marked for decommission
• Load balancers detached
• DNS records removed

Database decommission. The CIAM's primary database, typically Postgres or MySQL, has the user records that you've already archived. Take a final snapshot for safety, then decommission per cloud provider procedure.

Backup retention. Existing backups of the old CIAM database may need retention per the compliance policy. Confirm backup expiration aligns with the retention plan.

Monitoring and alerting. Remove monitoring dashboards, alerts, and on-call rotations specific to the old CIAM. Update status pages.

Cost reconciliation. Confirm the old CIAM's cloud costs (compute, database, network) are now zero. Cancel vendor contracts (managed services, support contracts, log analytics for the old platform).

Documentation cleanup. Internal documentation, runbooks, architectural diagrams all reference the old CIAM. Update or remove. Onboarding documentation for new engineers should not reference the retired system.

Retrospective. Document what the migration cost (engineering time, vendor cost, downtime), what surprised the team, and what would be done differently. The retrospective is the input for the next migration when it eventually comes.

Anti-patterns to avoid

• Skipping the migration coverage verification. Retiring before migration is complete leaves users locked out and forces an emergency restoration.
• No final snapshot. Once the infrastructure is decommissioned, the data is gone. Snapshot before retirement, no exceptions.
• Treating the archive as casual backup. The archive contains sensitive identity data (hashes, PII, audit logs). Apply the same access discipline as production.
• Forgetting the federation providers. Old OAuth callbacks left configured on Google, Apple, Facebook are confusing; clean them up.
• No retention policy. Archives that don't have a documented retention period accumulate indefinitely; they need lifecycle policies.
• Skipping the cost reconciliation. Old vendor invoices keep arriving for months because no one cancelled the contract.

What success looks like at day 45

• Old CIAM fully retired, no running services, no operational dependency.
• Final snapshot archived with documented retention and access policy.
• Compliance archive in cold storage, encrypted, access-controlled.
• Federation cleanups complete, no stale OAuth callbacks pointing at the dead CIAM.
• Cost reconciled, old vendor contracts cancelled, cloud costs zero.
• Documentation updated, runbooks, diagrams, onboarding materials reflect the new CIAM only.

For migration paths that lead to this decommission, see the Cognito to Stytch playbook, the Keycloak to managed playbook, and the Auth0 to self-hosted playbook.