How to move landscaping customers from spreadsheets to a CRM

How we work: This guide uses current public documentation and does not claim hands-on testing unless stated. Some links may later become affiliate links, at no added cost to you. Rankings are independent of commissions.

The safe way to move landscaping customers from a spreadsheet into a CRM is to preserve the original file, build a property-aware staging copy, map every column, import a small batch, and reconcile it before the CRM sends a message or creates live work. Do not upload the office’s only spreadsheet and hope the importer’s success screen means the records are correct.

Start with these downloads:

• Download the customer and property staging CSV
• Download the source-to-destination field map

The files contain synthetic examples. Replace them with records handled under your company’s data policy. This is a desk-researched migration workflow, not a claim that we imported a company’s customer list or tested a vendor account. The linked Jobber, Yardbook, National Association of Landscape Professionals, and Federal Trade Commission pages were opened and checked on August 9, 2026.

What should you do before changing the spreadsheet?

Make three separate artifacts:

1. Source snapshot: an untouched copy of the current spreadsheet, saved with the extraction date and restricted to people who need it.
2. Staging file: the working copy where fields are split, standardized, reviewed, and assigned migration decisions.
3. Destination import file: a file built from the CRM’s current sample template, containing only columns that the importer accepts.

Do not turn the source snapshot into the staging file. If an address is split incorrectly, a formula is replaced, or a duplicate is merged badly, the original is the evidence needed to reconstruct the record.

Name one migration owner and one reviewer. The owner prepares the files and runs the import. The reviewer compares the result with the source. For a solo operator, these can be the owner and a trusted bookkeeper or office administrator, but the check still needs to be written down.

The National Association of Landscape Professionals gives a useful industry warning. Companies in its software implementation report described exporting customer lists, cleaning data, planning the rollout, training staff, and continuing to adjust after launch. Those examples do not set a universal timeline. They show that upload is one part of implementation, not the whole change.

Before copying customer data into another tool or sending a file to support, confirm the approved transfer method. The FTC’s current small-business guidance recommends limiting sensitive-data access to people who need it, backing up important files, encrypting sensitive data in storage and transit, and deciding how vendors may use, retain, and delete data. A convenient personal inbox or consumer file-sharing link is not automatically an approved migration channel.

Which migration method is safest?

Use the highest-ranked method the destination CRM can support.

This ranking is about control, not product quality. A self-service importer can be suitable when the team understands its matching behavior and can keep the new records quiet. A vendor-assisted import is not automatically safe if nobody has defined which records, fields, and history are in scope.

If the company has not chosen a destination, use the landscaping CRM comparison first. The import plan should follow the product’s real client, property, estimate, job, and invoice model rather than a generic contact-list promise.

How should customers and service properties be modeled?

A landscaping customer is not always one person at one address. A property manager may pay for several sites. A homeowner’s billing address may differ from the service address. Two contacts may share a property, and one contact may request separate work at several properties.

The staging CSV therefore uses separate source_client_id and source_property_id columns. Each service property gets one row. Client fields can repeat only to support a row-based import; the IDs show which rows belong together.

Use this minimum model:

Jobber’s export documentation, checked August 9, says its client CSV can include tags, property addresses, contact information, and custom fields. Its export handles up to 1,500 rows per CSV file and sends multiple attachments above 1,499 clients. That row limit matters when recording source totals: several attachments can represent one export.

Yardbook’s current customer-import guide uses another concrete model. Its headers are case-sensitive, it requires contact_first_name, address_line1, city, and zip_code, and it represents multiple properties for one customer as separate rows with the customer’s name repeated. These are product-specific rules. They are why the neutral staging template must be translated into the vendor’s current template instead of uploaded unchanged.

Our solo landscaper CRM setup explains the client, property, and opportunity records after migration. This article stays focused on getting the existing customer and property data across without silently changing its meaning.

How do you clean the staging CSV without damaging evidence?

Work on a copy and add a review status. Do not overwrite uncertain values with what seems likely.

Which identity fields need review?

Give every source client and property a stable text ID. If the spreadsheet has no IDs, create migration-only IDs such as C-000001 and P-000001; record that they were created for migration. Preserve existing IDs exactly, including leading zeros.

Build duplicate candidates from combinations of:

• normalized email address;
• normalized phone number;
• company or contact name plus billing address;
• service address; and
• an existing customer number.

Then review each candidate. Do not merge automatically because one field matches. Families share email addresses, property managers share office phone numbers, and neighboring properties can have similar addresses. Mark the decision as keep, merge, exclude, or review, with a short reason.

Which contact fields need cleanup?

Split full names only when the source supports the split. Keep a company name separate from a contact name. Put email and phone values in their own columns and flag invalid or ambiguous values rather than inventing a correction.

Keep postal codes and identifiers as text so leading zeros survive spreadsheet editing. Store staging dates as YYYY-MM-DD, then transform them only if the destination’s current import template requires another format.

