Data migration

Migrations fail quietly

Rarely with an error. A field maps to the wrong place, a date format shifts by a month, duplicates multiply because the source had three records for one customer. Everything imports, the counts look plausible, and the problem surfaces six weeks later in an invoice or an audit.

The test run into a sandbox exists so that discovery happens before the switch rather than after it, and so that it is your team checking your own records rather than us checking ours.

• An audit of what is actually in the source, including the repurposed fields
• Field-by-field mapping, with a decision recorded where there is no match
• A full test migration you inspect before anything is committed
• Production run verified by count and by sample
• A rollback plan that exists before the switch, and the source archived

Personal data

Handled under a processing agreement, transferred encrypted, and the working copies deleted on completion. Where the source contains data you no longer have a basis to keep, the migration is the right moment to stop carrying it and we will flag it.

In the largest size both systems run in parallel for a period. That costs more and it is the only version where a serious problem is recoverable without a bad week.