Skip to content

Solutions

Data migration

Moving your data, with the evidence to prove it arrived.

The problem

Why this is harder than it looks

Migration is the line most often underestimated in a platform project, and the one clients ask about least during procurement. The data is never as clean as the people responsible for it believe. Every legacy system has a field that means three different things depending on who filled it in, and finding those is the work.

Method

How we run it

  1. Source profiling

    We read the actual data, not the schema documentation. Row counts, distinct values, nulls, orphans, duplicates, and the fields whose meaning has drifted. You get a profiling report before any mapping is designed.

  2. Mapping design

    Field by field, with the transformation rules written down and signed off by someone who understands the business meaning — not just the data type.

  3. Repeatable build

    The migration is code and can be re-run from scratch. A one-shot script that cannot be repeated is not a migration, it is a hostage situation on cutover weekend.

  4. Dry runs at production volume

    At least two, against a full-size copy. This is how you find the load that takes eleven hours instead of ninety minutes, while there is still time to do something about it.

  5. Reconciliation and cutover

    Control totals, record counts and financial balances compared source to target, reported at every run. Then a cutover plan with a defined rollback point.

What you get

  • Source profiling report, including the data quality problems we found
  • Signed-off field mapping with transformation rules
  • Re-runnable migration code, handed over with the rest
  • Dry-run results at production volume, with timings
  • Reconciliation reports: control totals, counts and balances, source against target
  • Cutover runbook with a rollback position and a decision point

What is out of scope

Stated here rather than discovered in month three.

  • Correcting your legacy data. We find and quantify the problems; the corrections need people with the business knowledge to make them
  • Migrating data you cannot give us access to, or that exists only in a format nobody can read
  • Guaranteeing that a source system’s totals are correct. We guarantee the target matches the source — if the source is wrong, the target will faithfully reproduce it, and the reconciliation report will show you
  • Ongoing synchronisation between old and new systems. That is an integration project, and a different one

What it costs

Estimated separately from deployment and priced on the profiling report. Anyone quoting a migration before profiling the source is guessing.

See the rates

Questions

Things people ask

How much history should we bring across?

Less than you think. Open balances and master data are almost always necessary. Full transaction history usually is not, and it is the most expensive part. A common answer is two to three years in the new system and the legacy database kept read-only for anything older.

What if the reconciliation does not balance?

We do not go live. That is the point of running it before cutover. In practice a first dry run almost never balances, and the difference is the most useful thing the project produces — it is usually a data quality problem that predates us by years.

Can you migrate from a system with no export?

Usually. Direct database read, API extraction, or worst case screen-scraping a report. What we cannot do is extract from a system whose vendor will not give you access to your own data, and that is a commercial problem rather than a technical one.

Who owns the migration code afterwards?

You do, along with everything else we write for you. It is in your repository from the first commit.

Talk to someone who will tell you if it is a bad fit

A scoping conversation, not a sales call. We will tell you what the platform does today, what it would cost, and where the risk sits.