Business system data migration
When the data has to move, but the business cannot afford for it to mean something different afterwards.
I help businesses move operational data between systems with mapping, checks, reconciliation and enough judgement to protect the records people actually rely on.
Problem diagnosis
Migration breaks when records are treated as rows instead of decisions.
- The old and new systems use similar field names but different meanings.
- Customer, order, asset, invoice or stock data has edge cases that do not fit the target import.
- People need confidence that the migrated records reconcile, not just a success message from a tool.
A poor migration can create billing mistakes, missing history, duplicated records, operational delays and weeks of manual cleanup.
Responsibility
The migration plan should be readable by the people who own the business process.
I work from the business meaning of the records, then build the mapping, checks and exception handling around that. The output is not just moved data; it is moved data people can trust.
What I would build
The first useful version would be concrete.
- 01
Source and target mapping
Fields, statuses, relationships and ownership rules are mapped before data is moved.
- 02
A test migration
A representative subset is moved first so odd records, missing fields and interpretation problems appear early.
- 03
Validation checks
Counts, totals, sample records and business-critical fields are checked against the source before sign-off.
- 04
Exception handling
Records that cannot be mapped cleanly are separated for review rather than silently forced into the new system.
- 05
Cutover notes
The final move has a clear sequence, rollback thinking and a record of what changed.
Fit filter
Probably right, probably not.
Probably right when…
- The data is operationally or commercially important.
- Several systems or teams disagree about what the records mean.
- You need mapping, checking and judgement, not just a file import.
Probably not me when…
- You need a simple export/import that the target product already handles well.
- The work is cloud-storage migration or phone/computer transfer.
- You want database administration with no business-process responsibility.
First step
Start with diagnosis, not a big commitment.
The first conversation is about what the records mean, what must reconcile, and what would count as a failed migration.
£150 per hour plus VAT where applicable. Two hours minimum for new clients. No retainer, no minimum term, no lock-in. You own everything I build.
Useful things to send before a call
- Sample exports from the source system
- Target import rules or documentation
- A list of fields that must be preserved
- Known awkward records and exception examples
Objections
Questions this page should answer before you email.
Can you migrate from old or awkward systems?
Often, yes, if the data can be exported or accessed. The first stage proves what is possible before the business depends on it.
Will all historic data move?
Not automatically. Some history is essential, some is archive-only, and some should not be imported into the new process.
Can this run alongside a wider software change?
Yes. Migration is often one part of a rebuild, modernisation or CRM/database project.
Next step
If this looks like your problem, send me the awkward bits.
The useful first email is short: what is breaking, what product or process cannot handle it, and what working would need to mean.