Moving from Jobber or DripJobs to GoHighLevel: what breaks and what doesn't

Do not treat a move from Jobber or DripJobs to GoHighLevel as a like-for-like migration. Keep both systems if you depend on field-service scheduling, routes, recurring jobs, or job costing; make a full move only if your work is simple and appointment-based. Contacts and basic sales records have documented paths into HighLevel. The harder operational records do not.

Your customer list is not the main risk. Names, phone numbers, email addresses, tags, basic fields, pipeline records, invoice summaries, and some payment history can move through CSV files. The risk is losing the connections around that data: which visit belonged to which job, who was assigned, how profit was calculated, where the signed document lived, and which payment belonged to which invoice.

What does GoHighLevel replace, and what does it not replace?

GoHighLevel can handle contacts, opportunities, pipelines, appointment booking, invoices, and historical transactions. Its service calendars support services, staff availability, duration, locations, and customer booking. HighLevel also documents invoice CSV imports, installment schedules, partial payments, and editing partially paid invoices while preserving recorded payments.

So it is too broad to say that HighLevel has no scheduling or real invoicing. The distinction is what those functions are connected to.

Jobber treats a job as the overall scope of work and visits as scheduled appointments inside that job. Its visit records include assignment, status, instructions, scheduled duration, and time tracking. Jobber separately documents route optimization and recurring jobs with repeating visits and billing schedules.

DripJobs documents appointment and job scheduling, proposals, invoicing, and payments in its plan descriptions. Its job-costing system records labor, materials, miscellaneous costs, actual costs, and profit margin.

Our assessment is that HighLevel does not provide a documented, like-for-like migration target for those field-service structures. No retrieved HighLevel page states in one place that it lacks job costing, field dispatch, or route optimization. The conclusion comes from comparing the documented systems and finding no native HighLevel CSV process that recreates jobs, visits, routes, recurring-job billing structures, or contractor job-cost records.

The same distinction applies to invoicing depth. HighLevel has genuine invoicing functions. What has not been established is that an imported invoice preserves every contractor-specific connection among the original proposal, job, visits, costs, deposits, changes, payments, and supporting files. Importing invoice rows is not the same as recreating the operating record that produced them.

For a broader platform comparison, read GoHighLevel for contractors: what it actually does, and what it doesn't. This article stays focused on the migration.

What migrates cleanly, what must be rebuilt, and what is lost?

Will you lose your job history?

You do not have to lose the raw history. You can still lose its structure.

Jobber stores clients, quotes, jobs, visits, invoices, notes, and files as separate records. Its reports are also separate CSV exports. Those files have to be connected through identifiers such as client, quote, job, and invoice numbers. Keeping a visits spreadsheet is not the same as opening a customer and seeing the original job, assigned visits, invoice, attachments, and communications in one connected record.

Preserve the source identifiers in dedicated HighLevel custom fields. Useful examples are the Jobber client ID, job number, quote number, and invoice number, or the DripJobs record ID. HighLevel documents importing information into custom fields. Keep the untouched CSV and PDF exports as well. This gives the office a path from a HighLevel contact or opportunity back to its original records.

Attachments require their own index. A folder full of roof photos or signed proposals is incomplete if nobody can tell which customer and job each file belongs to. Name or index each downloaded file with the source customer ID, job number, record type, and original filename. That step preserves context even when the destination cannot recreate the original attachment relationship.

Jobber's attachment rules make this a real workload rather than a single export click. As of September 2026, a saved Jobber note only shows the ZIP export option when it contains at least five attachments. Notes with fewer attachments require individual saving, and the option is not an account-wide bulk export. Jobber documents those limits in its notes and attachments guidance.

Communication history needs the same caution. HighLevel's own contact export documentation says automation history, including prior email and SMS logs, is excluded from contact CSV exports. It also says notes over 255 characters can be truncated on export as of September 2026. That describes export from HighLevel rather than import into it, but it demonstrates why a contact spreadsheet should never be the only historical archive.

Do not permanently close the old account immediately after a contact import appears successful. Jobber says reports become unavailable after permanent account closure. Its normal closing process does not provide one complete migration package: reports are CSV files, while jobs, quotes, and invoices require separate handling. Equivalent DripJobs closure and retention rules were not found, so verify those rules with DripJobs before canceling.

What should a migration rehearsal include?

Test records that expose relationships, not ten easy customers with one phone number each. Include a repeat customer, multiple service properties, several jobs, a lost lead, a recurring job, a partially paid invoice, notes, and attachments. Those records reveal whether the field map preserves the history your office actually uses.

Start with the repeat customer. Confirm that phone numbers and email addresses do not create unwanted duplicate contacts. Check whether each service address is recognizable and whether the office can tell which work happened at which property. A flat address field is not enough when the source platform treated properties as records connected to jobs.

