Pick your source
Migrating from something not listed? The pattern below applies to any source. Contact us if you would like the professional-services team to review your plan.
The shared pattern
Every migration follows the same five phases. Only extraction differs between source systems.1
Build a parallel destination
Create the token-holding structure alongside the existing one rather than altering it in place. The original stays untouched and readable for the whole migration, which is what makes every earlier phase reversible.
2
Backfill in chunks
Read the source in batches, send each batch to
UserCreateBulk, and record the returned tokens. Backfilling runs against a live system — the application keeps serving traffic throughout.3
Verify
Confirm every source record has a token, and that detokenizing returns the original values. Do this before anything is deleted.
4
Move the application to the vault
Dual-write new records, switch reads to the vault, and run in that mode for a full business cycle. Code paths still reading the old data surface here, while recovery is still free.
5
Cut over and remove the old data
Swap in the new structure, keep the old one until you are satisfied, then delete it. This is the only irreversible step.
Mechanics common to every migration
Keep the record whole. The entire user record goes into the vault profile — not just the obviously sensitive fields, but every application attribute as well. Splitting a user across two stores leaves you reconciling two sources of truth, with some attributes protected and some not. A 120-field profile is normal; that is what the benchmarks were run against. Carry your existing primary key in the profile.UserCreateBulk echoes the submitted profile back alongside each token, so the mapping never depends on response ordering. Putting your source identifier in the indexed custom field also makes re-runs safe — a second attempt for the same record is rejected as a duplicate rather than minting a second token — and lets you look records up by legacy id afterwards.
Expect partial success. A batch does not fail as a unit. UserCreateBulk returns created and errors arrays, with a per-record reason for each failure. The usual cause is a duplicate email, phone, login, or custom value: Databunker Pro enforces uniqueness within a tenant, so records your source allowed to coexist are rejected here. Log the failures and resolve them before cutting over — those users have no token.
Make the backfill resumable. Skip records that already have a token, so an interrupted run can simply be restarted. For large sources this matters more than raw speed.
Size the database first. Bulk writes sustain roughly 5,800 records/sec on one instance, and at tens of millions of rows the database becomes the limit rather than Databunker Pro. Check the sizing guide before a large backfill — adding application instances will not help once the database is at full CPU.
Check your licence covers the row count. The record cap is evaluated when a bulk request begins. Trial mode stops at 1,000 records; see licensing and limits.