Home services and trades
Archive or migrate old job history when switching FSM software?
By SourceX Editorial · Updated
Short answer
Migrate the old job history your team will act on inside the new FSM software, and archive everything else read-only with the original IDs intact. In practice that means active customers, locations, equipment, open work and live agreements move; closed jobs, paid invoices, expired estimates and technician notes go into a linked archive your company controls.
Key takeaways
- Migrate records someone will act on in the new system; archive records people will only look up.
- Apply the rule one record family at a time, not as a single yes-or-no for the whole database.
- A read-only archive is only useful if it keeps the IDs that join jobs, estimates, invoices and equipment.
- The archive, not the migrated subset, is where the history's research and licensing value sits.
The decision rule in one sentence#
The decision rule for old job history is to migrate what is operational, archive what is historical, and never let the archive lose its links. Operational means a dispatcher, technician or billing clerk will act on the record after go-live. Historical means someone might need to look it up.
Run the rule record family by record family. Customers and equipment almost always pass the operational test; a closed drain job from years ago almost never does. The questions below settle the cases in between.
| Test question | If yes | If no |
|---|---|---|
| Will dispatch, a technician or billing act on this record after go-live? | Migrate it | Archive it |
| Does an active warranty, membership or service agreement depend on it? | Migrate the active terms plus a short prior-visit summary | Archive it |
| Is it a closed job, paid invoice or expired estimate? | Archive it with search access | Check whether it is really still open |
| Would importing it mean reshaping notes, options or attachments? | Archive it in its original form | Migrate it if the field team needs it |
| Is it a duplicate, test or junk record? | Keep it in the full backup only and flag it | Treat it like any other record |
How far back should you migrate?#
How far back to migrate depends on how your team uses history in the field, not on a fixed number of years. HVAC and commercial mechanical teams often want installed equipment and a short service summary per unit in the new system, because technicians diagnose against prior repairs. Trades built on one-time jobs, such as drain cleaning or restoration, rarely need closed jobs migrated at all.
Obligations also set a floor. Active equipment warranties, workmanship guarantees, membership visit counts and open financing all depend on past facts, so migrate those facts as fields (install date, warranty term, last visit, visits remaining) and leave the full job records in the archive.
- Technicians routinely check prior repairs on the same unit before quoting.
- Memberships carry visit counts or price commitments that depend on past visits.
- You file warranty claims with manufacturers and need claim history inside the system.
- Reports in the new platform need prior-year baselines you cannot rebuild elsewhere.
What a read-only archive must contain#
A read-only archive must contain enough to rebuild any job's story without the old software: structured exports, original attachments and a map of how they join. Without join keys, an archive turns into a pile of spreadsheets that nobody trusts and nobody opens.
Store two copies in company-controlled storage, limit access to named roles, and write down how long the archive is kept and who approves its destruction.
- The vendor's full native backup or database export, if one is offered.
- One structured export per record family, with the old internal IDs as columns.
- Photos, signed forms and PDFs filed under the job or invoice they belong to.
- A crosswalk linking each old customer and site ID to its record in the new system.
- A data dictionary listing each file, its columns, its ID fields and known gaps.
- Call logs, recordings and text threads if they sit outside the FSM platform.
Which archive format holds up over time?#
The archive format that holds up best is a combination: a native backup for completeness and flat exports with IDs for everyday use. Each form fails in a different way on its own, so relying on one creates a gap that usually shows up years later, during a warranty dispute or a sale of the company.
If you have the skills in-house, loading the flat exports into a simple database makes the archive searchable by address, unit or job type. If you do not, a well-named folder structure and a data dictionary go a long way.
| Archive form | Strength | Weakness |
|---|---|---|
| Vendor native backup or database copy | Most complete; keeps internal structure | May need the old software or a technical person to read |
| Flat exports (CSV or spreadsheet) with IDs | Readable anywhere; easy to search and join | Only as complete as the reports you ran |
| PDF reports and invoice copies | Easy for office staff to read | Hard to search at scale; links between records are lost |
| Continued read-only access to the old system | Familiar screens for staff | Depends on vendor terms and an ongoing fee; ends when the account closes |
| Exports loaded into a database or data warehouse | Searchable, joinable and durable | Needs setup and someone to maintain it |
Illustrative: an HVAC and electrical company decides#
Illustrative: a fictional residential HVAC and electrical company is moving from an on-premise system to a cloud FSM platform. The owner first wants every closed job imported. A test import of a sample month shows technician notes cut short, estimate options missing and equipment links replaced by text.
The COO applies the rule instead. Active memberships, equipment with a last-service summary, open estimates and open balances migrate. Everything else goes into an archive of flat exports with original IDs, a native backup and a photo library organized by job number. Customer service staff answer old-visit questions from a lookup sheet. When the company later discusses licensing, the reviewer works from the archive, because it still links calls, estimates, jobs and callbacks.
Mistakes that quietly ruin the archive#
The mistakes that ruin an archive are usually small decisions made in the last days before cutover. Each one looks harmless at the time and only shows up when someone needs to answer a warranty claim, a customer dispute or a buyer's diligence question.
Most of them are avoided by treating the archive as a deliverable with an owner and a checklist, not as a side task for whoever has time.
- Exporting reports without ID columns, so jobs cannot be joined to invoices or equipment.
- Saving exports to a departing employee's laptop or personal cloud account.
- Skipping attachments because the vendor's export left them out.
- Deleting the old account before anyone has traced a sample of jobs end to end.
- Keeping only PDFs because they are easy to read today.
Why the archive deserves care after go-live#
The archive deserves care after go-live because it is often the only complete record of how your company actually works: the requests customers made, the conditions technicians found, the work that was sold and the jobs that came back. Those linked sequences are what AI developers building dispatch, diagnostic and estimating tools look for, and a migrated subset rarely contains them.
When a company asks whether an archive could be licensed, SourceX begins with metadata only: systems, years, record families and how they link. The SourceX Enterprise Data Value Framework then rates drivers such as recency, data cleanliness, scale and rights, with preparation cost and privacy burden counted against net value. If a package proceeds, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Can we migrate history later if we archive it now?
Yes, if the archive kept original IDs and complete exports. A later import can draw from the archive instead of the retired system. Without IDs, any later import means matching records by name and address, which is slow and error-prone.
Who should own the archive internally?
Name one owner, often the COO or controller, who approves access, keeps the data dictionary current and applies the retention schedule. IT can maintain the storage, but someone in operations should decide what the archive is for and who may use it.
Do we need the old vendor's help to build the archive?
Usually, for the most complete copy. Ask in writing for a full export or backup and a description of what it includes, and check your contract's data return terms. Your own report exports fill gaps, but some fields and attachments may only come out through the vendor.
Is a read-only archive enough for warranty claims?
Often, yes, as long as warranty-relevant facts are also migrated as fields on the equipment record. The new system shows the warranty is active, and the archive backs up the claim with the original job notes, photos and invoice.
Should duplicate and test records go into the archive?
Keep them in the full backup so the copy matches the source system, but flag them in the flat exports so nobody counts or migrates them by mistake. Cleaning duplicates before any import keeps the new system from inheriting old clutter.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.