User Data Migration
Hiya,
The final "ion" is migration. This is unique compared to the previous options for getting users into your CIAM system (registration, federation, and creation) because here, the users explicitly exist in a different, legacy, CIAM system.
This means that some things are simpler. You know what data is available to you because it is already present in the legacy system. It is also more likely to have a fixed timeframe rather than be ongoing.
Complexities
However, there are some complexities in migration that don’t exist for other options. The biggest one is that you'll be moving secrets from one system to another. These secrets include:
hashed passwords
TOTP secrets
MFA account recovery keys
If you can't access these secrets, that constrains your options. A migration of user data is different than a typical data migration because of these.
Options
You have three main options when you are migrating user data.
Bulk or big-bang
Drip or slow
Hybrid
Let's look at each of these in turn
Bulk
A bulk migration is when you migrate all the user data from the legacy system to the new system at one point in time. Then you cut over the applications to use the new system.
This is high effort, high risk, but also is limited in scope. When you are done, you're done. Much of the work takes place without impacting users and you can often set up a staging environment to test this rigorously.
Another benefit to this approach is that you can merge two or more data sets. If you have N applications which all have their own user data and you want to move to a central identity store, the bulk migration will let you merge identities (as long as you have a common thread, typically an identifier like an email address, phone number, or username).
This approach doesn't work if you don't have access to legacy system password hashes unless you want to force all users to reset their passwords. Not a good look.
Drip
In this migration pattern, instead of moving over user data all at once, you move users over as they authenticate. Your new system delegates the first authentication to the legacy system. If the legacy system indicates the user has provided the correct credentials, the new system stores the provided password and other returned profile data.
This pattern doesn't move MFA data, but is effective at moving over passwords and other profile data.
The upside of a drip migration is that you can migrate their data without access to password hashes or forcing password resets.
There are two downsides:
you must have legacy API login access (the ability to post a username and password).
you need to run and pay for two systems for a period of time. How long? Depends on how often your users log in and what percentage you need migrated. Here's more on how to calculate this timeframe.
You should also consider what to do with users who have not logged in and been migrated during the drip migration. You can lose those users, migrate them with unknown credentials and allow account recovery, or bulk migrate them.
Hybrid
You might combine these two methods, with a bulk migration moving most of the user data, but using a slow migration to move over users who register after the legacy data is exported.
This is extra effort, but if you have user registrations you don't want to lose between when you can export your data for a bulk import and when you can cutover your system, this approach can work.
External Data Dependencies
Often times there will be external dependencies between data in a CIAM system and other systems, such as hostnames, role names, and user ids. If at all possible, limit the changes so the underlying CIAM system switcheroo isn't visible to all the downstream applications that depend on it.
Why move?
I buried the lede!
This is a big question worth spending some time on. CIAM systems tend to be relatively undifferentiated. This is why the functionality is a good candidate to outsource to a third party system. It's also sticky, because it's risky to interfere with the ability of your customers to gain access to your applications.
Why move from one system to another? It won't be a trivial undertaking, so why expend the time and money to do so?
There are a few reasons:
cost: if you are paying for a system, prices may increase over time and at some point, the effort to move may have an ROI compared to future costs
functionality: while mostly undifferentiated, there are differences, especially as you get into more esoteric use cases. For instance, Stanford University requires encrypted SAML assertions and Swedish consumers expect to log in using BankID. Not all CIAM providers offer these, and if they become critical for your applications, that may motivate a move.
system end of life (EOL): Companies buy other companies and the new entity may consolidate product offering. If your current CIAM provider no longer offers new versions, eventually you'll have to deal with the security and functionality issues.
offloading effort: you may want to move from a home-operated open source or homegrown solution because you've run the numbers and determined that outsourcing login functionality makes sense.
Conclusion
Migration is a lot less common than the other ways of getting users into your CIAM system, but when you need it, you need it.
Hope this overview of user migration helps you understand some of the complexities of moving between CIAM systems.
Dan