System Migration and Cutover
Move customer and order history from a legacy system into a new one in validated batches, keep both aligned during the transition, and cut over with counts that match.
The problem
A migration is a one-time bulk move followed by weeks of both systems being live at once. The bulk move fails halfway and nobody knows which records made it. Then changes keep landing in the old system after the first pass, and the cutover happens on hope.
How it runs on Neblex
The first pass is a bulk flow: read the legacy records, map them to the new model with field mapping and lookups against reference Data Tables, remove duplicates on the natural key, validate every record, and write in checkpointed chunks. Rejected rows go to a branch that writes them to a Data Table with the reason, so the team fixes data rather than reruns the whole job.
While both systems are live, a Poll for changes flow keeps them aligned: a cursor or snapshot comparison picks up inserts, updates, and deletes in the legacy system and applies them to the new one. A Merge by key step resolves a record that changed in both places, later fields winning, and a branch can hand a genuine conflict to a person as a task.
At cutover, a summary flow compares record counts and checksums on both sides and publishes the result. Every run is in the history with its inputs and outputs, so an auditor can trace any record from the old system to the new one.
Step by step
Map the model
Field mapping and Data Table lookups translate legacy codes and picklists into the new system's values.
Bulk load in chunks
The initial pass runs in checkpointed chunks with duplicates removed and quality assertions before every write.
Quarantine the rejects
Rows that fail validation are routed onward with the reason and written to a Data Table for cleanup.
Keep both sides aligned
A change-detection flow applies ongoing inserts, updates, and deletes until the old system is switched off.
Cut over with evidence
A reconciliation flow compares counts and checksums and publishes the report before the switch.
Platform capabilities used
- Field mapping with Data Table lookups
- Chunked processing with checkpoints
- Remove duplicates
- Assert Data Quality
- Poll for changes with delete detection
- Merge by key
- Wait for form for conflicts
- Replay from the failed step
Common questions
How do we know nothing was lost?
Every chunk is checkpointed and every run is kept with its inputs and outputs. The cutover flow compares counts and checksums on both sides, and any record can be traced through the run history.
What if a record changed in both systems?
A Merge by key step combines the two versions field by field with later fields winning, or a branch routes the conflict to a person as a task in the inbox before anything is written.
Can we rehearse the migration?
Yes. Run the same flow against a sandbox of the new system first. Flows promote between environments, so the rehearsed flow is the one that runs on the day.
Related use cases
Data Warehouse Loading
Load Salesforce and Postgres data into Snowflake on a nightly schedule in checkpointed chunks, with duplicates removed and quality checks applied before…
IT & DevOpsOnboarding and Offboarding Automation
Turn Workday status changes into same-day provisioning in Okta and Google Admin, and revoke access the moment someone leaves.
FinanceOrder-to-Cash
Sync Salesforce orders into NetSuite for fulfillment, invoicing, and revenue recognition, with order and payment status flowing back to the CRM.
Want this running on your stack?
Neblex Integration Fabric is generally available: every core feature on every plan. Bring this workflow and we will map it to your systems.