Switching field service software: moving your job records

What has to move

Switching field service software means exporting customers, jobs, certificates and invoices, then importing them without losing history. The record set that has to move therefore covers more than current contact details. Customer records support site and contact information, while job records carry service history and operational context. Certificates and invoices must remain findable after the move, because they evidence work and support financial and compliance checks. Under UK GDPR, individuals' data requests must generally be answered within one month, so a business needs records it can still find and export after the move. That requirement makes exportability part of the migration scope, not an afterthought. Personal data held in customer, job and invoice records must be locatable and retrievable in a form that supports a response within the legal period. The migration plan therefore needs to identify where each record type is held, how it links to other records, and how it can be exported from the new system once the old contract ends. Record ownership and access permissions form part of the same export specification, because a record that cannot be accessed cannot be produced.

Export formats vary: CSV, PDF and API. Each format carries different limits for preserving links between records. CSV can support structured data fields; PDF can preserve the visual form of certificates and invoices; API access can support transfer between systems where it is provided. The migration plan needs to check which format applies to each record type and whether the export includes the history attached to the current record. Gas safety records must be kept for 2 years; F-gas records for 5 years. Those retention periods travel with the record, so the new system must hold the record for the required period and keep it retrievable. Certificates that exist only as PDFs need a consistent naming and indexing method so that they remain findable alongside the job record. Invoices need links to the customer and job so that financial history remains usable. The table of record types, formats and retention periods is the working reference for the export and import steps. It identifies what is being moved, where it sits in the old system and what evidence of the move is retained.

Planning the timeline

Planning the timeline starts with the notice periods on the old contract. Those periods set the switching timeline, because the old system must remain available long enough for the export to be completed and checked before access ends. The migration plan works back from the contract end date. It identifies the date for the first export, the date for a test import, and the date for the final export. The plan also sets aside time for checking whether customers, jobs, certificates and invoices have arrived with their history intact. Under UK GDPR, individuals' data requests must generally be answered within one month, so the old and new systems must support a response throughout the transition. A request can arrive at any point, including during parallel running. The plan therefore records where personal data sits at each stage and which system can produce it. The notice period is not only a commercial date; it is the outer boundary for the migration work. The timeline also records the point at which the old system becomes read only, if that point is set.

Parallel running reduces risk during cutover. In that period, the old and new systems both hold the records needed to keep work visible while the import is checked. The plan sets a defined period for parallel running and states which system is authoritative for each record type. It also sets the checks that end the period. A job record can be compared across both systems; a certificate can be checked for retrievability; an invoice can be checked for its link to the customer and job. Gas safety records must be kept for 2 years; F-gas records for 5 years. The plan confirms that the new system holds those records for the required period and that the old system does not remove access before the migration is complete. Export formats vary: CSV, PDF and API. The final export step matches each format to the record type and records the evidence that the import succeeded. The timeline closes with a record of the cutover date, the parallel running period and the retention checks. It also names the person or role responsible for each check. The record of the move supports later data requests.

Avoiding double entry during cutover

Cutover creates a period when the old and new field service systems may both hold live work. Double entry arises when a job, certificate or invoice is entered in both systems, or when an accounting sync posts the same transaction twice. A controlled migration defines one system of record for each record type at each stage and records the point at which the old system becomes read only. The integration order follows the dependency between records: customer records first, then jobs, then certificates, then invoices. That order allows each new record to reference an existing customer and job, and it keeps certificate history linked to the correct site. Accounting sync follows the invoice export, with reconciliation against the old ledger before the new system starts posting. Where both systems remain active for a period, parallel running reduces risk during cutover because staff can compare outputs and resolve mismatches before the old contract ends. The old contract notice period sets the switching timeline, so the cutover plan works back from that date. Export formats vary, including CSV, PDF and API, and the chosen format affects how far automation can prevent duplicate entry.

Double entry also occurs when accounting and job records diverge. The invoice export is the bridge between the field service system and the accounting system, so the migration sequence keeps invoice numbers, customer references and job references aligned. A reconciliation point before and after the accounting sync shows whether every exported invoice has a matching entry and whether any manual adjustments exist in the old system. Certificates require separate handling because gas safety records must be kept for two years and F-gas records for five years. That retention period means certificate metadata and the associated PDFs remain available after the old system is closed. Under UK GDPR, individuals' data requests must generally be answered within one month, so a business needs records it can still find and export after the move. A searchable export of customer and job data supports that obligation. Parallel running reduces risk during cutover by allowing a controlled comparison of old and new records. The cutover plan can allocate a fixed period for parallel operation, with duplicate checks on jobs, certificates and invoices before the old system becomes read only. The aim is a single posting for each transaction and a complete, exportable history.

Switching checklist

A switching checklist walks through the move in a fixed order. It starts with the old contract notice period, because that period sets the switching timeline and the date by which the old system becomes read only. The next item is a data inventory covering customers, jobs, certificates and invoices, with the location of each record and the export format available. Export formats vary, including CSV, PDF and API, so the checklist records how each format will be imported and whether history remains linked. Certificate retention is part of the inventory: gas safety records must be kept for two years and F-gas records for five years. The checklist also records the retention location after the old system closes. Under UK GDPR, individuals' data requests must generally be answered within one month, so the inventory includes a search and export route for customer and job data after the move. The contract notice period and the data inventory together define the cutover window. The checklist then covers the import sequence: customer records, jobs, certificates and invoices. Each stage has a validation point to confirm record counts, references and attachments. Parallel running reduces risk during cutover, so the checklist can include a period when old and new systems are compared before the old system is closed.

