Planning Your AIC Migration: Timeline and Complexity Considerations

Akamai Identity Cloud reaches end-of-life on December 31, 2027. Between stakeholder alignment, vendor evaluation, security review, procurement, and phased rollout, most organizations need 12–18 months from decision to completed cutover — so teams that want meaningful buffer before the EOL date need to be moving now.

Akamai has published official migration guidance and designated Next Reason as a Migration Center of Excellence for AIC transitions. We’ve been working with AIC customers on migration planning since the deprecation was announced. The earlier a team starts, the more control they have over approach, timeline, and target platform selection.

Our work in this space spans the full lifecycle — translating existing AIC configurations and customer requirements into target architecture designs, building migration plans, executing the migration, managing zero-downtime cutovers, and operating the new platform post-launch. What follows covers the main decisions and complexity factors we work through with every AIC customer.

Three Migration Paths — and What They Actually Mean

The right migration path depends on your environment’s complexity, your timeline, and how much you want to use this transition as an opportunity to modernize your identity architecture more broadly.

Lift-and-shift is the fastest path. You’re moving your existing AIC configuration and user data to another CIAM platform with minimal structural changes. The tradeoff is that you’re recreating what you have, not improving it. This makes sense when the timeline is tight or your current identity flows are already working well.

Phased migration moves your existing architecture to a new platform incrementally, running both systems in parallel while user segments and applications cut over in stages. The architecture you end up with reflects what you had in AIC — cleaned up, but not redesigned. This is the most common approach for complex environments where continuity and risk management take priority.

Greenfield rebuild starts from the architecture question rather than the migration question. Rather than replicating what exists, you’re designing the target CIAM environment based on where you want to be — which may look quite different from what AIC supported. This makes sense when the current setup has structural limitations worth addressing, when the business has changed enough that a like-for-like migration wouldn’t serve you well, or when there’s appetite to use the transition as an opportunity to adopt modern security patterns and build toward capabilities — like passkeys, adaptive authentication, and threat detection — that weren’t feasible or well-supported in the existing architecture. It takes longer, but the output is a purpose-built platform rather than a ported one.

Consent Data Migration

Consent data is well understood as a migration complexity, but the scope of what’s actually accumulated in a long-running AIC instance still has a way of expanding once the inventory starts. Organizations that have been running AIC across multiple markets for several years tend to find consent categories that evolved organically over time, inconsistently structured across brands or regions. The mapping work is methodical but time-consuming, and it needs to happen early enough to inform the project scope rather than revise it mid-execution.

A migration is also a natural point to evaluate whether AIC’s approach of managing consent as part of the identity record is still the right architecture. We’ve worked with clients who used the transition to move consent management to a dedicated platform — OneTrust in particular — rather than replicating the same structure on a new CIAM platform. For organizations with complex, multi-market compliance requirements, separating consent management from identity can simplify both systems and make ongoing regulatory reporting more tractable. It adds scope to the migration, but for the right organization it’s scope worth taking on.

DataSync: Purpose-Built for AIC Migrations

DataSync is a proprietary tool we built specifically to support migrations off AIC. Most generic migration tooling requires significant customization to handle how AIC structures identity data — DataSync is designed around that structure from the ground up, which dramatically reduces the time and complexity of migrating user data and removes a meaningful source of risk regardless of which migration path you’re taking or which platform you’re moving to.

In practice, DataSync keeps identity data in sync between AIC and the target platform continuously during the migration, routing authentication requests based on each user’s current state. This means both systems stay live throughout the transition — users aren’t aware anything is moving, and your team isn’t managing a hard cutover window. You can move by application, region, or user segment at whatever pace makes sense, with data integrity validation at each stage and rollback capability maintained throughout.

The platform-agnostic design is intentional. Target platform selection is a consequential decision and teams shouldn’t feel constrained in that evaluation by tooling limitations on the migration side.

Where to Start

If you’re on AIC and haven’t started planning yet, the most valuable immediate step isn’t picking a target platform — it’s a thorough inventory of your current AIC environment. Most organizations don’t have a complete picture of their AIC configuration, the applications dependent on it, or the scope of their consent data until someone sits down and maps it out.

That inventory shapes everything else: which migration path makes sense, what the realistic timeline looks like, and where the risks are. The later it happens, the less room there is to absorb scope that wasn’t visible at the outset — which adds real risk to completing the migration ahead of the EOL deadline.

As Akamai’s designated Migration CoE, we offer a migration assessment that covers exactly this ground. If you’re managing customer identities on AIC, book a conversation →