Migrations do not fail at the import step
Ask an owner who has switched field service software what went wrong, and they will rarely say the data import failed. Imports mostly work. What they describe instead is the second week: a technician dispatched to an address that came across truncated, an invoice sent twice because the old system still had it queued, a customer who called the number on last month's paperwork and reached a voicemail box nobody checks anymore.
As of August 2026, the failure mode in service software migrations is operational, not technical. The data moved fine. The business kept running on habits shaped by the old system, and the seams between the two showed up as missed jobs.
This guide is the sequence that avoids that. It covers what to migrate and what to deliberately abandon, the order of operations for cutover, the specific traps that cost bookings, and how to know within two weeks whether the change actually worked.
First: decide whether to switch at all
Switching is genuinely disruptive, so it should clear a real bar. Three reasons justify it. Everything else is usually a configuration problem wearing a migration costume.
Reason one: the system cannot do something structural you need. Not "the interface is dated" but "it cannot handle a second location," or "it has no path to answer the phone and book on the call," or "it cannot produce per-technician job costing." Structural gaps do not close with training.
Reason two: you are paying for four things that should be one. A scheduler, a separate CRM, a separate invoicing tool, and a separate phone or answering service, each with its own login, its own export, and its own version of the customer. The consolidation case is laid out in all-in-one versus point solutions. The cost is rarely the subscriptions — it is the reconciliation labor and the errors at the seams.
Reason three: the economics changed. Per-user pricing that punishes hiring, per-booking fees that scale against you, or a per-call answering service whose bill grows exactly when business is good. Run the numbers rather than the feeling; what AI operations actually cost shows the shape of that math.
If none of those apply, fix the configuration instead. Most "we need new software" conversations end with a duration setting, a missing service type, and a price list nobody has updated in two years.
What to migrate — and what to leave behind
The instinct is to bring everything. That instinct is what turns a two-week project into a two-month one. Sort your data into three buckets.
Must move
- Customers, with validated service addresses, phone numbers, and email. This is the asset. Everything else is replaceable.
- Open and future appointments. Every job on the books from cutover forward, with the assigned technician and the real duration.
- Outstanding balances and unpaid invoices. Anything representing money owed to you.
- The price list, in the structure the new system expects — service types with real durations, not a flat catalog.
- Active recurring agreements: maintenance contracts, seasonal plans, standing commercial routes.
Move if it is clean
- Equipment and site records — what is installed where, model and serial. Enormously valuable for repeat-service trades, and usually the messiest data you own.
- Recent job history, meaning roughly the last twelve to twenty-four months. Enough for a technician to see what happened last visit.
- Photos and documents attached to recent jobs.
Leave in the old system, read-only
- Job history older than about two years.
- Closed tickets, resolved notes, dead leads.
- Anything you have never once looked up.
Keep the old system readable for a year rather than migrating its archive. Export a flat backup, keep a login if the vendor allows it after downgrade, and move on. Nobody has ever regretted not migrating four-year-old dispatch notes; plenty of businesses have stalled a migration trying to.
The data cleanup nobody budgets for
Cleanup, not transfer, is where the time goes. Four problems appear in essentially every service business export.
Duplicate customers. The same household appears three times because the phone number was entered with dashes, without, and with a leading one. Deduplicate on normalized phone — last ten digits — rather than on name, which is unreliable. Migrating duplicates means your new system starts with the same confusion the old one had, and your AI receptionist will fail to recognize returning customers who are split across records.
Addresses that are not really addresses. "Behind the Shell station," "same as last time," "apt B." These worked because a human read them. A routing engine cannot. Anything you intend to dispatch or geocode against has to be a real address, and it is worth geocoding the whole customer file before import to find the failures in bulk rather than one dispatch at a time.
Service types that are a free-text field. If the old system let staff type the job description, you have four hundred variants of six actual services. The new system needs a bounded list with durations attached, because that list is what makes phone quoting and availability-aware booking possible — see how an AI receptionist quotes from your price list.
Prices that live in someone's head. Very common. The migration is the moment to write them down, because a documented price list is a prerequisite for both quoting on the call and for meaningful job costing.
Treat all four as improvements you were going to have to make anyway. That reframing matters, because otherwise the cleanup feels like migration overhead rather than the actual value.
The cutover sequence
Order matters more than speed. This sequence protects the calendar and the phone, which are the two things customers notice.
| Phase | What happens | Duration | Risk if skipped |
|---|---|---|---|
| 1. Configure | Services, durations, technicians, skills, territories, price list, business rules | 2–5 days | Booking produces schedules nobody can work |
| 2. Import customers | Deduplicated, geocoded customer file only | 1 day | Duplicate records poison recognition and reporting |
| 3. Dry-run booking | Staff book fake jobs, verify durations and travel time | 2–3 days | Configuration errors surface on live customers |
| 4. Import open work | Future appointments, unpaid invoices, active agreements | 1 day | Jobs on the books get lost |
| 5. Verify calendar | Reconcile new calendar against old, job by job, for 30 days out | 1 day | The one failure customers feel immediately |
| 6. Cut over bookings | All new work enters the new system; old goes read-only | Instant | Dual-write causes double-bookings |
| 7. Move the phone | Port or forward numbers; point answering at the new stack | 1–3 days | Calls arrive into an unvalidated system |
| 8. Watch | Daily review of calls, bookings, and invoices | 2 weeks | Small errors compound quietly |
Two things in that table deserve emphasis.
Phase 5 is not optional and cannot be sampled. Print the next thirty days from both systems and reconcile every single job. This is a tedious afternoon that prevents the specific disaster where a customer arrives home for an appointment that exists in a system nobody looks at anymore.
Phase 7 comes near the end, not the beginning. The temptation is to move the phone first because it feels like the headline change. Do not. Keep calls flowing through the known-good path until the calendar underneath is verified. If you are adopting AI answering as part of the switch, the agent needs a correct price list, correct durations, and a correct calendar before it starts committing to slots — otherwise it will confidently book jobs against configuration that has not been checked.
Dual-write is the trap
The most damaging decision available during a migration is running both systems live for new work "just to be safe."
It sounds prudent. In practice, a dispatcher takes a call at 4:50 p.m., enters it in the new system, means to mirror it into the old one, and gets pulled away. Now a job exists in one place. Whichever system a technician checks the next morning determines whether that customer gets served. Within a week you have two calendars that disagree and no reliable way to know which is right.
Pick a date and a time. Before it, the old system is authoritative. After it, the new one is, and the old one becomes read-only. Tell every person who touches the schedule. If you can revoke write access on the old system, do it — willpower is not a migration strategy.
The parallel-read period is fine and useful: keeping the old system visible for history lookups costs nothing and reassures staff. It is parallel writing that breaks things.
Ten days that decide whether it worked
Migrations are judged on the first two weeks. Watch these six signals daily.
- Calls answered versus offered. If answer rate drops after cutover, something in the routing is wrong and it is costing you jobs today, not eventually. Baseline it before you switch — method in call abandon rate and ring time.
- Bookings per day compared to the same period last month. A dip usually means the intake script is asking for something it should not, or availability rules are too tight and the system is refusing slots it should offer.
- Reschedules and cancellations. A spike here means the calendar is committing to times the field cannot work — almost always a duration or drive-time configuration error.
- First-visit completion. Technicians arriving without the right information or equipment points at incomplete data migration on the equipment and site records.
- Invoices sent and paid. Money is where quiet double-entries surface. Watch for duplicates from the old system's queued automations, which are easy to forget to disable.
- Customer recognition rate. When a repeat customer calls, does the system know them? Low recognition means the dedupe did not work, and it is much cheaper to fix in week one than in month six.
Reading actual call recordings for the first two weeks is the highest-value habit in the whole migration. It surfaces script problems, quoting errors, and routing mistakes far faster than any dashboard. If recording is new to you, check the obligations first in call recording consent and compliance.
Once calls, calendar, customers and invoices are on one spine, this monitoring stops requiring report-building — you can ask the Jarvis AI Brain plainly how many calls booked yesterday versus the same day last month and get an answer from live records.
Things that break that nobody warns you about
Automations still running in the old system. Reminder texts, review requests, invoice follow-ups, recurring job generation. These keep firing after cutover and your customers get two of everything. Inventory every automation before you switch and disable them explicitly.
Accounting connections. If the old system synced to QuickBooks, connecting a new one without disconnecting the old produces duplicate transactions that are genuinely painful to unwind. Disconnect first, verify, then connect. The mechanics are covered in QuickBooks sync for service businesses.
Review request cadence. Review automation is per-platform and easy to double up. Two requests for one job reads as spam and costs you the review you were asking for — see getting more customer reviews.
Old phone numbers on old paperwork. Invoices, van wraps, yard signs, and last year's mailers carry numbers that will keep ringing for years. Forward them; never let one go dead. Tracked forwarding also means you learn which legacy channel is still producing, which feeds call tracking and attribution.
Technician muscle memory. Field staff will keep opening the old app for weeks. Remove it from their devices on cutover day rather than asking them to remember.
Google Business Profile details. If the switch changes any customer-facing number, the profile has to change with it, and the change should be made once rather than repeatedly — the Google Business Profile guide covers the details that matter for local ranking.
Getting the team through it
Software migrations fail on people at least as often as on data, and the pattern is consistent enough to plan around.
Dispatchers resist hardest, and they are usually right to. They are the ones whose fluency evaporates overnight. Someone who could build a full day's board in twenty minutes is suddenly slower than a new hire, in front of everyone, during a busy week. Treat that seriously: give dispatchers early access during the dry-run phase, let them break things in a system with no real customers in it, and ask them to help define the service list and durations. A dispatcher who helped configure the thing arrives at cutover day as an owner rather than a victim.
Technicians care about exactly three things — can I see today's jobs, can I get directions, and can I close a job out without a fight. If those three work on their phone, adoption is close to automatic. If any one is clumsy, they will revert to texting the office, and your job data quietly stops being real. Test the field app on the actual devices your crew carries, including the oldest one, before cutover.
Office staff will keep a spreadsheet. Someone always does, because the old system did not do something they needed and the spreadsheet filled the gap. Find it during discovery and ask what it tracks — it is almost always pointing at a real requirement nobody wrote down. Migrating without answering it means the spreadsheet survives the migration and your new system is immediately incomplete.
Announce the cutover date twice and hold it. Sliding the date once teaches everyone the date is negotiable, and the parallel period stretches — which is precisely the state in which double-bookings breed.
What the switch costs on this platform
Run with Jarvis has no onboarding fee and no contract, which changes the risk profile of switching:
- Core — $500/month. 500 AI call minutes, $0.45 per minute after. 24/7 bilingual AI receptionist, booking and calendar, GPS tracking and route optimization, auto ETA and arrival SMS, multi-outlet POS, invoicing with QuickBooks bidirectional sync, CRM and customer portal, review automation, mobile app, chargeback defense.
- Pro — $750/month. 1,000 minutes, $0.40 after. Everything in Core plus dynamic number insertion, Google Ads and Meta attribution, transcription and lead scoring, call recording and playback, power dialer and softphone, callback scheduling.
- Elite — $1,200/month. 2,500 minutes, $0.35 after. Everything in Pro plus AI campaign building, Google Business Profile management, AI review replies, LSA lead management, competitor intelligence and the Jarvis AI Assistant.
All three are month-to-month with zero setup fees and unlimited users, so a migration does not require committing to a year of something you have not run live yet. The platform also places AI outbound follow-up calls against your own leads and customers — stalled quotes, unpaid invoices, reactivation — with /pricing showing which tier carries which outbound capabilities.
Before signing anything, run the vendor through the AI receptionist vendor evaluation checklist, and if booking depth is central to your decision, test it specifically using the probes in will an AI phone agent book into my existing scheduling software.
The short version
Clean the data before you move it. Move only what you actually use. Configure and dry-run before a single real job enters the new system. Verify thirty days of calendar job by job. Cut over on a date, not gradually. Move the phone last. Then watch six numbers daily for two weeks and fix what moves.
Done in that order, a migration costs a few weeks of attention and no lost jobs. Done in the opposite order — phone first, cleanup later, both systems live "just in case" — it costs a month of credibility with customers who did not sign up to be part of your rollout.
Thinking about moving? Get in touch and we will walk your current stack and sequence the switch before anything gets touched.