Do not convert a blank communication-permission field to “yes.” Unknown, yes, and no have different meanings. A migration should preserve what the business actually knows, not create permission by default.

Which landscaping fields need special treatment?

Separate billing and service addresses. Check apartment, unit, gate, and property-name fields for accidental concatenation. Keep route zones and service types in a controlled vocabulary instead of allowing variants such as North, north route, and N Route to become three destination tags.

Do not put gate codes, alarm details, payment data, chemical records, or private notes into a broad client-note field simply because the importer accepts text. Decide whether each belongs in a restricted destination field, a separate approved archive, or outside the import.

The staging template intentionally does not carry passwords, payment-card data, or access codes.

How should every source column be mapped?

Open the field-map download and create one row per source column. Complete these decisions before the pilot:

An empty destination field is not a mapping decision. If a column will not move, say why and where the retained copy will live.

Jobber’s current mass-update guide demonstrates why identifiers and mappings need special care. It warns users not to change the J-ID column because it matches existing records. Its re-import flow maps headings, previews values, and validates names, email format, titles, and J_ID format before import. That validation catches some malformed values; it does not prove that a customer was matched to the intended property or that every source column was preserved.

Use the vendor’s downloaded sample file on the day the destination file is built. Do not copy headers from an old blog post or a previous migration.

What should the pilot import contain?

Use synthetic records first when the product allows them. Include shapes that exercise the data model:

1. one residential client with one property;
2. one company with a named contact;
3. one property manager with two service properties;
4. two legitimate clients who share a phone number;
5. one inactive client;
6. one client with a tag containing more than one value; and
7. one source column intentionally assigned to the archive.

Confirm field mapping, duplicate behavior, multi-property relationships, and the export path. Remove or clearly label synthetic records before live work.

For the live pilot, use the smallest approved batch that exercises the same shapes. Record:

• the source file name and extraction date;
• source client and property counts;
• the exact destination template version or download date;
• the import operator and start time;
• the batch label, tag, or other supported identifier;
• validation warnings and rejected rows; and
• every manual change made after upload.

Keep marketing messages, quote reminders, invoice reminders, review requests, and other outbound automations disabled for imported records. A test import must not contact a customer.

How do you prove the import worked?

An accepted file is only a transport result. Reconcile the records and the workflow.

Open the CRM records individually and in a destination export. A dashboard count can hide a property attached to the wrong customer. An export can reveal that a displayed value is not available through the exit path.

Yardbook’s export guide, checked August 9, names CSV downloads for customers, expenses, payments, chemical tracking, and invoices. It does not establish that one customer CSV contains every operational record. Treat customer import and full business-history migration as different scopes.

For a broader source-of-truth and handoff inventory, use the landscaping software stack audit template. It helps identify which system owns invoices, payments, jobs, files, and other records that a contact import may leave behind.

What is the rollback plan before the full import?

Do not assume the CRM has an undo button. Ask the vendor what can be reversed, who can reverse it, how matching existing records changes the answer, and whether deleting a client also deletes related properties or work.

Write the rollback plan before the pilot:

1. Keep the source spreadsheet authoritative until reconciliation is signed.
2. Freeze source edits during each export-and-import window, or log every change that occurs after extraction.
3. Keep outbound CRM automations disabled for imported records.
4. Identify the imported batch using a vendor-supported tag, batch record, or documented list of destination IDs.
5. Define the stop conditions, including unexpected merges, wrong property relationships, unexplained record-count differences, or customer contact.
6. Record the vendor-approved isolation or removal process. Do not improvise bulk deletion.
7. Restore normal source editing if the batch is rejected and record any changes that must be replayed.
8. Retain the source snapshot, staging file, destination file, field map, exception log, and reconciliation result under the company’s retention and access rules.

Rollback may mean abandoning an isolated target account or leaving a rejected batch inactive while support removes it. It does not necessarily mean deleting records yourself. If the destination cannot isolate a pilot, identify an import batch, or explain deletion effects, resolve that gap before sending the full customer list.

When can the CRM become the source of truth?

Cut over only when:

• the full import has the same mapping and controls as the accepted pilot;
• client and property counts reconcile;
• sampled fields and every multi-property relationship pass review;
• rejected and unsupported records have owners;
• required history remains available in an approved archive or destination;
• the destination export has been opened and checked;
• staff know where to update each field;
• integrations and automations have separate test plans; and
• the owner and reviewer sign the reconciliation.

Then record a cutover time. Changes before that time belong in the spreadsheet; changes after it belong in the CRM. Keep the old file read-only according to the company’s retention policy instead of allowing two editable customer masters.

The migration is complete when the business can find each customer and service property, explain every excluded field, recover the retained source, and run the next real workflow without relying on a hidden spreadsheet. Upload completion by itself is not the finish line.