Migrating Your Data Without Losing Your History

Why this matters

Your customer list, job history, and invoice record are the most valuable thing your shop owns that is not a truck. They are years of relationships and evidence you cannot rebuild. A data migration - moving that record from an old system, or from paper, into a new one - is the moment that asset is most at risk. Done carelessly, it orphans your history: customers land without their past jobs, invoices lose their links, notes vanish, and you discover it months later when you reach for a record that is not there. A good migration is boring and deliberate. This is how you keep it boring.

What migration means and what to move

Data migration is copying your records out of the old system and loading them into the new one, so the new tool starts with your real history instead of a blank slate. You are not moving everything. You are moving what you would grieve to lose.

  • Customers: names, addresses, contacts, phone and email, service and access notes.
  • Job and estimate history: what you did, what you quoted, when.
  • Invoices and payments: what was billed, what was paid, what is still owed.
  • Equipment records: the units under each customer, serials, service history.
  • Attachments: photos and documents tied to jobs.

Decide the cutoff early. Most shops move all open items and a few years of closed history, and leave the deep archive in the old system for reference rather than dragging every ancient record forward.

Know what moves cleanly and what does not

Not all data migrates equally, and knowing the difference sets your expectations.

  • Structured fields move cleanly. A name, an address, an amount, a date map field-to-field with little trouble.
  • Relationships are the fragile part. The link that says this invoice belongs to this job belongs to this customer. If the migration breaks those links you get orphans - an invoice with no customer, a photo with no job. Verifying links is the heart of a good migration.
  • Free-text notes and attachments are the most likely to be dropped or mangled. They rarely have a clean field to land in. Confirm they come across before you trust the move.

The sequence that de-risks it

Order is everything. Never do a one-shot dump and hope.

  1. Export a full copy from the old system and set it aside, untouched. This is your safety net and, if the old data lived only on paper or one machine, your first real backup. See related: Backing Up Your Business Data.
  2. Map the fields. Write down which old field lands in which new field. This is where you catch mismatches before they become damage.
  3. Import a small slice first - a few dozen customers with their jobs and invoices - not the whole database.
  4. Verify the slice by hand. Open those records in the new system. Do the jobs hang off the right customers? Did the invoices keep their amounts, dates, and links? Did the notes come through?
  5. Fix the mapping and re-run the slice until it comes across clean.
  6. Only then migrate the full set, and verify a fresh sample again.

The small-slice test is the single most important step. It turns a catastrophe you find in month three into a mapping fix you find in hour two.

The fields that always break

Watch these specifically, because they fail quietly.

  • Dates: formats differ between systems and can silently shift or blank out. Spot-check a range of them.
  • Phone numbers: different formatting can drop digits or split a field. Confirm they are dialable.
  • Duplicates: migration is when your duplicate customers surface. Clean them before the move if you can, because merging is harder after.
  • Special characters in names and notes: can turn into garbage on import. Scan a sample.
  • Amounts and balances: confirm open balances still total what the old system said. A mismatch here is money getting lost.

Keep the old system readable, do not just kill it

The day you go live is not the day to delete the old system. Keep it accessible in read-only form for a good while - a season at least - so you can settle any question the migration did not carry perfectly. Cheap insurance, and it lets you cut over with confidence instead of hoping you moved everything. Retire the old system only once you have run long enough on the new one to trust that nothing important was left behind.

The recap

  1. Move what you would grieve to lose; leave the deep archive behind.
  2. Export a full untouched copy first. That is your safety net.
  3. Map fields, import a small slice, verify by hand, fix, repeat, then do the full load.
  4. Watch dates, phones, duplicates, special characters, and balances.
  5. Keep the old system read-only until the new one has earned your trust.

The judgment to bank: a migration you verify in slices is boring, and boring is exactly what you want when your entire history is in motion.

References

  • U.S. Small Business Administration (SBA), managing business records and data
  • Cybersecurity and Infrastructure Security Agency (CISA), data backup guidance
  • See related: Backing Up Your Business Data; Move Off Paper to Field-Service Software or Not