Marrinn Migrate.
Migration is where good projects go to die — a weekend cutover, a spreadsheet of mappings, and a Monday morning spent explaining which customers lost their history. Migrate replaces that with dry runs, reconciliation reports and an evidence trail. And it encrypts the data properly on the way in.
Five stages, and you can stop at any of them.
Nothing is irreversible until you say so. Every stage produces a report you can read, challenge and sign off before the next one runs.
The cutover you rehearse before you run.
Connect the legacy system, let the engine profile it, review the proposed mapping, run it against a copy, and only then move production.
- Profile — what is actually in the source, not what the schema claims
- Map — AI-proposed field mapping, reviewed and edited by you
- Transform — cleaning, deduplication, format and currency normalisation
- Dry run — full load into a staging target with a reconciliation report
- Cutover — the real move, reversible, with the clock running visibly
- ✓Profiled — 41 tables, 2.6M rowsok
- ✓Mapped — 318 fields, 6 needing reviewok
- ✓Transformed — 1,204 duplicates mergedok
- ✓Encrypted — 19 fields classified sensitiveok
- ✓Reconciling — row counts and checksums running
Dry run only — the production target has not been touched.
Built for the systems nobody wants to touch.
The 2004 Access database. The ERP with three custom modules and no documentation. The CRM whose vendor stopped answering the phone. Those are the interesting cases, and they are the ones Migrate is for.
Legacy and modern
SQL Server, Oracle, MySQL, Postgres, Access, CSV and Excel exports, and REST APIs.
Wherever you are going
A new database, a SaaS platform via its API, TagFlow, or a data warehouse.
AI-assisted, human-approved
The engine proposes the mapping from names, types and sampled values. You approve or correct it.
Cleaning & deduplication
Fuzzy matching, normalisation, and explicit rules for the records that need judgement.
Unlimited dry runs
Rehearse against staging as many times as you like. Production is untouched until cutover.
Reconciliation report
Row counts, checksums and per-table differences — signed off before anyone goes live.
Incremental sync
Keep the old system in step during a phased cutover, then switch off the tap.
Rollback plan
A tested way back, produced as part of the migration rather than improvised at 3am.
Migration is the one chance to fix the encryption.
Data is already being rewritten row by row. That is the moment to classify what is sensitive and encrypt it properly — rather than promising to do it in a later phase that never gets funded.
Classified on the way through, encrypted on the way in.
The engine reads the data, identifies what is personal or sensitive, and proposes an encryption policy per field. You sign it off; it applies during the load.
- Automatic classification — names, addresses, identifiers, payment and health data
- Field-level encryption so a database dump reveals nothing useful
- Managed keys — your KMS, your HSM, or keys you hold yourself
- Encrypted in transit and at rest, including staging and backups
- Deterministic options where a field still has to be searchable
- full_namePersonal · encrypt
- date_of_birthPersonal · encrypt
- national_insurance_noSensitive · encrypt
- card_last_fourFinancial · encrypt
- emailPersonal · deterministic
- created_atNot sensitive
Proposed by the engine · awaiting your approval before load.
The paperwork, produced as you go.
UK GDPR does not ask whether you meant well; it asks what you can evidence. Migrate produces that evidence as a by-product of doing the work properly.
Data inventory
A record of every field moved, its classification and where it ended up.
Encryption register
Which fields are encrypted, with which algorithm, under which key.
Full audit log
Every run, approval and change — who did it, when, and against which environment.
Data residency
Keep the whole pipeline in the region you choose, or inside your own network.
Retention & erasure
Records flagged for deletion are handled during migration, not carried forward.
Reconciliation evidence
The signed-off proof that what left the old system arrived in the new one.
Most migrations fail on the boring parts.
Not on the technology — on the assumptions nobody checked, and the reconciliation nobody had time to run.
The data is never what the schema says
Profiling reads the actual values first, so the surprises arrive during a dry run rather than during cutover.
Rehearsal is not optional
You run the cutover as many times as you need against staging, until the report comes back clean.
Someone has to sign it off
Every stage produces a readable report and asks for approval. Nothing proceeds on a shrug.
Tell us what you are migrating off.
Send us the shape of the source system and we will tell you honestly how hard it is going to be — including if it is not worth doing.