Systems integration
Data migration that keeps the history, not just the records
Moving data between systems is where most replacement projects go wrong. Done properly it is rehearsed, reconciled and reversible — not a weekend and a held breath.
The situation
The riskiest part of replacing a system
Migration is usually scheduled last, estimated optimistically and rehearsed once. That is why it is the stage that most often forces a go-live to be abandoned.
- Duplicate records nobody has agreed how to merge
- Historical data in a format the new system has no field for
- Free-text fields holding information that should be structured
- No agreement on what counts as a successful migration
- A cutover plan with no tested way back
- A legacy system nobody wants to keep, but nobody dares switch off
What it covers
What a migration covers
Profiling
Understanding what the data actually contains, as opposed to what the schema claims, which is where the surprises live.
Cleansing and de-duplication
Duplicates, gaps and contradictions surfaced for a decision rather than silently carried into the new system.
Mapping
Field-by-field mapping including the awkward cases — data with no home in the new model, and fields repurposed years ago.
Rehearsal runs
Full migrations into a test environment, repeatedly, until the run is boring and its timings are known.
Reconciliation
Evidence that what arrived matches what left, by count and by value, rather than a spot check and an assumption.
Cutover and rollback
A sequenced plan for the switch, and a tested way back if the criteria are not met on the day.
How we work
How a migration runs
The principle is simple: by the time you do it for real, you should have done it several times already.
Profile and agree
Establish what the data holds and agree what a successful migration means, in numbers, before anything moves.
Map and cleanse
Build the mapping, resolve the duplicates and decide what happens to data with nowhere to go.
Rehearse
Run the full migration into test, reconcile, fix, repeat. Each run should be less eventful than the last.
Cut over
Execute against the plan, reconcile against the agreed criteria, and keep the rollback available until they are met.
Outcomes
What you are left with
- History preserved, not just current records
- Duplicates resolved by decision rather than by accident
- Reconciliation evidence that the migration was complete
- A cutover that has been rehearsed rather than attempted
- A tested rollback, available until the criteria are met
- A legacy system that can actually be switched off
Platforms and tooling
What we work with
Sources
- SQL Server
- Oracle
- MySQL
- Access
- Excel
- Legacy and mainframe extracts
Targets
- Salesforce
- Dynamics
- Blackbaud
- SAP
- PostgreSQL
- Cloud data platforms
Tooling
- ETL pipelines
- Azure Data Factory
- SSIS
- Custom transformation
Named as platforms we work with, not as formal partnerships.
Common questions
Questions we are usually asked
Longer than most plans allow, because the effort is in profiling and cleansing rather than in the transfer itself. The move might run in hours; agreeing what to do with twenty years of inconsistent records is what takes the time.
It gets a decision rather than a default. Options are usually an extension field, an archive that remains searchable, or an accepted loss — but it should be a choice someone made knowingly, not something discovered afterwards.
You can, but it is worth costing honestly. Licences, hosting and the security patching of a system nobody maintains often exceed the cost of migrating the history properly in the first place.
By agreeing the criteria in advance and reconciling against them — record counts, financial totals, and sampled checks on the awkward cases. Without criteria set beforehand, sign-off becomes a matter of nerve rather than evidence.
Sometimes, using parallel running and a synchronised switch, though it costs more and adds complexity. For many organisations a planned weekend outage is the cheaper and safer answer, and we will say which we think applies.
You roll back, which is only possible if the rollback has been tested rather than merely written down. That is why rehearsal runs include rehearsing the way back.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Legacy modernisationFor the system nobody wants to touch but everything depends on.
- Systems integrationMaking the systems you already own talk to each other.
- Bespoke databasesFor the operational data that has ended up in a spreadsheet.
- Cloud servicesMoving to cloud, or making an existing cloud estate behave.
- Mainframe modernisationMoving off hardware and languages that are getting hard to staff.
- Bespoke CRM systemsA customer database built to your process, with no per-user licence.