The world is changing fast and the pace is only accelerating. It took about 68 years for airlines to reach 50 million customers.  TV took about 22 years to get 50 million viewers. Facebook took about 3 years to get 50 million subscribers. But for the recent popular mobile game, Pokemon Go, it took only 19 days to get 50 million players (chart).

In the IT world, new features and innovations are introduced all the time and business IT systems must evolve to stay competitive and efficient. Solutions that were once state of the art might have become outdated and hold your business back from its full potential. The same goes for IAM (Identity and Access Management) systems.

In an earlier article from this IAM migration blog series, ‘8 signs you should migrate your IAM system‘, Keith Uber, Ubisecure’s VP of Customer Success, talked about different drivers behind IAM migration projects. In this chapter, I will show you the different approaches and considerations for your IAM system migration. The next chapter covers approaches for account linking utilising User-Driven Federation and Directory User Mapping, as well as other tips and tricks.

Migration method options

There are multiple ways to handle a migration project. What the best option is for your company depends on your business requirements but, roughly speaking, there are two main strategies: big bang migration and trickle migration. Let’s run through the two approaches.

Big bang migration

In big bang migration, a.k.a. ‘rip & replace’, the main idea is to extract data from the legacy system, import it into a new one and reconfigure all related applications for all users in one go.

This means that you switch all of the system’s identities to a new system during a certain maintenance window, which is usually when there is a minimal traffic flow to your applications, e.g. overnight. In many cases, after the change is done, users won’t even notice the difference. If the new IAM system is API-based then the user interfaces will not need to change – functionality is simply integrated to the existing application. If the new system is not API-based, users might have to deal with new front-end screens and operating procedures, etc.

Big bang migration simplifies the planning of the project schedule, since you can do the actual data import execution of the project inside a relatively small, predefined time window.

big bang migration

Big bang migration

Trickle migration

Trickle migration – a.k.a. ‘phased migration’, ‘synchronised migration’ or ‘iterative migration’ – involves running the two systems (old and new) in parallel, migrating target applications one at a time and decommissioning the old system gradually, until everything is running via the new IAM system.

This method offers a phased approach, which gives you time to monitor a successful execution of the step by step migration process, while the services are still partly relying on the old system and running simultaneously with the new one.

trickle migration

Trickle migration

Which method is better for my business?

With sufficient planning, either method will ensure success for your IAM system migration. Yet it’s important to be aware of the risks of poor planning with each method, so these can be mitigated against.

Big bang migration, due to its short time window for changeover, could be stressful if something goes wrong during that time window. In comparison, trickle migration offers a smaller comparable risk by implementing at individual stages, particularly if there is a huge amount of data to be imported.

On the other hand, trickle migration can be more complicated to plan and execute since there can be several distinct components affecting the migration, meaning the project’s time frame has more potential to overrun. Also, you have to think carefully about the synchronisation between the old and the new systems which are in operation at the same time. Therefore, a lot of companies prefer the big bang method for IAM system migration at least at the application level. This means that one or a few applications would be migrated all together in the first phase. Then, later, the other applications can be migrated.

I will show you how to mitigate against risk with whichever method you choose in the next section – ‘user migration considerations’.

User migration considerations

Your IAM system is a central piece of your enterprise’s services. Therefore proper preparation for the migration project is necessary regardless of your chosen strategy – big bang or trickle migration.

Careful planning ensures on-schedule success, and minimises service downtime. In order to guarantee a successful execution of your project, consider the following steps:

  • Make sure you have a fresh back up of the data before starting the execution phase, and that you test that the backups are functional before proceeding.
  • Always transfer existing customer credentials where possible. The chances are that you can import most of the user attributes from the legacy system to the new IAM system. However, there might be some attributes that are more challenging to transfer, such as passwords or SSNs (Social Security Numbers). This type of sensitive information is often saved in a hash format. This is not a problem if your new IAM solution supports the same cryptographic hash algorithms as the old one. (More on password migration in the next section.)
  • Allow parallel logins during a migration period if required. If you choose to use the trickle migration method, make sure that the old system is running and is accessible at the same time as the new one. You can conduct the import in several steps that can be phased in many ways, such as by user group, business unit, customer group, region, use case, a target application, etc.
  • Always transfer existing customer account links where possible. Sometimes your system has a link to log in via another trusted party’s service, such as a social account login or third-party persistent IDs. Another case is where, during login, another service returns one or more attributes to match the account of a local user. You should preserve these links to the new service during the migration project. I will talk more about these cases in my next blog, coming soon: IAM System Migration Approaches Part 2.
  • Thorough testing and audit of access control logic. Both pre-testing and post-testing are essential parts of migration projects. Typically, an enterprise has a test IAM environment in addition to a production environment. Establish the test environment before the production environment and utilise it in the pre-testing stage by migrating the system to it. It is also important to test the environment after (and possibly during) the migration to see that everything is working as planned. Once the test environment is functioning you can start to migrate the production environment.

Data import

Importing the user data from your legacy system to a new one is a crucial part of the migration project. Here, the migration strategy plays a big role: should you get everything imported in one go (big bang migration) or should you run both systems simultaneously and move the data in phases (trickle migration). Here are some options you can choose from.

One-off import

In the case of big bang migration, you can use a one-off import method. A good option is to use an import tool if it is provided by your IAM provider. A ready-made tool makes the process much easier and faster. If such a tool is not available, you could create a script that utilises APIs of the new IAM system to import the data. In both cases, everything is imported in one go.

If the passwords (and possibly some other attributes) are not stored in a plain text format, find out if the new IAM system supports the same hash algorithms as the old one. If this is not the case then you cannot do a one-off data import.

Phased import

If you can’t do a one-off import, a simple solution is to ask the users to re-register their accounts to the new system. If the new IAM system facilitates it, you could send users an email invitation to a re-registration form in the application itself, importing the existing data via APIs where possible. In many cases, some of the identity attribute fields can be refilled (e.g. when the invitation is initiated from a CRM system). Thus the user just verifies that everything is correct, accepts the terms of use and defines a new password. This is then saved to the new IAM system in a hash format.

A challenge may arise if you cannot accept re-registration, or even a password reset, as part of the new system’s introduction process. ‘On the fly migration’ allows a secure rehashing of existing customer passwords, even if the password data is unavailable in the new IAM system. You can import all the plain text attributes to the new system and, when a user signs in to it for the first time, their password validity will be checked against the user directory of the old back-end service. If it is correct, the new IAM system rehashes and saves the password. On the fly migration allows a smooth registration during the login process that is transparent to the end user.

Conclusion

IT administrators go through different types of migration projects all the time. Due to the huge data sets that modern-day applications have to deal with, trickle migration has increased in popularity.  In the case of IAM migrations, the most straight forward way is to use the big bang strategy, at least at the application level – where you integrate the different customer-facing services and IAM in phases. At the beginning of the project you add a few services, and then at the later phase you add more of them and possibly some additional Customer IAM features – such as extra authentication methods, delegated user management and cross-domain federation to your partner services.

Download our free white paper, ‘Migrating your organisation’s IAM system’, for everything you need to know about seamlessly replacing IAM capability in apps and services.

Get in touch to discuss your own migration to Ubisecure’s IAM software, available as on-premise, cloud, or IDaaS – www.ubisecure.com/contact/.