Switching Field Service Software: What the Process Actually Involves

What does switching field service software involve?

Switching field service software means moving the day-to-day running of your service operation onto a new system in a planned sequence. Most of the work happens before go-live, which is why a well-prepared switch tends to feel uneventful on the day itself. The stages usually run in this order:

• Discovery and scoping: the provider learns how your business runs, and you agree timelines and what a successful go-live looks like.
• Data migration: customer, site, asset, contract and stock records are prepared and validated before import.
• Configuration: the platform is set up around your workflows, and integrations with your accounts package or ERP are built and tested.
• Training: office staff and engineers learn the parts of the system they'll use every day.
• Go-live: the new system starts running your live operation with real data in place.
• Ongoing support: a named contact and a support desk see you through the months after launch.

If you're still deciding whether to move, our post on moving on from legacy FSM software covers the risks of staying put, and there's a broader explainer on what FSM software does. This guide picks up once the decision has been made.

Who needs to be involved in the switch?

A switch runs more smoothly when the right people are involved from scoping onwards. Most projects benefit from:

• An operations or service manager who owns the project and makes the final calls on scope
• Someone from finance who understands your billing rules and the link to your accounts package
• The planners or schedulers who will use the system most heavily in the office
• One or two respected engineers who can test the mobile app and give honest feedback

How long does it take to switch field service software?

There's no standard timeline for switching field service software. The length of a project depends mainly on the volume and condition of your data and the number of integrations that need building. A good provider will set out a realistic timeline during scoping, before configuration or data migration begins.

What affects the timeline?

• Data volume and condition: a business with tens of thousands of asset records and years of service history has more to prepare than one with a few hundred customers, and data spread across spreadsheets takes longer to pull together.
• Integrations: connecting the new system to your accounts package or ERP needs building and testing before go-live.
• Workflow complexity: multiple job types and contract pricing rules all need configuring and checking.
• Your team's availability: data preparation usually sits with your own team, so the time you can set aside for it has a direct effect on the schedule.

When is the best time to switch?

There's rarely a perfect moment, and the longer a switch is delayed, the more the existing system becomes the default. A more practical approach is to avoid planning go-live for your busiest weeks and work back from there. Squeezing the early stages to hit an arbitrary date tends to store up problems for later.

What happens during scoping and set-up?

Scoping is where the provider learns how your business actually works, and set-up is where the new platform is configured to match it. Done properly, the system reflects your operation from the first day, so your team isn't left reshaping its processes to fit the software.

Discovery and scoping

Before anything is built, the implementation team should take time to understand your job types, asset structures, billing rules and workflows, along with any systems the new platform needs to connect to. Nothing should be assumed. This is also where you agree the scope and timeline, and define what a successful go-live looks like.

Configuration

Once scope is agreed, the platform is configured around your workflows. That typically covers digital job forms, planned preventive maintenance schedules, pricing rules, engineer profiles, customer records and stock set-up. Accounts and ERP integrations are built and tested at this stage too. Seeing your own customers and assets inside the platform often helps settle remaining doubts before training begins.

What happens to your existing data?

Your core operational data comes with you. In a structured field service software migration, these records are typically exported from your old system, prepared in templates, checked by validation tools and imported into the new platform before go-live.

What data is usually migrated?

A standard migration typically covers the data your business runs on day to day:

• Customer accounts and sites
• Contacts
• Equipment and asset records, including warranties
• Stock parts and on-hand values
• Service contracts, PPM schedules and basic job details

It's worth confirming early which data types your provider includes, so historic records don't become a surprise later.

Who does the data migration?

It depends on the provider, so agree responsibilities during scoping. In a customer-led migration, your team decides what's worth bringing across and populates the import templates, since you know your data best. The provider explains how each field maps into the new platform and answers questions about structure along the way.

Once the templates are ready, an import tool runs validation checks before anything is confirmed, flagging errors and missing information so you can fix them first. You should be able to run as many test imports as you need, and nothing should go live until you're satisfied. A final cleanse before go-live then clears out any test data. For a step-by-step look at how this process works, see our guide to moving from Protean to Service Geeni.

Is migration a chance to clean up your data?

