How hard is it to get our data out of an old system?
Extracting is usually the easy part. Reconciling is the work: duplicates, missing required fields, records whose shape does not exist in the new model, and history that is technically present but meaningless. The rule that saves projects is to migrate the spine — customers, locations, open work — and archive the rest as searchable read-only data rather than forcing it into a structure it never fit.
Check the exit before you check in
Export capability is worth evaluating when you buy software, not when you leave. Some platforms provide full API and database access; others provide reports designed for reading rather than for moving. The difference determines whether a future migration is a project or an ordeal.
If you are choosing a system now, ask what a complete export contains, in what format, including attachments and historical records. Ask whether it is self-service. A vague answer is itself an answer.
The problems are in the data, not the transfer
- Duplicates. The same customer entered three ways over eight years. Merging requires rules, and the rules require someone with authority to decide.
- Missing required fields. The new system insists on something the old one never captured. You either back-fill, relax the requirement, or flag the record.
- Shape mismatch. The old system modeled one customer per address; you now need customers with several properties. There is no mechanical translation for that.
- Free text carrying meaning. Years of notes where operational facts live in prose. Readable by people, invisible to reports.
- Attachments. Photos, signed forms and PDFs are often the largest and most-forgotten portion.
Migrate the spine, archive the rest
Not everything needs to become live data. The active spine — current customers, locations, equipment, open jobs, balances — has to be correct in the new system because people work from it daily. Ten years of closed jobs generally do not, and forcing them through a transformation adds enormous effort for records nobody edits.
The pragmatic pattern is a read-only archive: the historical data preserved and searchable, with a stated cutoff date visible in the new system so nobody wonders where it went. This keeps the migration bounded while preserving the ability to answer a question about 2019, and it is how we approach system transitions generally.
Reconcile before cutover, not after
Run the load into the new system and compare against the old one on measures that matter: customer count, open job count, outstanding balance total, revenue for a known month. Differences are normal. Unexplained differences are not, and they must be resolved before anyone starts working in the new system.
Keep the reconciliation report. Six months later, when a number looks wrong, it is the document that tells you whether the discrepancy came from the migration or from something new — the same reason revenue reporting should always be able to explain where a figure came from.
Topics: data migration · legacy systems · data quality · cutover
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.