How just-in-time migration makes your CIAM transition easier 

So you’ve decided to migrate your customer identities to a new solution. Maybe you’re moving away from a homegrown tool as your organization and product offerings scale, or maybe you need a more sophisticated solution that’s prompted you to seek out a new vendor.

But let’s face it: When you hear the word “migration,” visions of months-long project plans start dancing in your head.

If lengthy planning cycles and an endless schedule of cross-functional meetings aren’t high on your bucket list, then just-in-time migration might be the right (and a less headache-laden) approach for you.

What is just-in-time migration for customer identities?

Just-in-time migrations simply move users over one by one as users log in.

Sounds simple enough, right?

Well, if you’re familiar with legacy IAM solutions, then you probably already know that just-in-time migration is not the way that organizations (and their vendors) typically approach migrations.

Since the beginning of IAM time, bulk migrations were the only way to go: “Gimme a .CSV file with every user’s info and I’ll load it into the system.” Remember, most vendors designed their products to serve workforce use cases – not customers – where it’s perfectly acceptable to dump user IDs into a new system and then expect all those users to jump through new hoops to sign up to use the new system.

How just-in-time migrations solve “the password problem”

Bulk migration typically doesn’t work well for customer use cases. Why?

Blame it on the passwords.

They’re exactly what makes migrating user profiles so tricky. By definition, passwords are “secret.” To keep them secret, passwords are “scrambled” in a way that isn’t reversible, also known as hashing. So migrating user IDs and their passwords is rarely as simple as copying and pasting them into a new piece of tech (that would be so nice though, wouldn’t it?).

A just-in-time migration approach solves the “password problem” by temporarily keeping your old customer datastore in place. As your existing customers log into your new CIAM system, their info (including their password) gets checked – via orchestration – against the old system. If it matches, it’s moved from the old to the new customer datastore.

Done right, your customers won’t know anything’s different – there’s no password to reset and no new user ID to create. The big benefit of this approach is that your users don’t have to change a thing – it’s business as usual.

Questions to consider before starting your just-in-time migration

Here are three questions that’ll help you determine if a just-in-time migration approach is right for your org, and get you prepared to kick off the project.

Where is your customer ID store today?

Since you’ll need to keep your old customer ID store in place during a just-in-time migration, you’ll want to know what’s involved. Is it a homegrown solution that is tightly coupled to your application? Is it a SQL database sitting somewhere in the cloud? Is it Azure AD or an existing IAM/CIAM solution? Wherever it is, think about what’s required to keep it online for six months or so.

How often do your users log in?

The answer to this question will give you a sense of how long it’ll take to migrate customers into your new ID store with a just-in-time migration. Check your authentication logs. If 50 percent of customers log in once a month and 85 percent log in at least once every 90 days, your migration should be largely done in about three months.

Who gets the call when a customer can’t log in?

Because of the disruption involved with a bulk migration, you can expect lots more support calls if you choose to go that route. If your customer support team doesn’t typically handle super technical questions, you’ll need to think through where you’re going to route those calls and what training you’ll need to give that team.

How just-in-time migration benefits your customers and your dev team

There’s more good news about just-in-time migrations: They offer both your customers and your dev team multiple benefits.

It’s a more customer-friendly approach.

The TL;DR? A just-in-time migration is by far the more customer-friendly approach since your customers don’t need to reset their username or password with this process.

In contrast, with a bulk migration every user will likely need to reset their password when they log in, which will have your customers jumping through clunky (and unwanted) hoops to make that reservation or complete that purchase.

Even if you’ve sent them several emails to give them a heads up about the change, many of those missives will have gone unread. You can expect a spike in support calls from locked out – and unhappy – customers. A small percent of customers may just abandon their old accounts and create new ones if the login speed bumps are too big.

Finally, if your users log in frequently – daily or even weekly – there’s a chance that recently-created accounts may not get loaded into the new system since there’s often several days of data cleansing that takes place between the export and the import of that pesky .CSV file.

It’s a faster process for your dev team.

The big surprise for folks that haven’t considered a just-in-time migration approach is that it’s far more efficient than the alternative. How can that be?

Well, since there’s no impact on customers you don’t need to get as many internal teams involved. There’s no need for a big customer communications effort, and less training is required for your customer support team. In short, that project plan is going to look a lot simpler (and so is your calendar). Plus, the IT team doesn't have to choreograph the data export > cleanse > import process.

Sound too good to be true? There are a few things that you’ll have to do for a just-in-time migration. Like we said before, you’ll need to maintain your existing database during the migration period. There’s also a small bit of coding involved and – depending on how often your users log in – there may be a small number of users at the end of the migration period that haven’t logged in, which you’ll need to manually port over. However, your team can complete these to-dos in about a week. Compare that with a 6+ month timeframe for a bulk migration, which is the timeframe that one of our customers experienced when they switched CIAM providers previously before onboarding with Strivacity.

If you’re still curious about how a just-in-time migration stacks up against a bulk migration, here’s a handy chart we created for you so you can weigh the pros and cons of each:

Getting started with user migration

In short, migrating your customers doesn’t have to be a pain in the neck. Just-in-time migration can be a good approach and can let you get started sooner than you think.

There will always be edge cases where a bulk migration makes sense. For example, if you’re an insurance company where users log in less than once a year and maintaining your old customer store is prohibitively expensive, then bulk migration is probably the way to go. However, for most orgs who have users who log in frequently, a just-in-time migration approach is often the better choice.

Have other questions about migrating users to a new CIAM solution, or curious about where to start? Send us a note – we’d love to chat with you.