Yes, and it's one of the more useful side effects of switching. Preparing data for import often surfaces duplicate records and equipment that's no longer in service, and clearing these out means the new system gives you accurate information from the start.

Poor data quality is a problem well beyond field service. In their 2026 State of Data Integrity and AI Readiness report, which surveyed 505 data and analytics leaders at large organisations, Precisely and Drexel University's LeBow College of Business found data quality was the most common data integrity priority, cited by 51% of respondents, and the biggest challenge to the success of data integration projects.

How do you get engineers to use the new system?

Engineers often come round to new field service software quickly once they can see how it makes their working day easier. Involving a couple of respected engineers early, and explaining clearly why the business is switching, tends to do more for adoption than mandating it from the office.

In Prosci's research on resistance to change, change practitioners identified the top reason employees resist change as a lack of awareness of why the change is happening. Engineers who understand the reasons before training starts are more likely to give the new system a fair try.

What's in it for engineers?

Before a switch, engineers often spend part of every job calling the office for job details or filling in paper forms. A good engineer mobile app puts job details, asset history, parts availability, risk assessments and customer notes in front of them before they arrive on site, and forms are completed on the job.

Having that information on site matters because repeat visits are expensive. Aquant's 2026 Field Service KPI Benchmark Report, based on nearly 30 million service events across 161 service organisations, found failed visits accounted for 25% of total service cost at the median. It also found that in weaker-performing teams, critical knowledge tends to sit with a small number of experienced people. Putting the full asset history on every engineer's phone is one practical way to spread some of that knowledge more widely, which supports improving first-time fix rates across the whole team.

How should engineers be trained?

Training works best when it's practical and specific to each role. Engineers mainly need to learn the mobile app, so there's little need to cover the finance module or reporting suite. The aim is for every person to be able to do their own job from day one, which is far more achievable than knowing every feature in the system.

Where you can, give engineers time to practise on realistic jobs before go-live, since confidence on site comes from repetition as much as from a training session. An app that works offline also helps, as plant rooms and remote sites don't always have a reliable signal.

What about engineers who resist the change?

Most teams have an engineer who has done things the same way for 20 years. Arguing rarely helps, so show them a real situation where the new system would have made a difference, such as a repeat visit caused by missing information or a customer query that took 20 minutes to answer because the history wasn't to hand. When respected colleagues come back from training saying the app is straightforward, the rest of the team listens. Most sceptics come round eventually, even if it takes a few weeks of using the system before they'll admit it.

What happens on go-live day?

On go-live day, the new system starts running your live operation with your real data already in place and the implementation team on hand to help. Because the preparation happens in the weeks beforehand, many businesses find the day itself is quieter than they expected.

Engineers start receiving jobs on the mobile app and the office team schedules work in the new system, with support available throughout the day. It's also worth agreeing with your outgoing provider in advance whether you'll keep read-only access to the old system for reference during the first few weeks.

What should you check in the first week?

In the first week, it's worth checking that:

• Jobs are reaching engineers' phones with the right details attached
• Completed jobs are moving through to invoicing without manual steps
• PPM visits are generating on schedule against the correct assets
• Stock used on jobs is recording against the right van or store

Fixing gaps early stops workarounds from taking hold.

What support should you expect after switching?

A field service software implementation shouldn't end at go-live. After switching, you should expect:

• A dedicated customer success contact who understands your set-up and checks in as you settle
• A knowledge base of how-to guides and videos your team can use without raising a ticket
• A support desk with clear, published response and resolution times
• Help refining your configuration as you spot gaps or want to make more use of the system

As a reference point, Service Geeni's support team responds to 100% of support issues within 30 minutes and resolves 100% of major issues within 60 minutes.

The weeks after go-live are also when old habits creep back, such as a planner keeping a spreadsheet on the side. The switch sticks when managers keep reinforcing the new way of working and remove old workarounds once the system covers them. Support after go-live is worth discussing before you sign, and our guide to choosing the right FSM tool covers what to ask providers.

Download the full switching guide

The No-Nonsense Guide to Switching Field Service Software covers each stage in this post alongside the signs it's time to switch and the real cost of staying on a system that isn't working. It also includes the questions worth asking any provider before you sign. Download your copy below.