One time migration via script
:::tip Guideline only As a rule of thumb, one-time migration fits user volumes below ~500k. Volume, downtime tolerance, change rate, and go-live style matter more than the number alone — choose together with us or a partner if unsure. :::
This approach can be used when you accept a maintenance window (small downtime) and switch to cidaas with all applications at once — typically for smaller to mid-size user bases (guideline: below ~500k users).
In the one time migration mode we mostly use a script based solution. For very small instances it could be a csv-importer or something similar.
The script could also be implemented as a create or update script, so you can run the script multiple times without any issues. If the amount of users is medium sized it might make sense to do a full migration a few days before the GO-live and a delta sync of only a subset shortly before the GO-live. By this the risk of data deriviations between both system can be lowered to a minimum.
Technically we don't need a downtime to switch to cidaas, but if we use the one time migration we will not migrate data which will be added, changed or deleted between the export of the old system and the import to cidaas. To avoid missing data we need to block changes in the old system.
As you can see in the graph the data will be synced once in a bulk to cidaas and after that, the switch to cidaas can take place.
Technical implementation
cidaas provides a REST Bulk Migration API:
| Path | {your-domain}/users-srv/user/bulk |
| Max batch size | 1000 users per request (recommend smaller batches, e.g. 50–100, via a queue for large migrations) |
| API reference | Migrate (add or update) user entities |
- API scope — The endpoint requires
cidaas:bulk_user_create. migrationMode— Only needed if you must overwrite passwords on users that were already migrated. Ask support to enable this configuration when required.
See the User Migration Guide for token setup and payload mapping.