Which platforms does the FieldCamp migration tool support?

Zenbooker, Kickserv, Jobber, and Service Fusion. No other platform is supported by the migration tool.

Is it safe to run the same migration step twice?

Yes. Every step is idempotent — already-migrated records are counted as skipped, not created again. On Zenbooker and Kickserv, re-running a step already marked done returns straight away without re-reading the source, so it is safe but has no effect.

Will my customers be notified during the migration?

Not automatically for every platform. Only Service Fusion suppresses client automation, so Zenbooker, Kickserv and Jobber client imports still fire new-client workflows. Job and visit suppression works for Zenbooker and Service Fusion only, so new-job and new-visit workflows can fire for Kickserv and Jobber. Pause your new-client, new-job and new-visit workflows before running those imports.

Switching from Zenbooker, Kickserv, Jobber & Service Fusion | FieldCamp

Q: Can I migrate only clients and skip jobs and invoices?

Yes. Each entity type has its own Run button, so you can bring clients over now and the rest later.

Step-by-step guide to switching from Zenbooker, Kickserv, Jobber, or Service Fusion to FieldCamp using the API-based data migration tool.

Under the hood — the FieldCamp data model shows how every record connects, how you can customize it, and how it maps to your trade.

Switching from Zenbooker, Kickserv, Jobber, or Service Fusion to FieldCamp is designed to be fast, predictable, and low-risk. FieldCamp connects to your old platform's API and pulls the records across — there are no CSV files to prepare. This guide walks you through getting your API credentials, running the migration, and verifying everything once you land inside FieldCamp.

Why teams switch to FieldCamp

Most teams move to FieldCamp because they want the modern automation, AI-powered dispatching, and unified inbox they cannot get from legacy platforms. Common reasons we hear:

They want true AI-driven dispatching instead of manual drag-and-drop scheduling.
They are tired of paying for add-ons that should be standard (texting, online booking, route optimization).
They want a single workspace where estimates, invoices, and payments live alongside the calendar and CRM.
They need real automation through a workflow builder, not just templates.

The migration tool is not gated by plan, subscription, or add-on. Access is decided by your role alone — see Who can open the migration tool below.

Supported platforms

The migration tool supports four source platforms. Each one appears as a card in the tool.

Zenbooker

Team members, services, clients, jobs, invoices.

Kickserv

Clients, jobs. The Jobs step does more than its name suggests — it also creates the products and services on each job, the taxes those lines need, the job's invoice, and any payment already recorded against it.

Jobber

Clients, products & services, team members, jobs, quotes / estimates, invoices.

Service Fusion

Team members, products & services, clients, jobs, estimates, invoices, payments.

Records land in the normal FieldCamp modules: clients, jobs, estimates, invoices, and your price book.

Housecall Pro is not supported by this tool. Neither is any other platform not listed above. If you are coming from one of those, move your data across with the CSV importers instead — start with the client CSV and Excel import guide, then import jobs. Developers can also push records with the FieldCamp API.

Who can open the migration tool

The tool lives at app.fieldcamp.ai/settingsV2/data-migration. It is deliberately hidden from the Settings sidebar, so you have to type the address directly.

You need an account admin (the admin or superAdmin role, or a user with no role assigned). Anyone signed in with an email address on FieldCamp's own internal domain can also open it — the check is on the email address itself, not on a staff flag or a role. Everyone else sees an unauthorized screen. Review roles and permissions if you are not sure which role you have.

Before you start: pre-migration checklist

A clean migration starts with a clean source. Spend 15 minutes on these items before you run it.

Create your FieldCamp account

Set up team members

Invite techs and dispatchers so jobs can be assigned to the right owner. See adding and managing team members. The migration can also bring team members over for Zenbooker, Jobber, and Service Fusion.

Decide on a cutover date

Pick a date to stop creating jobs in the old system. Most teams choose a Friday so they have the weekend to verify data.

Get your API credentials

