Start just as simply. Grow past it.
The day-one basics (customers, scheduling, estimates, invoicing, payments) work the same from the first morning. The difference is what comes next: dispatch and the rest of the shop on the same platform, so the third truck does not mean a third migration.
Is it time?
The signs shops leave Jobber on.
You are adding trucks
A calendar shows time; it does not show trucks, overlap, or the job nobody took. Dispatch needs a board.
The seat math started
Every hire now has a software line attached. Here people are people on the record: $0 each, at every size.
Recurring work slips
The maintenance visits that keep the month steady deserve a record, not a memory. Recurring rules are rebuilt deliberately on this side.
What comes over
The history is yours. It comes along.
- Customers, contacts, and locations
- Jobs and appointments
- Estimates, invoices, payments, and outstanding balances
- Price books
- Notes, tags, files, and photos
- Team members: every name, no seat count
And what doesn’t: said here, not discovered later.
In-app conversation threads
Message history inside Jobber does not export cleanly. What their export exposes comes; the rest stays theirs.
Recurring job rules
Rebuilt on this side rather than translated blind, so the schedule you end up with is the one you meant, not a guessed import.
Moving day
Leave without looking back.
The history comes with you, validated line by line. The only thing left behind is the bill.
How migration works
Nine steps. Not “import, then hope.”
01
Export
Pulled through the API or their export. Nothing is retyped by hand.
02
Mapping
Fields land in their Thorbis homes, custom fields and tags included.
03
Staging
A separate copy, away from anything live. The live shop is not the test environment.
04
Validation
A report you read: record counts, balances, unmapped fields. You sign off.
05
Parallel operation
Their system stays up beside the board while you confirm the data matches.
06
Cutover
Live when you approve it. You pick the morning, not a go-live calendar.
07
Reconciliation
Key totals compared against the old system. Money has to match or it waits.
08
Rollback prep
The original export is retained, so the load can re-run if something is wrong.
09
Post-launch review
Flagged records walked through with you. Nothing left in limbo.
No fixed clock is promised. The load is verified, and both systems run in parallel until you call the board the record.
Cutover controls
The switch is kept boring on purpose.
01
A freeze window
A short window where the old system stops changing, so the final delta is clean.
02
Owner sign-off
Nothing cuts over until the validation report has a name on it.
03
An exception list
Anything the importer could not map cleanly is flagged for review, not silently dropped.
04
Rollback notes
What we would do if Monday is wrong, written down before Monday.
Asked before the switch
Straight answers.
Will switching be a big change for the team?
The basics work the same way from day one: book the job, send the estimate, invoice, take payment. The new capabilities, like the dispatch board, turn on when you are ready for them, not all at once.
What happens to open jobs and unpaid invoices?
They come across in the guided migration, and the validation report shows the totals against Jobber’s records before cutover. If the numbers do not match, the load waits.
Will I have to migrate again when I grow?
No. Dispatch, inventory, payroll, and reporting arrive on this same platform as they ship. The roadmap says which stage each is in. Growth turns modules on; it does not start another migration.
Coming from somewhere else?
Start
Bring the history. Leave the mess.
Standard migration is in Core. You do not buy a project to leave the software you already paid for. The dry run is yours to reject.
Coming from Jobber? We’ll extract your records.
Rather talk first? Email the team.