Data migration, from first extract to signed-off cutover

• Rules that differ between the old system and the new one, found after go-live instead of before.
• Codes, flags and packed fields that nobody documented.
• Records the new system refuses: archived, oversized or outside its limits.
• A cutover window that was guessed rather than measured.
• Totals that don't match, found by finance a month later.

Each of these is cheap to find in a SQL warehouse before the load and expensive to find after it. That is where we start.

If there is an API, we use it. If there isn't, we read the database, parse the exports or, as a last resort, automate the screens. The route depends on what you can get at, and every route ends in the same place: tables we can query and count.

Compare the extraction routes

Two CRMs into one. An ERP and a CRM into a new platform. One system split across three. We map every source to the target model once, so each lands the same way and the reconciliation still adds up across all of them.

Profiling report

Row counts, keys, nulls, orphans and oddities for every source table.

Mapping specification

Field by field, with transformations, lookups and defaults, signed off by you before the build starts.

Migration code

Repeatable and documented, so every rehearsal and the final run do exactly the same thing.

Data quality report

Each issue found, its root cause, and how to stop it coming back in the new system.

Rehearsal reports

Timings and a full reconciliation for every dry run.

Cutover runbook

Every step with its owner and timing, the go or no-go criteria and the rollback path.

Sign-off sheet

Counts, totals and spot checks for every object, with anything held back listed and explained.

How the steps fit together

A fixed price once the scope is clear. Discovery and open-ended work on a day rate. There are no figures here because the access route and the state of the data change the effort too much to guess from a web page; a short description gets you a real answer.