Moving acquired shops onto one FSM: what happens to legacy job history

Why does legacy job history get left behind?#

Legacy job history gets left behind because platform migrations are scoped to keep the business running, not to preserve the past. The project team's deadline is the first morning dispatchers book work in the new FSM, so the import plan centers on what that morning needs.

Closed history is also the hardest data to map. Every shop named its job types, cause codes and custom fields differently, and attachments are not always included in a standard bulk export. Forcing years of completed jobs into a new system's structure costs time and money, so many teams quietly leave it for later. Later often arrives after the old subscription has ended.

Migrate, archive or keep read-only: decide per record family#

The migrate, archive or read-only choice works best record family by record family, because each family serves a different purpose after cutover. Live operations need some records inside the new FSM; others only need to survive, intact and searchable, somewhere the platform controls.

Read-only access to the old system is a useful bridge when the vendor offers it, but it is not an archive. Plans change, vendors are acquired and read-only seats tend to be the first cost someone cuts.

An archive-before-cutover checklist#

An archive-before-cutover checklist turns the export into a deliverable with an owner and a sign-off, rather than a task someone attempts the week the contract ends. Run it for every shop in the same format, so archives from different systems can be read side by side.

Keep an export log alongside the files: who ran each export, from which account, on what date, with which filters and which files came out. The log is what lets someone trust the archive later, when the person who ran the export has moved on and a warranty claim or a diligence request asks whether the history is complete.

• 1Read the legacy vendor's terms on data export, account closure and how long data is kept after cancellation.
• 2Request every available export: customers, locations, equipment, jobs, notes, estimates, invoices, memberships, forms and attachments.
• 3Keep original record IDs and the fields that link one record to another.
• 4Count records by year in the source system and in the export, and resolve any gaps.
• 5Write a data dictionary for custom fields, job types, cause codes and tags.
• 6Have the shop's office manager open a sample of old jobs in the archive and confirm they read correctly.
• 7Store the archive in platform-controlled storage under the owning legal entity.
• 8Cancel the legacy subscription only after the records owner signs off.

How should a platform sequence several shops?#

A platform should sequence shops by deadline and risk, not by the order in which they were acquired. The legacy contract renewal date usually sets the real deadline, and the trade's busy season sets the window when no shop should be asked to change software.

Reuse what each migration teaches. The crosswalk built for the first shop's job types and cause codes becomes the starting point for the next, and the platform FSM should carry a shop or brand field on every new job so history stays attributable after the old systems are gone.

What a records-value lens adds to the migration plan#

A records-value lens adds one question to every migration decision: will this archive still show how each job unfolded? The value of job history, for warranty disputes, pricing analysis, technician training and possibly licensing, lies in the links between a call, the diagnosis, the estimate, the work, the invoice and any callback.

PDF job reports and spreadsheets of totals look complete but break those links. Structured exports with original IDs keep them, as do photos and forms tied to the job they came from. Technician free text matters too, because it records what was found and why a repair was chosen, which no line-item code captures.

Equipment records deserve particular care. Model and serial numbers, install dates and the history of repairs on each unit let the platform see which equipment fails, when and how it was fixed. That history usually spans several owners of the home and several technicians, and it is the first thing to break when a migration imports only active sites.

Illustrative: three shops, one field service platform#

Illustrative: a fictional roofing and restoration platform moves three acquired shops onto its chosen FSM. One shop ran Jobber, one ran FieldEdge, and the oldest ran a desktop job system on an office server, with photos in folders named by customer.

The FieldEdge shop goes first because its contract renews soonest. The Jobber shop follows after storm season. The desktop system needs a database export by an outside technician and a script to tie photo folders back to job numbers, so it goes last, with the server kept running until the archive is signed off.

Each shop's active customers, open estimates and service agreements move into the new FSM. Completed jobs, notes, photos and insurance claim files go into the platform's archive with a data dictionary per shop. A later review finds the desktop shop held the deepest record of storm-damage assessments in the group, history that would have been lost with the server.

How SourceX treats archived job history#

SourceX assesses archived job history the same way it assesses live operating records, under the SourceX five-step transaction. The first step is a fit check built on metadata such as source systems, years covered and record families. If a license proceeds, archives stay in the platform's own storage or ship on encrypted drives; SourceX does not host multi-terabyte datasets.

The SourceX Evidence Packet records provenance, including the source system and the migration that produced the archive, along with licensing rights, permitted use, the privacy record and release authorization, so the platform can show where each record came from.