Moving data between systems cleanly is its own discipline. There is the one-off migration when you replatform or retire a legacy system, and there is the ongoing sync once two systems have to stay in step with each other. We do both, with the reconciliation and rollback planning that keeps a cutover from becoming an incident.

When you need a migration

  • Replatforming — moving from one ecommerce, ERP or CRM platform to another and bringing the history with you.
  • Consolidating several systems, or several instances of the same system, into one.
  • Post-acquisition, where two organisations’ data has to be merged onto a single platform.
  • Retiring a legacy or in-house system and lifting its data somewhere supported before it is switched off.

How a migration runs

  • Field-level mapping agreed in writing before any data moves, including how edge cases and legacy quirks are handled.
  • Extract and transform into the target’s format, with validation on every record.
  • Dry runs into a staging copy of the target system — usually several — so the real cutover is rehearsed, not attempted blind.
  • Reconciliation reports after each run: record counts, financial totals and sampled spot-checks, so you can sign off on the numbers rather than take it on trust.
  • A dated cutover plan with a defined freeze window, a go / no-go checklist and a rollback path.
  • Supported go-live and a short stabilisation period afterwards.

Ongoing sync

Where both systems stay in use after go-live, a migration becomes a sync. The hard part is not moving the data once — it is deciding what happens when the same record changes in two places.

  • One owning system per field, agreed in discovery and written down.
  • A conflict strategy per field group — owner wins, merge by field, or quarantine for a human to review.
  • An origin marker on every change so an update that came from System A is not bounced back to System A as if it were new.
  • Event-driven propagation — changes move within seconds, not on an overnight batch.
  • A transaction log so any single record can be traced from either side.

Data quality

Deduplication and normalisation run as records move, not as a separate clean-up project six months later. Bad addresses, inconsistent casing, duplicate customers and orphaned references are caught at the boundary.

What you get

  • The mapping document and the migration scripts.
  • Every reconciliation report, so the migration is auditable after the fact.
  • For a sync: the live integration, its field-ownership map and a runbook — handed over, yours to keep.

Talk to us about a migration

Tell us the source and target systems and roughly how much data is involved. We will come back with an approach, a fixed price and a cutover outline. Get in touch or call 01303 883111.