Guide

Migration Guide

Migrate off of Akamai's Identity Cloud platform

Suggest Edits

With the upcoming EOL of Akamai Identity Cloud (AIC) in 2027, migrating to a new Customer Identity and Access Management (CIAM) platform is a critical step toward ensuring uninterrupted service for your customers, as well as modernizing and upgrading your CIAM capabilities. This guide is designed to support you through the migration process by outlining the available migration assistance options, providing clear pathways for gathering all necessary artifacts from your current AIC service, and sharing best practices to facilitate a smooth transition.

Whether you’re planning a full migration or a phased approach, understanding key considerations—such as data integrity, end user experience, and compliance requirements—is essential. By following the recommendations in this guide, you can minimize disruptions, maintain a secure identity infrastructure, and unlock the full potential of your new CIAM platform with confidence.

Migration service options

  • Self-service with this migration guide for assistance.
  • Migration assistance from Akamai Professional Services (PS) via your existing PS package, or you can add one to your Akamai contract. Please contact your Akamai representative if you'd like to discuss this option.
    • Note that Akamai PS can only help with the migration from the Akamai side, not on the Ping (or other CIAM provider) side.
  • Migration services via Next Reason, an Akamai partner with CIAM and AIC-specific expertise who can help as much or as little as you choose, and has the flexibility to help on both the Akamai side and the Ping (or other CIAM provider) side. This requires a contract with Next Reason. Visit Next Reason for more information or send an email (aic_migration_experts@nextreason.com) to engage Next Reason’s global AIC migration team.
  • Migration assistance from Ping or other new CIAM provider via their services and support offerings. Please contact your new CIAM provider's representative to discuss this.
    • They should be able to help with the migration to their platform, but wouldn't have direct access to help with exporting from AIC.

Migration strategy

How should I contemplate migrating sites, apps, and users to a new CIAM platform? Building a strategy of what is acceptable and what is not will help determine what your end solution looks like. In many cases, you will need to build scaffolding in order to migrate from one platform to another depending on what experience you want for your end users.

Strategy considerations

Brand-by-brand or all at once

AIC customers with brand-specific sites can migrate brands independently if possible. When brands share the same end user profiles, it can get complicated and may require all brands to move at once.

Hard cutover

Performing a hard cutover where all authentication is switched from one platform to another in one fell swoop may be the easiest to plan for but hard on end users as they will likely have to relogin. However, if reauthentication is acceptable, this is the easiest path.

Lazy migration

A lazy migration is to migrate individual end users into the new system as they authenticate with AIC. This typically provides a seamless experience for end users and they continue on with sessions and tokens from the new system when complete. However, the login mechanism will need to move fully onto the new system by the end of 2027, when authentication with AIC will no longer be available.

Mobile devices

The hardest to plan for is mobile devices. Often, an update to the mobile app is required to onboard a new CIAM implementation which will require all mobile users to update their app in order to use the new system. Given the time it can take for mobile users to update, the new system may need to be in place far in advance of closing out the old system.

Domains and CNAMEs

If you have a mobile app that calls one of AIC's domains, you'll have to release a new version of the app to call the new CIAM platform's domain when you make the switch.

A better approach might be to update the app early on to call your own domain and your own service that points to AIC. Then when the time to switchover comes, you'll update your CNAME or service, not the mobile app itself, to point to the new CIAM platform. Doing this means you can update the app and let your end users start to upgrade to the new app version far in advance of the actual switchover, meaning fewer end users will experience broken functionality or a forced update.

Gather AIC artifacts

Take an inventory of all your AIC artifacts to understand everything that may need to be migrated or re-created in the new CIAM platform. This includes:


Regions

Most likely, you already know which regions you store user profiles in. (Note: This is unrelated to language/locale support. When we say "region" we’re referring to location of data storage.) If you’re not sure which AIC-supported regions you use today, you can find out in 1 of at least 2 ways:

  • Consult your Akamai Identity Cloud contract. Regions should be clearly spelled out in the contract, since this is a fundamental basis for payment.
  • Log in to the AIC Console. Assuming you are the highest-level administrator of AIC on behalf of your company, you should have access to all the AIC regions your company uses. See your current region in the top-right corner of the Console after you login (example: EU). If you click on that region, you’ll see a list of all other regions you store user profiles in (assuming you have access to all your regions). You can click into each region to see your Capture application(s) there.

Capture applications

Capture applications are essentially AIC environments. You have at least 2 Capture applications per region you are provisioned in - 1 production and 1 or more lower environments (example: Dev, Test, QA, Prod). To see what Capture apps you have:

  • Log in to the AIC Console. Assuming you are the highest-level administrator of AIC on behalf of your company, you should have access to all the AIC regions and Capture apps your company uses. See your current region in the top-right corner of the Console after you login (example: EU). Your Capture apps in that region are listed in the left-hand menu (example: MyCompany Prod, MyCompany Dev). If you use more than one region, you can click into each region to see your Capture application(s) there.

