Records of Record, Migrated Without Losing a Row

Every federal modernization program eventually reaches the same cliff: the data has to move. Off a mainframe, off an Oracle Supercluster, out of a decades-old client-server application, and into something modern — without losing a single record of consequence. A benefits determination, a pharmacy order, an interment eligibility record: these are records of record, and "mostly migrated" is not a passing grade.

The uncomfortable truth is that migrations rarely go wrong because the target platform is bad. They go wrong because a migration is treated as a one-time data dump instead of an engineered, reversible, reconciled process. Our approach starts from a single principle.

1. Profile before you map

Most migration pain is data you did not know you had. Before writing a single mapping rule, catalog every source entity, field, and code set, and profile it for completeness, duplication, and referential integrity. You are looking for the landmines early: orphaned foreign keys, fields that hold three different formats, "temporary" codes that became permanent a decade ago. Profiling first turns nasty surprises at cutover into known, planned work.

2. Govern the mapping

A source-to-target crosswalk is not a spreadsheet someone keeps on a laptop — it is a versioned, traceable artifact. Every field mapping, every code-set reconciliation, every business rule is written down, reviewed, and tied back to an authoritative source. When an auditor or a program manager later asks "why is this value here," the answer is a document, not a memory.

3. Cut over reversibly, by domain

Big-bang migrations are attractive on a schedule and dangerous in practice. We migrate by bounded domain behind feature flags, so each wave is independently validated and independently reversible. If wave three surfaces a problem, waves one and two are untouched and wave three can roll back — no all-or-nothing gamble on a single weekend.

4. Reconcile — and fail closed

This is the step that separates a real migration from a hopeful one. Row-level checks and control-total reconciliation run automatically, and discrepancies block promotion rather than silently passing. Where the stakes justify it, source and target run in parallel (dual-run) so the new system is proven against the old under real load before anyone depends on it.

• Row counts and control totals must match, per domain, per wave.
• Referential integrity is re-verified in the target, not assumed from the source.
• Any unreconciled discrepancy halts promotion and raises an alert with evidence.

5. Cut over, hypercare, retire

Cutover is runbook-driven, with explicit rollback triggers defined in advance. A hypercare window follows, watching the new system under production conditions. Only after sign-off does the legacy platform get decommissioned — the old system of record is the safety net until the new one has earned the title.

What "done" means

Done is not "the new system is up." Done is: every record accounted for, every total reconciled, every mapping traceable, and a rollback path that existed until the moment it was no longer needed. That is the standard a program office can put its name behind — and defend to an Inspector General.