Generate the API token or Connected App for your platform using the section below. You need admin access in the old system to do this.

Back up attachments

Download a copy of important client documents and job photos. Keeping originals locally is good insurance.

Getting your API credentials

The tool asks for credentials the moment you open a platform card. For Zenbooker, Kickserv, and Service Fusion they are held only for that browser session and are never stored. Jobber works differently — see below.

Zenbooker

One field:

API Token — generate it at Zenbooker → Settings → API Tokens. It starts with zbk_.

Kickserv

Two fields:

API Token — your Kickserv API token. It starts with p-. The field has no in-app hint, so ask your Kickserv admin if you are not sure where to generate it.
Account Slug — the subdomain part of your Kickserv URL (for example b82986 in b82986.kickserv.com).

Jobber

Jobber does not use a pasted token. The modal shows a Connect Jobber button that opens Jobber's authorization window. Sign in there and approve access — your Jobber password never touches FieldCamp. Once approved, the window closes and the migration status appears. If you have connected Jobber before, use Already connected — continue.

Jobber is the one exception to "nothing is stored". The access and refresh tokens Jobber issues after you approve are saved against your FieldCamp account, so the later migration steps can keep reading from Jobber without asking you to sign in again. Disconnecting Jobber removes them.

Service Fusion

Service Fusion uses OAuth2 client credentials. Create a Connected App under Service Fusion → My Office → Developer Settings → Connected Apps, then paste:

Client ID
Client Secret

Give the token or Connected App full read access. FieldCamp can ignore data it does not need, but it cannot read what the token is not allowed to see.

Running the migration in FieldCamp

Open the tool

Go to app.fieldcamp.ai/settingsV2/data-migration directly. It is not listed in the Settings menu. You will see one card per supported platform, each showing how many entity types it covers.

Pick your platform card

Click Open Migration on Zenbooker, Kickserv, Jobber, or Service Fusion.

Enter credentials

Paste the token or Client ID / Client Secret and click Continue. For Jobber, click Connect Jobber and authorize instead.

Check the totals

Each entity type is listed as a row. Where FieldCamp knows the source total, the row reads "migrated / total" and draws a progress bar. Where it does not, the row shows the migrated count alone, with no total and no bar. Use Refresh totals to read the counts from the source platform again.

Jobber is the sparse one: it fetches a total only for Clients, and only when you press Refresh totals. Every other Jobber row shows a count with no total and no progress bar.

Do not read a full-looking row as proof that the migration ran. Most Zenbooker "migrated" counts are counts of everything in your FieldCamp account, not only what came from Zenbooker, and the Kickserv jobs count reads a field the importer never writes. On an account that already has data, those rows can look complete before a single record has been migrated. Trust the records themselves, not the number.

Run each entity in order

Press Run on each row. Entity types that depend on others are blocked until their dependency has records — the row tells you what it is waiting on, printed as the raw step keys rather than the friendly labels, for example blocked by: clients, items, team. The order is:

Zenbooker — Team Members, Services, Clients (any order), then Jobs (needs Clients + Services), then Invoices (needs Jobs).
Kickserv — Clients, then Jobs (needs Clients).
Jobber — Clients, Products & Services, Team Members (any order), then Jobs and Quotes / Estimates (need Clients), then Invoices (needs Jobs).
Service Fusion — Team Members, Products & Services, Clients (any order), then Jobs (needs Clients + Products & Services + Team Members), Estimates and Invoices (need Clients + Products & Services), then Payments (needs Invoices).

Run all remaining runs every row for you, in order, skipping anything already complete.

Watch the step finish, then fix failures

There is no live progress. A step is one request, and the row updates once when it comes back. While it runs the button reads Running…; when it returns, the row shows the migrated count against the source total — for example "40 / 40 migrated" — plus "• N failed" if any record failed. Created and skipped counts appear only in the toast that pops up after the step returns, so read that toast before it fades.

If records failed, a View errors link lists which ones and why.