Entity types

"Entity types" are user directories - siloed datastores containing your end user profiles. You can use the following endpoint to get a list of your entity types per Capture app:

Schemas

Every entity type has a custom schema which defines the data you store in user profiles. It includes things like data attribute names and types, constraints, and validation rules. You can use the following endpoints to view your schema and validation rules per entity type:

Password hashing algorithms

Akamai Identity Cloud supports a single password hashing algorithm for all customers: bcrypt. You can see this firsthand if you run an /entity or /entity.find API call and return the "password" attribute; the stored password attribute is a special object containing both the hashing algorithm "type" and the hashed password "value". Example:

"password": {
	"type": "password-bcrypt",
	"value": "$2a$10$h6VNV47uzr2z.kGVw.PqueYZS9gJUr5kBu/4QPK1MLg.4DAeovN2G"
}

For some AIC customers, other hashing algorithms may have been supported for migration purposes only (in other words, when they implemented Janrain/AIC and migrated user profiles to Janrain/AIC). After this in-migration, when a user logs in via the AIC service, their password hash is automatically converted to bcrypt. This means, for such customers, most if not all user passwords are now hashed with bcrypt, but it’s possible to still have some user passwords stored with a non-bcrypt hashing algorithm.

Unfortunately, there’s no easy way to find exactly which non-bcrypt hashing algorithms might still be floating around. What we DO know is that any non-bcrypt passwords can only belong to users who never logged in with the Janrain/AIC service. So if you migrated to Janrain/AIC 5 years ago, those users haven’t logged-in in at least 5 years.

With this in mind, we recommend that you:

  • Let your new CIAM provider know that your current user passwords are hashed with bcrypt, and ideally they will support bcrypt for your migrated passwords. This will allow your active users to seamlessly login via the new CIAM service.
  • Consider deleting old, inactive user records. You can do this by searching for entities whose lastLogin date is less than the date you migrated users to AIC. For example, if you migrated to AIC 5 years ago, you might use a filter like this: "filter=lastLogin<='2020-01-01'". If a deleted user comes back to your application, they’ll need to create a new account.

If you migrate all users, including those that may have a non-bcrypt password:

  • Users with a bcrypt password may be able to login seamlessly post-migration (assuming bcrypt is supported in the new CIAM platform)*
  • Users with a non-bcrypt password may have to reset their password post-migration (e.g. their login will fail, and they can go through the forgot-password flow to reset it)*

If you migrate all users to a CIAM platform that does not support bcrypt, all users may have to reset their password post-migration.*

*Your exact options and solutions may differ depending on the CIAM platform. Please discuss this with your representative from the new CIAM platform.

Clients

API clients, also known as Capture clients or properties, are keys used to access your user profiles and AIC configurations. They’re used by your various customer-facing and internal applications, as well as internal users.

You can use the following endpoint to view all your API clients and their permissions per Capture app:

If you use access schemas: You can also use this endpoint to view your access schema per client. An "access schema" is an optional feature that defines which schema attributes a client can access and with what permissions.

Application and client settings

Settings can be configured per API client, or as global defaults (used across all clients in the same Capture application). The recommended way to grab all application and client settings is to export them from Console. This provides them all in a single CSV file.

Alternatively, you can use the following API endpoints to gather your settings:

Flows and translations

Flows are large JSON files that define elements of the user experience with login, registration, and profile management.

See Flows and flow management APIs for all endpoints you can use to gather the following:

  • List of all your flows
  • In each flow:
    • Forms and fields used
    • Supported locales and corresponding translations
    • Email templates and SMS messages
    • Custom text strings

📘

There are pieces of the flow that are inaccessible via API or the Console, like behind-the-scenes logic (Example: When a user registers, compute X, Y, and Z and write the resulting values to their profile). If you need to gather these hidden elements, or just understand what you have, you must request this from your Professional Services representative.

Console users and permissions

Your internal Identity Cloud administrators, developers, and even customer care agents use the Identity Cloud Console to view and edit clients, settings, flows, schemas, and user profiles. You may need to understand who has access to the Console and what permissions they have. You can export this agent information from the Console.

📘

Console agent roles reference

Hosted Login configurations

If you’ve implemented Hosted Login, you additionally have Hosted Login configurations you can migrate.

OIDC clients

OIDC clients are keys used in implementing Hosted Login on your sites and apps. They connect to Hosted Login policies as well as your Capture application(s), configurations, and user directory. You can use the following endpoints to view your OIDC clients:

Login policies

Login policies contain connections to your user directory and other OIDC login configurations. You can use the following endpoints to view your login policies:

Extended login policy configurations can be viewed per policy at these endpoints:

Token policies

Token policies contain your OIDC token-specific configurations. You can use the following endpoints to view your token policies:

Extended token policy configurations can be viewed per policy at these endpoints:

Session policy

