Changing your job management system means making room for a project while the daily work continues. Engineers still need their schedules. Customers still expect updates and certificates. Invoices still need to go out on time.
This guide focuses on reducing disruption, not promising there will be none. It assumes you have already chosen your new software. The next task is to prepare the data, test the workflows and agree exactly where each job will be managed during the changeover.
Map the workflows your new system must support. Follow real jobs from booking to payment, including approvals and handovers.
Check your existing contract and data export options. Confirm notice periods, export contents and access before setting dates.
Decide what to migrate and clean your data. Separate live records from archives and preserve links between them.
Configure and test a complete job. Test the full workflow, including accounting and poor-connectivity conditions.
Run a controlled pilot with office and field staff. Use a defined group and resolve issues before wider rollout.
Train each role and set a clear changeover rule. Give staff practical training and establish which system owns each job.
Go live, reconcile records and review early results. Check transferred work, monitor exceptions and keep a documented fallback.
Before moving data, establish what the new system must support on day one. Follow a real job from the initial enquiry through booking, dispatch, site work, sign-off and invoicing.
Record the forms, photos, signatures and approvals involved. Pay particular attention to handovers between office staff, engineers and finance. Include the less straightforward work: return visits, variations, recurring maintenance and jobs requiring supervisor approval.
Separate essential requirements from improvements that can wait. Name the person who will check each requirement and describe what a successful test looks like. That gives you a basis for accepting the setup, rather than relying on a demonstration that does not reflect your work.
Read the old contract before committing to a changeover date. Confirm the notice period, renewal date, cancellation process and any charges for exports or continued access.
Ask the provider, in writing, what you can export and in which formats. Request a sample early. A customer spreadsheet does not prove that job histories, photos, certificates and relationships between records will also transfer.
Check whether the export includes:
Customer, site and asset references.
Open jobs, future appointments and recurring schedules.
Quotes, job costs and invoicing status.
Attachments, forms, certificates and relevant history.
Agree how personal data will be handled during the move, including secure transfer, access permissions and arrangements for return or deletion after the service ends. Confirm these arrangements against your contract and applicable data-protection obligations with the person responsible for data protection.
Set retention requirements by record type and jurisdiction. Do not apply one blanket period to every certificate or assume that changing software changes how long records must remain available. Confirm uncertain requirements with the relevant adviser or industry body.
Separate the records needed for daily operations from those that can remain in an accessible archive. Active customers, sites, assets and outstanding work are the starting point. Relevant historical records may also need to be available to engineers servicing those assets.
Clean the data before importing it. Merge duplicate customers, correct addresses and standardise naming. Preserve the links: an asset must still belong to the correct site, a job to its customer, and a certificate to the work it records.
Keep the original export unchanged and document the mapping between old and new references. This gives you a way to investigate records that do not match after import.
If asset records need attention, our guide to asset management for field service explains the information worth organising before you move.
Use representative data to run a job from booking through to payment recording, where that falls within your setup. Dispatch it, open it on the mobile app, complete the forms, attach photos, capture a signature and raise the invoice.
Check the output as well as the process. Is the certificate complete? Is the customer and site information correct? Does the invoice reach the right account with the intended tax treatment and references?
Use a test environment or an agreed test process so customers do not receive trial messages or invoices. Include cancellations, return visits and incomplete forms.
For engineers working without reliable signal, test offline access, data capture and later synchronisation. Check attachments and conflicting updates, not just whether the app opens. Record the results and resolve critical failures before live work depends on them.
Choose a manageable group from both the office and the field. Give them a defined slice of real work, such as one job type, region or group of customers, with clear rules about which system they should use.
Include people who will report difficulties, not only confident users. Watch for missing fields, unclear instructions, extra administration and reports that finance cannot reconcile.
Keep an issue log with an owner, severity and resolution for each item. Agree the conditions for expanding the rollout. Essential forms, job updates and invoice handovers should work before the rest of the business moves across.
Train people on their own tasks. Dispatchers need practice with booking and reassignment. Engineers need to retrieve job details, complete forms and submit work. Finance needs to check invoice handovers and resolve exceptions.
Use realistic jobs and short reference instructions. Ask each person to complete the relevant workflow rather than simply confirm they attended training.
Then document which system owns each job. You might start all new jobs in the new system while finishing a defined list of existing jobs in the old one. Alternatively, you might transfer all outstanding work after checking its status and supporting records.
These approaches require different access arrangements. If staff must finish jobs in the old system, those jobs still need write access. Read-only access is appropriate only once no further updates are required there. Avoid entering the same live job into both systems.
Choose a changeover window that leaves the team time to check the results and respond to problems. Assign owners for scheduling, data, mobile access and accounting issues.
Reconcile the agreed migration scope. Customer and open-job counts are useful, but check record relationships, attachments, recurring visit dates and financial totals too. Keep a list of deliberate exclusions so differences can be explained.
Take a final export or transfer of changes made since the test import. Otherwise, records updated during preparation may be missing from the new system.
Define the fallback before go-live: who can pause the rollout, how engineers will receive their work, and how updates captured during an interruption will be reconciled afterwards. An old-system login alone is not a complete fallback plan.
Review missed appointments, incomplete forms, unbilled jobs and support issues during the first days and weeks. Investigate persistent problems rather than assuming every delay is part of settling in. Once the switch is stable, use your pre-move baseline to measure the return on investment.
Choose how to handle existing work before setting the changeover rule. There are two practical approaches:
Finish selected jobs in the old system. Keep the necessary write access for a defined list of jobs, with an owner and target closure date. Start new work in the new system.
Transfer outstanding jobs. Move their current status, supporting information and remaining actions, then stop updating the old copies.
A job awaiting its final invoice may be simpler to finish where it is. A long-running contract may justify a transfer so the team does not maintain two operational systems for an extended period.
Pay particular attention to:
Unaccepted quotes: retain the scope, price, validity and acceptance status. Confirm how accepted quotes will become jobs if direct conversion is unavailable.
Part-completed work: preserve completed tasks, parts used, forms, photos and the remaining scope.
Return visits: retain the fault history, outstanding actions and parts required.
Unbilled work: assign responsibility for raising each invoice and checking that it is neither missed nor duplicated.
Maintain a transition register showing the job reference, responsible person, system of record and next action. Staff should not have to guess where to find the current version.
End operational use first, then decide when to end access. Before cancelling, confirm:
Live work is accounted for. Every job left in the old system has closed or transferred, including outstanding quotes and unbilled work.
Records are reconciled. Counts, relationships, attachments and relevant financial totals match the agreed migration scope.
Archives are usable. Someone has successfully retrieved an old customer record, job history and certificate from the retained export.
Exceptions are resolved. Missing documents and failed imports have been addressed, not simply logged.
Archive ownership is clear. A named person manages access, security, retrieval and the applicable retention schedule.
Contract-end arrangements are confirmed. Notice, remaining access and data return or deletion arrangements are documented.
Do not rely solely on whether an export opens. Test whether someone unfamiliar with the migration can find the evidence needed for a customer query or audit.
Use these questions during planning with Fieldmotion. Treat them as checks for your proposed setup, not promises that everything in your old system will transfer automatically.
Data imports: Which records and attachments can be imported, in which formats, and how will customer, site and asset relationships be preserved?
Forms: Which forms need configuring, who approves their contents, and how will completed outputs be tested?
Recurring work: How will existing schedules, next visit dates and outstanding visits be checked before go-live?
Accounting: Which connection or export process applies to your package? Confirm supported records, transfer direction, tax and account-code mapping, duplicate prevention and error handling.
Onboarding: Who owns data preparation, configuration, training and acceptance checks on each side?
Support: Who should staff contact during rollout, what coverage is agreed, and how will urgent issues be escalated?
Work through these questions using examples from your own jobs and records. Record the answers in the migration plan so both sides have the same expectations.#
Build the schedule around data preparation, configuration, testing, training and contractual notice. Ask the new provider to review a sample export before agreeing dates. A target go-live date should leave room to resolve failed tests, rather than assume everything will pass first time.
It depends on what the old system exports and what the new one can import. Some history may become live records; other information may remain in a searchable archive. Test both retrieval and the links between customers, sites, assets and documents before ending access.
A controlled overlap can be useful, provided each job has one system of record. Keep write access only where work still needs completing. Move the old system to read-only when updates there have ended, and avoid maintaining duplicate versions of the same live job.
Name an internal lead with authority to coordinate decisions and deadlines. Involve representatives from dispatch, engineering and finance, plus the person responsible for data protection where appropriate. Agree the provider's responsibilities in writing, including imports, training, testing and go-live support.
Assign an owner, record the evidence and sign off each task before moving on.
|
Task |
Owner |
Completion Check |
Sign-off |
|---|---|---|---|
|
Map essential workflows and handovers |
Office, field and finance agree requirements |
||
|
Check contract, notice and export arrangements |
Dates, charges and access confirmed in writing |
||
|
Obtain and test a sample export |
Required records, attachments and links identified |
||
|
Agree migration scope and retention requirements |
Live data and archive lists approved |
||
|
Clean data and preserve original exports |
Duplicates resolved and reference mapping recorded |
||
|
Configure forms, schedules and accounting handovers |
Essential workflows ready for testing |
||
|
Test complete jobs and exception cases |
Outputs and handovers checked without affecting customers |
||
|
Test offline work and later synchronisation |
Job data and attachments recovered correctly |
||
|
Run a controlled pilot and resolve critical issues |
Rollout conditions met |
||
|
Train each role on its own tasks |
Staff demonstrate the relevant workflow |
||
|
Assign each open job to one system |
Transition register includes owners and next actions |
||
|
Agree final export and changeover access rules |
Late changes covered and write access defined |
||
|
Confirm fallback and escalation arrangements |
Owners, trigger conditions and recovery process recorded |
||
|
Go live and reconcile transferred records |
Counts, relationships and relevant totals checked |
||
|
Test archive retrieval and resolve exceptions |
Required evidence accessible and issues closed |
||
|
Retire the old system under agreed arrangements |
No live work remains and archive ownership confirmed |
The final test is practical: engineers can find their work, the office can see its status, finance can account for it, and past records remain retrievable. Those checks should determine when the move is complete.