Migrate Off Akamai Identity Cloud Before the Deadline

Migrating off Akamai Identity Cloud is a project, not a config change, and the deadline is the whole problem. Akamai Identity Cloud (formerly Janrain) has an announced end-of-life, and when it lands your authentication, registration, social login, consent records, and profile store all go away together. Start now: inventory usage, pick a replacement, and run both systems in parallel before you cut over. Waiting means a rushed migration with locked-out users.

Why the deadline matters and what you lose if you wait

The deadline matters because Akamai Identity Cloud is a single system holding five things at once: how users log in, how they registered, their linked social accounts, their consent and preference records, and the customer profile data itself. When the service reaches its announced end-of-life, all five stop together. There is no partial degradation you can limp along on.

Waiting compresses every hard part of the migration into the same window. Bulk data export, replacement selection, dual-run testing, and DNS cutover each take real calendar time, and they have dependencies: you cannot test JIT password migration until the replacement is live, and you cannot cut over DNS until dual-run is proven. Confirm the exact date against Akamai's official end-of-life notice and Deepak's Akamai Identity Cloud shutdown research, then work backward from it. If you are still choosing a vendor, start with What Is CIAM and the Top CIAM solutions shortlist.

Inventory what you are actually using

Before you can replace anything, list every Identity Cloud capability that is live in production, because you almost certainly use fewer features than the platform offers, and the gap decides your effort. Audit these five areas.

• Authentication. Which flows are real: password login, passwordless, social, MFA? Note token formats and whether downstream apps expect OIDC or SAML.
• Registration. Capture the exact self-registration fields, progressive-profiling steps, email or phone verification, and any custom validation logic.
• Social login. Enumerate every connected provider (Google, Facebook, Apple, and so on), each provider's client IDs, and the scopes you request. These are per-provider app registrations you will have to recreate.
• Consent and preferences. Export the consent taxonomy: marketing opt-ins, granular preferences, versioned policy acceptances with timestamps. This is compliance data. Losing it is worse than losing a password.
• Customer profile store. Document the full schema, including custom attributes, nested objects, and record volume. This is the payload of the whole migration.

Write this down as a spreadsheet with a row per capability and a column for "in use," "record count," and "who depends on it." That artifact drives both vendor selection and the cutover plan.

Data export and user-migration strategy

Export the full profile store in bulk, but expect passwords to migrate lazily on each user's next login rather than in the bulk load. These are two separate movements and conflating them is the classic mistake.

Bulk export covers everything that is portable in cleartext or structured form: profile attributes, email addresses, social account links, consent records, and preference data. Pull it through the Identity Cloud export API into a versioned, encrypted file, validate record counts against your inventory, and load it into the replacement. Do this more than once, because you will need a fresh delta export close to cutover to capture users who registered or changed data after your first pull.

Passwords are different. Identity Cloud stores password hashes, not plaintext, and a good replacement will use its own hashing scheme and work factor. You generally cannot just move hashes and have them work. Two options:

• Just-in-time (JIT) re-hashing. Import the legacy hashes into the new system as an opaque "legacy" credential. On a user's first login after cutover, the new system verifies the password against the old hash, and if it matches, silently re-hashes it under the new scheme and discards the legacy value. Users never notice. This is the default and the right answer for most teams.
• Forced reset. Import no passwords and send everyone a reset link. Only choose this if your legacy hash algorithm is unsupported or if you want a clean credential break for security reasons. It generates support load and drops re-engagement, so treat it as a fallback.

JIT depends on the replacement supporting your specific legacy hash format. Confirm that in vendor selection, not after export.

Mapping features to a replacement CIAM

Map each capability you inventoried to a concrete requirement in the replacement, and treat any unmapped row as a migration risk, not a rounding error. Use this table as the starting checklist.

If a row has no clean mapping, decide now whether you rebuild it in application code, drop it, or disqualify the vendor. For a deeper comparison of candidates, see Top CIAM solutions and the CIAM Compass portal. If you are also adding B2B SSO, Add SSO to Your B2B SaaS covers that path.

Cutover runbook with rollback

Cut over in stages with both systems running in parallel, and never flip DNS until dual-run has proven the new system against real traffic. Here is the runbook.

1. Stand up the replacement. Recreate registration fields, social provider apps, MFA policies, and the profile schema in the new tenant. Configure JIT password import against your legacy hash format.
2. Bulk import. Load the full export, then reconcile record counts and spot-check a sample of profiles, consent records, and social links against source.
3. Dual-run in shadow. Point a small percentage of authentication traffic at the new system while Identity Cloud remains authoritative. Confirm login, social login, MFA, and JIT re-hashing all work on real users.
4. Delta sync. Run a fresh export to capture profile changes and new registrations since the bulk import, and load the delta. Repeat this on a schedule until cutover.
5. Freeze writes on the old system. Set a short maintenance window where Identity Cloud stops accepting new registrations and profile edits, run one final delta, and make the new system authoritative.
6. Switch routing. Update DNS or your auth gateway to send all traffic to the new system. Keep TTLs low ahead of time so the switch propagates fast.
7. Monitor against rollback triggers. Watch login success rate, JIT re-hash success rate, MFA challenge completion, and support volume.

Define rollback triggers before you start, not during the incident. Roll back if the login success rate drops below your baseline by a set margin, if JIT re-hashing fails for a measurable share of users, or if error rates spike. Because DNS still points at both systems during dual-run and Identity Cloud stayed authoritative until step 5, rollback is a routing revert, not a data restore. Keep the old system live for a defined grace period after cutover so rollback stays cheap.

User-communication plan

Tell users what is changing, when, and what they must do, and design the migration so that for most people the answer to "what must you do" is nothing. Silent is the goal. JIT password migration is what makes silent possible.

Sequence the messaging:

• Ahead of cutover. A short heads-up that you are upgrading the sign-in experience, with a date range. No action required. Set expectations without alarming anyone.
• At cutover. Only message users who must act. If you chose JIT, that is nobody. If you chose forced reset, send the reset link with a clear reason and a support link.
• Edge cases. Users with expired sessions, deactivated social providers, or unsupported legacy hashes may hit friction. Give them a clean self-service recovery path and staff support for the window.

Minimize forced re-authentication by preserving active sessions where you can and by letting JIT handle passwords on the natural next login. Every forced reset you avoid is retained engagement and a support ticket you never receive.

What this costs you and common mistakes

The real cost is engineering time and calendar time, not just the new subscription. Budget for schema recreation, social provider re-registration, export and reconciliation scripting, dual-run testing, and support coverage during the window. Most migrations run weeks to a few months depending on record volume and how many features are live.

The common mistakes:

• Starting late. The dependencies are serial. A compressed timeline forces a forced-reset migration you did not want.
• Assuming password hashes port directly. They usually do not. Confirm JIT support for your specific hash format before you commit.
• Forgetting consent records. These are compliance artifacts with legal weight. Export them with timestamps and versions, and verify them.
• Skipping delta sync. Users who register between bulk import and cutover vanish if you only export once.
• Cutting DNS before dual-run. Without a proven parallel run, you have no cheap rollback. Prove it first.