Hosted Login sessions can be enabled or disabled, and the default TTLs (Time To Live) are configurable via the session policy. There is one (1) session policy per Identity Cloud customer ID. You can use the following endpoint to view your session policy:

Social providers

If you allow your end users to login via a social provider, like Facebook, then you’ll want to gather the social providers you have configured to use with AIC. You can use the following endpoint to view your configured social providers per Engage (Social Login) app:

📘

What is my engage-realm? You may have one or more Engage (Social Login) apps, each with its own "Engage realm", which is the unique domain for that Engage app.

The default domain for AIC's Engage realms is rpxnow.com. And by default, your Engage realm will be a subdomain like my-app.rpxnow.com. To find your default Engage realm, look for the rpx_realm setting in your application and client settings.

Example: If your rpx_realm is "hats4cats", then your Engage realm is: hats4cats.rpxnow.com

In Production, it's common to use a custom Engage realm, which replaces the rpxnow.com domain with a domain you own. To find your custom Engage realm, look for the rpx_custom_realm setting in your application and client settings.

Example: If your rpx_custom_realm is "login.hats4cats.com", then your Engage realm is: login.hats4cats.com

Note that, for each social provider you have configured to use with AIC, you have a developer app in the social provider's portal. This is where you have your provider-specific settings and configurations for social login. You’ll need to log into the provider’s developer portal (example for Facebook: developers.facebook.com) with the account that owns or has access to your provider app.

When you migrate to a new CIAM platform, you’ll need to update any settings in your provider app that point to Janrain/AIC. This could be things like allowed domains or redirect URIs. In production apps, this change may need to coincide with your production migration.

📘

Please refer to your new CIAM provider's social login configuration instructions for details.

Webhook subscriptions

AIC Webhooks allow you to monitor user profile activities by subscribing to profile-related events (creations, deletions, and updates). You may want to understand what profile events you’re subscribed to today, so you can configure a similar monitoring system in the new CIAM platform. You can use the following endpoint to view your webhook subscriptions:

Integration Bus tasks

AIC's Integration Bus is a data integration service provided via the SnapLogic platform. It is primarily used for exporting data on a regular basis to an S3 bucket or sFTP server.

If you use the Integration Bus, your pertinent team member(s) should have access to the AkamaiProd environment in SnapLogic. In that environment, on the Manager tab, you would have one or more projects under Project Spaces > Identity Cloud Data Export. Click on your project(s) and look for any Tasks, which you can click on to see what triggered or scheduled exports you may have configured/running.

📘

If there are no Tasks, then you don't have any exports configured to run. It's possible your team tested the Integration Bus at one time but never committed to using it, or have only used it for ad-hoc, manual exports. In either case, there would be no Integration Bus automations to migrate / mimic in the new CIAM platform.

If you’re not sure whether you use the Integration Bus or not, reach out to your AIC representative and they can help you confirm.

Export my user data

Akamai Identity Cloud stores your end-user data (user profiles) in secure database tables we refer to as "entity types". You can export your user profiles in 2 ways:

  • Via API
  • Via Integration Bus (serviced by the SnapLogic UI)

Export via API

When exporting via API, you’ll use the /entity.find endpoint to retrieve a subset of user profiles at a time, repeating the call at a controlled pace until all user records have been retrieved. See Querying large data sets for details and a sample Python script.

Export via Integration Bus

You can alternatively export your user records via the Integration Bus, specifically using the Data Export pattern. This method is built on the same /entity.find endpoint and iterates through records just like the sample Python script mentioned above. Major differences are:

  • Configuration is done via a SnapLogic-specific config file and most required tasks are done via the SnapLogic UI
  • The data is exported to an sFTP server or S3 bucket owned by you
  • The data is exported in either CSV or JSON format
  • There is a step-by-step guide provided by Akamai to configure and run this export, however any unresolvable issues that arise will likely need to go through SnapLogic tech support (not Akamai)

📘

Have a question about passwords? Passwords are part of the user record that is exported. Both the hashed password and the name of the password hashing algorithm are stored in the record. See Password hashing algorithms for more information.

Best practices

Remain compliant with data regulations

When you're handling user data, it's important to comply with local data laws and regulations. It's likely the person(s) responsible for migrating user data from AIC to another platform will export the user data, store it somewhere, then later import it into the new system. This may happen multiple times, since there are typically unforeseen issues that arise during this process.

Make sure all person(s) who will be handling the user data understands the local laws and regulations governing that data. For example, the data may need to be kept in the region where those users reside.

Securely transfer and store the data

Transferring user data securely is crucial to maintaining privacy, compliance, and integrity. Secure methods for migrating data include using TLS (Transport Layer Security) 1.2 or 1.3 to encrypt data while it is being transferred, and using SFTP (Secure File Transfer Protocol) or FTPS (File Transfer Protocol Secure) for batch transfers.
It’s also important to encrypt sensitive data at rest. The following OWASP cheat sheets may help:

Updated about 20 hours ago