The button can read five things:

Run — not started yet.
Running… — the request is in flight.
Retry — the whole step threw and did not finish.
Resume — a long run stopped part-way and will pick up where it left off.
Re-sync — the step finished. Press it to run the step again.

Note the difference between Retry and Re-sync. If individual records failed but the step itself completed, the step is still marked done and the button reads Re-sync. Retry appears only when the whole step threw.

Retry, Resume, the "Resumes from N processed" line, the last-error line, and the Reset & re-run from scratch link exist only for Zenbooker and Kickserv. Jobber does not track checkpoints at all, and Service Fusion reports its progress in a different shape, so none of those controls ever appear on those two platforms.

That has one consequence worth knowing on Service Fusion: once a step is marked done, pressing the button again does nothing on the server, and there is no way to clear that state from the screen.

Every migration step is idempotent — records already brought across are counted as skipped, not duplicated. Re-running a step is safe, so there is no undo to worry about. Two caveats:

On a checkpointed step (Zenbooker and Kickserv), re-running it after it is already done returns instantly without re-reading the source platform. It is safe, but it does nothing.
Reset & re-run from scratch clears the checkpoint only. It never deletes records that have already been imported.

Where the data lands

The migration writes into standard FieldCamp records, so nothing needs mapping by hand:

Source record	FieldCamp record
Customer / Client	Client
Job / Booking / Work order	Job
Service / Item	Product or service
Quote / Estimate	Estimate
Invoice	Invoice
Payment	Payment on the invoice
Employee / User	Team member

Payments come across for both Service Fusion and Kickserv. Service Fusion has its own Payments step; on Kickserv the payment is written as part of the Jobs step, along with that job's invoice, its line items, and the taxes those lines need.

If you used custom fields in your previous tool, they are not part of the migration. Create matching custom client fields in FieldCamp and fill them in afterwards. For non-standard records like equipment or properties, consider custom objects.

After the migration: verification checklist

Take 30 minutes to confirm a clean cutover.

Open the clients table view and spot-check 10 random clients.
Open the dispatch calendar and confirm upcoming jobs show on the right days and right techs.
Run an outstanding invoice analytics report and compare totals to your old system.
Confirm your price book and services carried over with correct pricing and taxes.
Test that a brand-new job, estimate, and invoice can be created end-to-end.

Verify against the records, not the counters. Most Zenbooker "migrated" numbers count everything in your FieldCamp account rather than only the Zenbooker rows, and the Kickserv jobs number reads a field the importer never writes. If your account already held data, a row can read as complete when nothing has migrated.

Run both systems in parallel for one week. Keep the old tool read-only and use FieldCamp for all new jobs. This gives you a safe rollback path while your team adjusts.

Turning on automation and AI features

Once your historical data is in, this is the right time to enable the features that make FieldCamp different.

Configure AI Dispatcher so new jobs get smart routing.
Set up online booking and point your website to the new widget.
Build your first workflow automation for follow-ups, review requests, and reminders.
Connect Stripe for online payments and turn on auto-pay where appropriate.
Browse the full add-ons catalog to enable Job Forms, Timesheets, Calls, and other modules you used in your old platform.

Cancelling your old subscription

Once you are confident in FieldCamp (typically 7-14 days after cutover), cancel your old subscription. Because the migration reads through the old platform's API, take a full export from that platform first and keep it in cloud storage for at least 12 months in case you need legacy records for tax or warranty purposes.

Troubleshooting

A step says "blocked by"

That entity type depends on another one that has not been migrated yet. Run the listed dependency first — for example, Jobs is blocked until Clients has records. The row names the dependency using the internal step key, not the label you see on screen, so it reads blocked by: clients, items, team rather than "Clients, Products & Services, Team Members".

A step failed part-way through

Click View errors to see which records failed and why, then press the button again — already-migrated records are skipped.