The checklist continues with accounting sync and close down of the old system. Invoice export is matched to the accounting ledger, with a reconciliation before and after the sync. The checklist records the invoice reference, the customer reference and the job reference used in both systems, so a duplicate posting is visible. It records any manual adjustments held in the old system. After the accounting sync, the checklist covers certificate files and metadata, because those records carry the retention periods of two years for gas safety and five years for F-gas. The checklist records where those certificates are stored and how they can be found and exported. Under UK GDPR, a subject access request must generally be answered within one month, so the post move system needs a search and export function for individuals' data. The final items are parallel running and cutover sign off. Parallel running reduces risk during cutover by allowing old and new outputs to be compared. The checklist records the comparison points for jobs, certificates and invoices, and the date when the old system becomes read only. Export formats vary, including CSV, PDF and API, so the checklist records the import method for each format. The list gives a record of the move.

Data protection during migration

Switching field service software means exporting customers, jobs, certificates and invoices, then importing them without losing history. The migration is a data protection event as well as an operational one. Under UK GDPR, individuals' data requests must generally be answered within one month, so a business needs records it can still find and export after the move. That requirement applies to personal data held in the old field service system and in any interim export files. A subject access request can arrive before, during or after cutover, and the one month period under ICO guidance does not pause because a migration is in progress. The business therefore needs a clear record of what data exists, where it is held, which export contains it and how it can be retrieved. Export formats vary: CSV, PDF and API. Each format has different search and extraction limits, so the migration plan needs to identify how personal data will be located in each one. Access rights, deletion rights and correction requests also depend on records remaining identifiable after import. The migration plan also needs a retrieval route for each export type.

The old supplier acts as a processor for data held in its system, and the contract terms govern return and deletion. The migration plan needs to set out when the old system stops being the live record, when data is exported, how the export is checked and when deletion from the old system is confirmed. Deletion needs to cover live data, backups where applicable and any copies held for migration testing. The business remains responsible for answering subject access requests within one month and for keeping the evidence needed to show compliance. A parallel running period reduces risk during cutover because the old and new systems can be checked against each other while the migration is still reversible. The notice period on the old contract sets the switching timeline, so data extraction, validation, import and deletion need to fit inside that window. The processor agreement needs to cover the return format, deletion confirmation and support for access requests during the transition. Without those controls, a business can lose the ability to locate or export records that it is still required to provide.

Records that outlast the contract

Some field service records have retention periods that continue after a contract ends. Gas safety records must be kept for 2 years, and F-gas records must be kept for 5 years. Those periods mean that a migration cannot treat every record as disposable at cutover. The new system needs to hold the retained records in a form that can be found, read and exported. A retention chart helps map each record type to its period and to the system that holds it. The chart also needs to show whether the record is a live job record, a certificate, an invoice or an archive item. Where the old supplier holds the record, the exit plan needs to secure an export that preserves the retention period. Where the new system holds the record, the import needs to preserve dates, identifiers and links to the customer and job. The retention period is not reset by the software move. A record that is two years old under a gas safety rule remains subject to that rule after import. The chart needs a review date and an owner.

Archiving is part of the migration, not an afterthought. Records that are no longer needed for live operations but still fall within a retention period need a controlled archive with access controls, search and export. The archive needs to be included in the data map used for subject access requests, because a request can cover records held in an archive as well as in the live system. Export formats vary: CSV, PDF and API. An archive that exists only as a PDF image may not support searching or extraction, while a CSV or API export may preserve structured fields. The migration plan needs to test retrieval from the archive before the old contract ends. It also needs to record deletion of records that are outside their retention period and no longer needed. Parallel running reduces risk during cutover by allowing the retained records to be checked in both systems. The notice period on the old contract sets the switching timeline, so archive creation and retrieval testing need to be scheduled within that period. A record of archive contents supports later audits and access requests.

After the switch

After the switch, the return visit test provides a practical check that migrated customer records remain usable in day to day work. The test involves selecting a customer whose history was exported from the old system and imported into the new one, then locating that customer, reviewing past jobs, certificates and invoices, and recording a new return visit against the same record. This confirms that the link between the customer, the property, earlier work and the new appointment has survived the move. It also shows whether staff can find the information without access to the old platform, and whether notes, attachments and dates appear in the right fields. The test can be repeated across a small sample of customer types, including those with gas safety records and F gas records, because retention periods differ. Gas safety records must be kept for two years and F gas records for five years. A record that cannot be retrieved after cutover creates a compliance and service risk. A link to the how to choose guide accompanies this article for businesses reviewing requirements before or after a move.

Parallel running reduces risk during cutover because the old and new systems are used alongside each other for a period. During that time, a migrated customer can be checked in both systems, and any gap in job history, certificates or invoices can be identified and corrected before the old contract ends. Notice periods on the old contract set the switching timeline, so the period available for parallel running depends on the notice date and the supplier's exit process. Export formats vary and may include CSV, PDF and API access. A business needs to confirm which format supports the records it holds, particularly where certificates are stored as documents and invoice details are stored as structured data. Under UK GDPR, individuals' data requests must generally be answered within one month, so a business needs records it can still find and export after the move. The return visit test supports that requirement by showing whether a customer record and its history can be retrieved, reviewed and updated in the new system. The test also gives a documented example of a completed job in the new platform.

Frequently asked questions

How long does it take to switch field service software?

Often several weeks, depending on data volume, cleaning and notice periods.

What data should be exported?

Customers, sites, assets, jobs, certificates, invoices and notes.

How quickly must a business answer a subject access request?

Generally within one month under UK GDPR.

Do old certificates need to be kept after switching?

Yes, retention rules such as 2 years for landlord gas records still apply.

Can job history be imported?

Often partly; many systems import customers easily but job history and documents may need PDF archiving.