Data migration is the process of importing user records from legacy systems into the Akamai Identity Cloud. The data migration process can be simple or complex, based on: 1) the state of data at rest in legacy systems; and, 2) the new target data schema with the Identity Cloud.
In this documentation, we’ll break that process down into manageable chunks, and explain how to work your way through each and every step. Those steps include such things as:
- Downloading the required files.
- Setting up your computer so it can run the data migration script.
- Mapping your legacy data to an Akamai user profile schema.
- Creating a data migration datafile.
- Creating and assign data transformations.
- Running dataload.py to migrate your data.
Is There an Alternative to Following the Process Outlined Here?
Well, sort of; after all, there are alternatives to practically anything. That said, however, the question that should really be asked, and answered, is this: are any of these alternatives truly viable alternatives?
For example, you might decide not to migrate your legacy data after all; that’s definitely simpler than migrating your data. If you go that route, however, you’ll lose all your legacy data (or, at the least, you won’t be able to access that data using Identity Cloud applications). In addition, your users will all need to recreate their accounts and repopulate their user profiles. That might be an acceptable to you but, to be honest, it’s probably not acceptable to your users.
Another option is to have Akamai do the data migration for you: contact your Akamai representative for details regarding a data migration executed by Akamai on your behalf. Taking this approach will definitely reduce your workload: for example, you won’t have to make sure that your computer meets all the requirements for running the data migration script, and you won’t have to actually run that script.
Despite that, however, your workload will not be not eliminated. Although Akamai will create the needed data transformations, perform as many dry runs as needed, and then carry out the migration, you’ll still be responsible for such things as mapping the legacy data to your Identity Cloud user profile, creating the data migration datafile (the import CSV file), and verifying that any practice runs complete successfully. That entails at least some effort on your part. In fact, unless you have a really complicated migration scenario, you might find that having Akamai do the data migration results in a lengthier and more complex process than if you did that migration yourself.
Note. Why? Largely, because, by doing it yourself, you eliminate the need for constant back-and-forth communication between yourself and Akamai support personnel. And, of course, you can do things on your schedule, not on someone else’s schedule
A final option is to write your own script for doing data migration. That’s not impossible: you just need a script that calls Akamai’s entity.bulkCreateAPI endpoint. There’s nothing wrong with that, but Akamai’s dataload.py script already uses the entity.bulkCreate API endpoint, and has proven itself to be both tried and true. Because of that, there’s typically very little reason to reinvent the data migration wheel.