Data Migration Toolkit
The problem it solves
Migrations fail in the record-keeping long before they fail in the data. Two spreadsheets disagree about a cutover date. A gate is signed against a plan that changed last week. Nobody can say which version of the field map was used.
Every sheet here is generated by the Python in the repository. The plan and the gate sheet come from the same source, so they cannot disagree. That constraint is the point of the build, not a convenience.
The seven artefacts
| Artefact | What it proves |
|---|---|
| Action log | What was done, when, and by whom |
| Change requests | What changed after sign-off, and what it cost |
| Field map | Where every source field ended up |
| Exception sheet | What did not migrate cleanly, and the decision made |
| Reconciliation | That the counts and totals match on both sides |
| Linkage check | That relationships survived the move |
| Gate sign-off | Who approved each stage, and against what |
The worked example
The repository ships two workbooks. One is blank, with a single example row per tab. The other is a full engagement caught mid-cutover: six gates signed, go-live pending, and four change requests logged with what each one did to the date.
A blank template shows what the columns are. A filled one shows what the work looks like when it is going wrong, which is the part worth seeing.
Why it is built this way
Excel, deliberately. The people who sign these gates use Excel. A tool they cannot open is a tool they will not use, whatever it does.
Generated, not hand-built. Anything typed twice will eventually differ. Generating both workbooks from one script makes agreement structural rather than something to remember.
Gates rather than a checklist. A checklist can be worked around. A gate with a name and a date on it cannot, and it is what an auditor asks for.