Next, follow one quote from its original source record to the HighLevel opportunity. Confirm the intended pipeline and stage. Check that the source quote number, job number, value, and status remain available. The goal is not to make the HighLevel opportunity look like a Jobber or DripJobs job. The goal is to retain enough identification to find the original record without guessing.

Then test the partially paid invoice. Compare the invoice number, customer, line items, tax, discounts, deposits, due date, payment status, and recorded payments. The exact HighLevel invoice fields visible in the retrieved material were not complete enough to promise treatment of every one of those details. A real sample in a test account is the deciding evidence.

Finally, open the attachments and archive files as an office employee would. Search by customer and source job number. Confirm that each file opens and that its purpose is clear. A successful row count does not prove that the business retained usable history.

How large should the import files be?

File size is only one control. Split files by record type and preserve untouched originals before cleaning anything. Keep a copy of the prepared import file, the field mapping, and the import result. If a status or custom field later proves wrong, that record shows what was sent and how it was mapped.

Jobber's export split also means several files can represent one customer list. As of March 30, 2026, its client export allows up to 1,500 rows per CSV file, with accounts above 1,499 clients receiving multiple files by email. Combine or process those files carefully so that the later files are not missed. This is not a total customer limit.

HighLevel's published size guidance conflicts. The newer documentation states 30 MB per contact and opportunity CSV as of September 16, 2026, while an older page states 50 MB as of March 24, 2026. Use files below 30 MB unless the live importer clearly displays a different limit. There is no reason to test the larger number during a live customer migration.

When should you run both systems?

Run both when HighLevel is responsible for lead capture, pipeline follow-up, forms, and customer messaging, while Jobber or DripJobs remains responsible for jobs, visits, crews, costing, and operational billing records.

That setup is not automatically safer. It creates overlapping places for contacts, opportunities, invoices, and transactions. Without ownership rules, the office can end up with duplicate customers, mismatched statuses, and conflicting financial records. The solution is not to let both platforms own everything.

Assign one owner to each record type. A lead can start in HighLevel and pass into the operating platform after an agreed pipeline stage. Jobber or DripJobs then owns the resulting job, visits, crew assignments, costs, operational invoice, and field documents. HighLevel keeps the lead source and sales follow-up record. Any integration between them follows those ownership rules instead of copying every editable field both ways.

Write down what happens when a customer changes a phone number, a quote is sold, a job is canceled, an invoice is corrected, or a payment is refunded. HighLevel's historical transaction importer accepts successful completed transactions and orders, but not refunds or voided records. That documented limit matters if the office expects imported financial history to behave like a live accounting record.

This article does not cover the design of the follow-up itself. That belongs in “How to build a fourteen-day follow-up sequence for unsold estimates” and How to track unsold estimates so they don't rot in the system.

When does a full move make sense?

A full move makes sense for a small contractor with simple appointment-based services, few crews, no route-optimization requirement, and no meaningful job-costing process. HighLevel's contacts, opportunities, service calendars, invoices, payment schedules, and historical transaction imports cover a substantial simple-service workflow.

This is the strongest case against keeping two systems. Paying attention to two databases creates work, and a simple operation does not need field-service structures it never uses. If each customer books a straightforward service, staff availability is the main scheduling concern, and profitability is not tracked by connecting labor, material, and expense records to each job, HighLevel can replace enough of the workflow to justify a full move.

The facts that change that answer are concrete. Keep the operating platform when dispatch needs to see jobs and visits separately, crews need assignment history, routes affect the schedule, recurring work uses repeating visits and billing schedules, or the owner relies on live job-profit calculations. Jobber's route optimization covers eligible anytime visits for up to seven days at once as of July 31, 2026. HighLevel service calendars document booking functions, but no retrieved import process recreates that route history.

Remaining on Jobber or DripJobs does not remove the need for controls. Jobber warns that recording a material cost in both line items and expenses can understate margin, and its job-costing report does not report recurring-job costs. DripJobs states that job costing is unavailable in its mobile app. Those limits do not make a full HighLevel migration safer. They mean the retained operating platform still needs a clear process.

What should happen before anything moves?

1. Export real CSV, XLSX, PDF, note, and attachment files from the actual account.
2. List which system will own contacts, leads, jobs, schedules, invoices, payments, documents, and costing.
3. Create the HighLevel pipelines, stages, and custom fields before importing opportunities.
4. Preserve source customer, quote, job, and invoice identifiers in dedicated fields.
5. Keep untouched source exports before cleaning or combining spreadsheets.
6. Run the rehearsal with difficult records and compare every relationship, not just row counts.
7. Test the office's normal searches, corrections, and handoffs before approving the result.
8. Move the remaining data only after the rehearsal passes.
9. Keep the original platform available until the archive, live workflow, and vendor retention rules have been checked.

Book a free consultation - we'll map your data before anything moves.