Migration Is a Discipline, Not a Data Transfer

Agencies rarely fear new software. They fear losing twenty years of operational history, or discovering after cutover that a report the county has relied on for a decade can no longer be produced.

That fear is rational. Migration failures are usually not transfer failures; they are meaning failures. The rows arrive and the context does not.

Where meaning gets lost

Legacy systems accumulate local conventions: a status code repurposed years ago, a free-text field carrying structured information, a workaround that became standard practice. None of that is documented, and all of it matters.

Discovery has to surface those conventions before mapping begins. The people who know them are usually records staff and long-tenured supervisors, not IT.

Validation before confidence

We sequence migration as discovery, assessment, mapping, validation, testing, migration, and verification. The validation and verification steps exist because a migration that looks complete in aggregate can be wrong in the specific cases an agency cares about most.

Verification should include the agency's own queries — the reports leadership actually runs — not only record counts.

Honesty about data quality

Migration frequently reveals data quality problems that existed for years. The right response is to document them and decide deliberately what to correct, what to carry forward as-is, and what to annotate.

Agency history matters. The goal is continuity of institutional knowledge, not a clean-looking database that no longer reflects what happened.