Which label the button carries tells you what happened. Retry means the whole step threw. Re-sync means the step completed and some individual records failed inside it. Resume means a long run stopped mid-way and will continue from where it stopped.

Retry, Resume, and Reset & re-run from scratch exist only on Zenbooker and Kickserv. On Jobber and Service Fusion the button only ever reads Run, Running…, or Re-sync, and there is no reset.

The totals look wrong or out of date

Click Refresh totals to re-read the counts from the source platform.

One row is always tagged approx: Zenbooker → Invoices. Zenbooker's API does not expose an invoice count, so FieldCamp shows the job count in its place as a stand-in. No other row on any platform carries that tag.

Read the caution under Running the migration in FieldCamp before you treat any number as evidence — several counts are org-wide rather than scoped to the platform you are migrating from.

Some invoice totals are off by a few cents

This is usually a tax-rounding difference between platforms. Open tax settings and confirm your tax rates exactly match the old system. Re-running the migration is not required — adjust new invoices going forward.

My recurring jobs did not come over

It depends on the platform.

Jobber — recurrence does come across. Jobber's recurrence rule is converted into FieldCamp repeat options, a calendar rule, and the recurring visits themselves.
Zenbooker and Kickserv — a repeating job is marked as recurring, but no repeat rule comes with it. You get the job, not the schedule.
Service Fusion — every job is imported as one-off.

Where the rule did not come across, recreate it inside FieldCamp by setting the job up as a recurring job or multi-day job, or attach a contract and terms.

Team member assignments are wrong

If technicians had different names or emails in your old system, jobs may land without the right owner. Fix them from the calendar or the jobs list — open the job and set the technician. Bulk reassign moves one technician's visits to another technician, so it will not help with jobs that have nobody assigned yet.

Duplicate clients appeared

This usually means the same person was stored under two different records in the old tool. FieldCamp has no merge action, so you pick which record to keep: open the duplicate and delete or archive it, then move anything you need onto the record you are keeping. See delete or archive a client.

FAQs

Which platforms does the migration tool support?

Zenbooker, Kickserv, Jobber, and Service Fusion. Nothing else.

Can I migrate from Housecall Pro?

Not with this tool. Use the client CSV and Excel import guide and job import instead, or push records through the FieldCamp API.

Do I need CSV files?

No. The migration reads directly from the source platform's API. There is no file upload and no field-mapping screen.

Are my API credentials stored?

For Zenbooker, Kickserv, and Service Fusion, no — the token or Client ID and Secret are held only for that browser session.

Jobber is different. You sign in on Jobber's own page, so FieldCamp never sees your password, but the access and refresh tokens Jobber issues afterwards are saved against your FieldCamp account so the later steps can keep reading from Jobber. Disconnecting Jobber removes them.

How long does a typical migration take?

It depends on how much data you have and how fast the source platform's API responds. Each entity type is pulled page by page, so a large account takes noticeably longer than a small one. Leave the modal open while a step works — the row only updates once, when the step returns.

Is it safe to run the same step twice?

Yes. Every step is idempotent — already-migrated records are counted as skipped, not created again. On Zenbooker and Kickserv, re-running a step that is already marked done returns straight away without re-reading the source, so it is safe but has no effect.

Will my customers be notified during the switch?

Not automatically for every platform — it depends on which import you run, so pause the relevant workflows first.

Client imports — only Service Fusion suppresses client automation. Zenbooker, Kickserv, and Jobber client imports still fire your new client workflows.
Job and visit imports — Zenbooker and Service Fusion suppress them. Kickserv and Jobber jobs do not carry the marker the suppression relies on, so new job and new visit workflows can fire for those two.

Before you migrate anything other than Service Fusion clients, pause your new-client, new-job, and new-visit workflows, run the import, then switch them back on. Otherwise a customer served months ago can be sent a "your service is booked" message.

Can I migrate only clients and skip jobs and invoices?

Yes. Each entity type has its own Run button, so you can bring clients over now and the rest later.