Field service data migration starts with record decisions, not file movement.

The short answer

Import trusted master data and preserve historical evidence without pretending the two are the same.

• Separate customer, site and asset master data from work orders, service reports and other historical events.
• Map stable source identifiers before cleaning names or combining duplicate rows.
• Keep a source archive and reconciliation record even when a row is not imported.

Give every source record one destination decision.

The map prevents a broad “migrate everything” instruction from turning uncertain history into working data. Apply the same five decisions to each source class.

• Inventory: Name the source and record class. List each spreadsheet, export, folder and system owner. Separate customer, site and asset data from work orders, reports, photos and commercial records. Working output: A source register with owners and record classes.
• Disposition: Choose import, retain, reference or exclude. Decide whether each class becomes working data, remains in the source archive, is linked as reference material or is excluded under an approved retention decision. Working output: One explicit destination decision per record class.
• Mapping: Preserve customer, site and asset relationships. Map stable source identifiers and parent relationships before normalizing names, addresses, locations, models and serial details. Working output: A hierarchy the import can validate.
• Sample validation: Test the difficult rows first. Use a representative customer with several sites, similar assets, missing fields and known duplicates. Correct the source or mapping before the wider import. Working output: A reviewed sample and documented correction rules.
• Reconciliation: Account for every accepted and rejected row. Compare the prepared file, validation result and imported records. Record rejected rows, duplicate decisions and the person responsible for correction. Working output: A signed reconciliation record and owned exception list.

A fictional asset register moves without inventing service history.

A service team has one maintained spreadsheet and a folder of older PDFs. The working directory and historical evidence receive different decisions.

• The data owner assigns stable source keys to the customer, each site and each asset before correcting display names.
• The team maps the linked rows into the standard CSV structure and runs the preview against the difficult sample.
• Duplicate equipment and missing site relationships are corrected in the source file, then the accepted rows are imported.
• The owner reconciles the imported customer, sites and assets while the old reports remain available under the documented archive process.
• Result: The new directory starts with reviewed equipment identities, while older evidence keeps its provenance and is not presented as structured service history.

Check the source before preparing the import.

Use this checklist before transforming the full dataset. A missing answer belongs in the decision log with an owner.

• Every source file, system and folder has a named business owner.
• Customer, site, asset, operational-history and commercial records are classified separately.
• Stable source keys preserve parent and duplicate decisions.
• Required customer, site and asset fields are mapped to the standard import structure.
• Similar equipment can be distinguished by site, location, model or serial details.
• A representative difficult sample passes preview and validation.
• Rejected rows and corrections have an owner before the wider import.
• The source archive, retention decision and reconciliation evidence are documented.

Treat master data and service history differently.

Customer, site and asset records describe the working service directory. A historical visit is evidence that work occurred at a particular time, under a particular source process. Importing the directory does not prove that older events have been reconstructed accurately. Start the connected service history with work completed and finalized in ilarvo. Bring older material into a new operational record only when its source, asset relationship and meaning can be reviewed explicitly.

Keep corrections visible after import.

Do not overwrite the only source file with cleaned import values. Preserve the received source, create a prepared version and retain the validation and reconciliation outputs. That chain explains why names changed, duplicates were merged or rows were excluded.

• Received source: unchanged evidence of what the team supplied.
• Prepared import: mapped and corrected customer, site and asset rows.
• Validation result: accepted rows and issues before import.
• Reconciliation record: imported totals, rejections and open corrections.