GET IN TOUCH

Send a message and I'll follow up over email.

Submitted details are used only to respond to your message. Nothing is shared, sold, or added to any marketing list.

← All artifacts
engineering

When a Migration Is Actually Done.md

Moving a decade of authoritative legislative records onto a new platform, and how you establish that a migration is complete rather than merely finished.

· 4 min read · By Abraham Nguyen

Data migration in government infrastructure demands replacing a foundation while people are still working inside the building. We handle authoritative records. A dropped row represents a permanent failure of public record, and deferred cleanup never survives contact with a system people rely on to do their jobs. The standard for success requires a decade of historical records to remain perfectly intact inside a database that models the world completely differently.

The architecture of consolidation

I recently led a migration of nearly 100,000 records across nine departments, moving them from a legacy framework into a modern, unified platform. Nine departments had spent years developing completely independent workflows, approval chains, and catalog structures. The mandate was to map all of that inherited complexity into a single shared core.

Getting the core architecture wrong means the old data cannot make the trip. Getting the mapping wrong means the new system grows a custom exception for every department, immediately rebuilding the exact silos the consolidation was built to eliminate. Designing the architecture and writing the migration are the exact same problem viewed from different angles.

Three gates of validation

A terminal output reporting “success” only confirms the script did not crash. To prove a migration is actually complete, you have to assume it failed and force the system to prove otherwise. We established completeness through three strict validation gates, each designed to catch a failure the previous gate was blind to.

EACH GATE CATCHES WHAT THE ONE BEFORE IT CANNOT SEESOURCE01 Row countsper entity, per department02 Field reconciliationsource contents vs destination03 Workflow validationowners run real proceduresCATCHESRecords dropped when adependency ran out of orderBLIND TOContents being wrongCATCHESA field emptied by atransform that did not matchBLIND TOBehaviour being wrongCATCHESCorrect data wired tothe wrong reviewerNO QUERY SEES THISA run reporting success has told you it hit no errors. It has not told you the data arrived.

Absolute row counts. This cheap check catches the loud failures, ensuring no records drop because a dependency ran in the wrong order.

Field-level reconciliation. A record can migrate with a critical field wiped blank by a mismatched transform while easily passing a simple row count. We compared the source and destination contents directly until every single discrepancy was explained.

Workflow validation. The teams who own the data exercised their daily procedures against the migrated content before we switched anything over. Values can map perfectly, but if an old approval routes to the wrong reviewer in the new system, the migration fails. This gate catches the organizational logic that no database query can ever see.

Managing the cutover

When it came time to launch, a single switch-flip would have made a rollback plan the only thing standing between us and nine simultaneous departmental crises. We staged the rollout department by department, running the old and new platforms in parallel. Staging turned one unmanageable risk into nine small, inspectable ones, allowing the new platform to earn the trust of the people relying on it.

ONE SWITCHall nine departments, one momentrollback is theonly safeguardSTAGED, WITH THE PLATFORMS RUNNING IN PARALLEL010203040506070809nine small risks,each inspectableEach department migrated, checked and accepted on its own before the next began.

Preserving institutional integrity

The most interesting engineering in a migration happens in the custom mapping logic. The work that actually determines success is the rigorous reconciliation nobody sees. Migrating legacy systems lacks the visibility of a new product launch, as the highest measure of success is a transition the users never notice.

I view this work the way structural engineers approach moving a historic building intact. You carefully lift the entire weight of the institution, preserve the exact integrity of the spaces where the real work happens, and lower it onto a modernized foundation. Modernizing government technology requires building an architecture resilient enough to carry that history forward.

Search my experience