Migrating data into or between ERPs is a high-stakes, mostly one-time job where mistakes are expensive and hard to unwind. n8n is a capable orchestrator for it, but a migration is not a normal workflow — it is a batch pipeline that must survive interruption, avoid duplicates, and prove it moved everything correctly. Design it for those properties from the start.
Extract, transform, load — in waves
Structure the migration as clear stages: extract from the source, transform to the target's shape, load into the ERP. Run it in waves rather than one monolithic pass — batch the records so you can validate a wave, catch problems early, and never have a single failure that requires restarting the entire migration. Small, verified batches beat one big irreversible run every time.
Idempotent and resumable
A migration will be interrupted — by an error, a rate limit, or a discovered data problem — and you must be able to re-run it without duplicating what already loaded. Track which records have been migrated (a status per source record) so a re-run skips completed ones and picks up where it stopped. Key loads on a stable source identifier so re-processing a record updates rather than duplicates. Assume you will run the migration many times before it is done.
extract batch (status = pending)
-> transform to target shape
-> validate (required fields, references resolve)
-> load into ERP (upsert on source id)
-> mark migrated + record target id
-> reconcile counts per wave
# a re-run only re-touches records still marked pending or failedValidate and reconcile
Validate before loading — check required fields are present and references resolve — so bad records are caught and quarantined instead of rejected mid-load or, worse, loaded wrong. After each wave and at the end, reconcile: compare source and target counts and spot-check values, so you can state with evidence that everything migrated correctly. "It ran without errors" is not the same as "every record arrived intact."
Never let production be the first time your migration runs end to end. Rehearse against a sandbox or a copy of the target, measure how long it takes, surface the data problems you did not anticipate, and refine. A migration you have run once against real-shaped data is a controlled operation; one you are running for the first time on go-live is a gamble.
Run an ERP migration through n8n as an idempotent, resumable, wave-based pipeline with validation before every load and reconciliation after every wave — and rehearse it against a copy before go-live. The goal is a migration you can start, stop, resume, and re-run safely, and finish able to prove that every record made it. Anything less on financial data is a risk you do not want to be explaining afterwards.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.