Landscaping software migration checklist: four-week plan

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.

Migrate landscaping software in dependency order, prove a small import, run one controlled shadow cycle, and cut over only after operational and financial reconciliation passes. Keep one system authoritative for each live workflow, and define rollback triggers before the first production import.

Download the four-week landscaping software migration checklist. It is a spreadsheet-ready control log with example rows to replace. Do not enter passwords, API keys, payment credentials, private customer documents, or recovery codes.

This is a desk-researched implementation framework, not a report of a live software migration. Official Jobber and Aspire documentation and independent trade guidance from the National Association of Landscape Professionals were opened and checked on September 8, 2026. The four-week sequence is a reference for a small landscaping operation. Extend it whenever the vendor’s implementation process, data volume, season, training load, or a failed gate requires more time.

What is different from a client-list migration?

A client import moves names and addresses. An operating-system migration also has to preserve the relationships that make work possible:

client → service property → contract → recurring schedule → visit → crew time → invoice → payment → ledger

Jobber’s current client importer illustrates the boundary. It accepts a documented set of client and property fields from CSV, TSV, or PSV files under 2.5 MB. It can create multiple properties from repeated client rows, and it imports text-based client custom fields. That page does not claim that the same client import moves active contracts, visits, invoices, payments, files, or full custom-field behavior.

The spreadsheet-to-CRM migration guide covers client and property cleanup in depth. This checklist starts where that narrower job stops: active work, recurring service, estimating, field use, accounting, integrations, permissions, training, cutover, and recovery.

Which records belong in the migration scope?

Inventory every domain before deciding what to import, rebuild, archive, or leave behind.

Aspire’s current vendor guidance names six migration domains for its own platform: properties, contacts, item catalogs, active contracts, kits and assemblies, and open opportunities. That is a useful landscaping-specific scope prompt, not proof that another product imports the same domains. Ask each vendor for a written import/export matrix and inspect the actual template.

What should be imported, rebuilt, or archived?

Use one decision per domain:

Do not use age alone. An old signed contract, chemical record, customer authorization, invoice, photo, or crew-time correction may still have an operational or retention requirement. Obtain qualified advice for legal, payroll, tax, pesticide, privacy, and contract records.

How does the four-week migration plan work?

Each week ends with a decision gate. A calendar date never outranks the gate.

Week 1: How do you scope and protect the source?

Goal: know what exists, who owns it, and what the target can actually accept.

1. Name the migration lead, operational owners, accounting owner, vendor contact, trainers, cutover decision owner, and rollback decision owner.
2. Declare the current authoritative system for clients, properties, schedules, time, estimates, invoices, payments, payroll handoff, and accounting.
3. Inventory record domains, counts, date ranges, attachments, integrations, devices, user roles, reports, and retention requirements.
4. Request the target’s current templates, field limits, import order, unsupported records, permissions, duplicate behavior, reversal path, and vendor lead time.
5. Export the source data and open every file. Keep the untouched baseline separate from working copies.
6. Build the field and relationship map. Mark every unsupported field as rebuild, archive, approved workaround, or blocker.
7. Define acceptance thresholds and rollback triggers before editing live configuration.
8. Test a partial recovery of critical files and document how the company would operate if either platform were unavailable.

Jobber’s current export documentation is a reminder to inspect mechanics, not just click a button. Its client export can arrive in multiple emailed CSV files when the list exceeds 1,499 clients. A count of downloaded files is not a record reconciliation, and a client export is not a full account backup.

CISA recommends inventorying critical data, keeping separate backups, and performing scheduled recovery tests. Its small-business guidance specifically calls for testing full and partial restoration and maintaining the ability to roll back data. Apply those controls to approved exports and configuration evidence; do not assume a SaaS export can restore the SaaS account itself.

Week 1 gate: source exports open, critical domains and relationships are mapped, unsupported records have owners, recovery was tested, and the target import order is documented.

Week 2: How do you configure and test a pilot import?

Goal: prove the target model with synthetic data and a small controlled subset.

1. Configure branches, teams, roles, service codes, units, tax rules, cost codes, invoice settings, accounting mappings, and required custom fields before dependent records.
2. Create synthetic records for a residential client, a multi-property commercial client, recurring maintenance, a project estimate, a credit, a failed sync, and each permission role.
3. Run the target’s import validation with the smallest reversible or isolated subset available.
4. Import one controlled live client only after synthetic tests pass and the handling of personal data is approved.
5. Compare every imported field, relationship, status, date, total, note, and attachment against the source.
6. Export the pilot back out of the target and open it independently.
7. Correct the map and repeat from a clean pilot state under the vendor’s documented process.

Never use a full live import as the first test. Jobber’s importer previews field mapping and invalid rows before import; use those checks, then inspect the resulting records. A green import message proves that rows were accepted, not that contracts, schedules, balances, or workflows are correct.

Week 2 gate: synthetic workflows pass, the controlled subset reconciles, target export is usable, permissions are approved, and no critical field is silently dropped.

Week 3: What does a safe parallel run look like?

Goal: compare one representative cycle without creating two operational authorities.

Choose one maintenance crew, one project or enhancement workflow where relevant, a small set of properties, and a complete billing cycle. The old system can remain authoritative while the new system shadows the work. Label shadow records so they cannot send customer messages, dispatch a second crew, post a live invoice, collect payment, trigger payroll, or sync to accounting.

Run these comparisons:

• route and schedule date, sequence, assigned crew, recurrence, and exception;
• field access, instructions, time, notes, photos, quantities, and completion;
• estimate line items, units, costs, price, tax, approval, and revision;
• invoice trigger, line items, credits, balance, payment, and customer status;
• payroll and job-cost hours;
• accounting item, customer, class or location, tax, receivable, payment, and deposit;
• notifications and automation stop conditions; and
• manager reports and exports.

NALP’s independent implementation guidance recommends phased rollout with specific teams, role-specific procedures, internal product masters, and a project lead. Its newer process reporting goes further: involve field teams, pressure-test the process, begin with a small pilot, and verify in smaller groups before scaling.

Week 3 gate: the shadow cycle matches the authoritative results or every variance has an approved explanation and control. Crew members can demonstrate their roles without relying on an administrator.

Week 4: How do you cut over and stabilize?

Goal: move authority once, reconcile the delta, and support users closely.

1. Announce the stop-write time, cutover window, support route, and rollback owner.
2. Pause nonessential source changes and capture the final delta since the baseline export.
3. Import or rebuild the approved delta in dependency order.
4. Reconcile active clients and properties, today’s work, future recurrence, open estimates and jobs, unbilled work, receivables, unapplied payments, credits, and accounting balances.
5. Switch one intake path, form, payment flow, integration, and automation at a time. Disable the old path only after the new one passes.
6. Make the target authoritative at the recorded time. Keep the old system read-only under the approved retention and contract plan.
7. Review schedules, crew time, completion, invoices, payments, sync errors, permissions, and customer messages daily during hypercare.
8. Keep an exception log with owner, severity, workaround, due time, evidence, and closure test.
9. Remove old integrations and access only after retention, export, and rollback requirements are satisfied.

Go-live starts the support period; it does not finish implementation. NALP’s trade reporting recommends continued training, feedback, process checks, and adoption review after launch.

Week 4 gate: live work is complete and singular, financial records reconcile, critical exceptions are closed or controlled, users can perform their roles, and the rollback window can close under the written rule.

How should source and target data be reconciled?

Use four layers. A single total can conceal a broken property link or a duplicate visit.

1. Reconcile populations

For each domain:

unexplained count difference = source in-scope count - target accepted count - approved exclusions

The result should be zero. Keep rejected rows and exclusions visible rather than deleting them from the denominator.

2. Reconcile controlled totals

Compare values that matter to operations and accounting:

• active contract value by billing rule;
• budget labor-hours and production quantities;
• unbilled completed work;
• open invoice balance;
• customer credits and unapplied payments;
• tax by reviewed jurisdiction;
• approved crew hours by pay period; and
• job-cost labor, material, equipment, and subcontractor totals.

Do not invent a tolerance. Accounting amounts may require exact agreement, while an address-cleanup review may use a different written rule. Name the owner who approves each threshold.

3. Reconcile relationships

Sample simple, edge, and high-impact records:

• a client with separate billing and service addresses;
• one client with multiple properties;
• a property with seasonal and year-round services;
• a contract with an exception or renewal;
• an estimate with options, deposit, or change;
• a job with notes, files, and several workers;
• an invoice with tax, credit, or partial payment; and
• a record corrected after the baseline export.

4. Reconcile workflows

Prove that the target can create, change, fail, recover, report, and export the record. The offline field-software test adds disconnect, queued-write, conflict, reconnect, and recovery cases for crews working with unreliable service.

What must pass before cutover?

Use controlled data and expected outcomes. These are proposed tests, not claims about any product tested for this article.

The software stack audit template can identify source-of-truth records, handoffs, renewal controls, administrators, exports, and access before the project begins.

What should trigger rollback?

Approve triggers in advance. Examples include:

• today’s or the next critical cycle’s work is missing, duplicated, or assigned incorrectly;
• active contract scope, recurrence, price, or billing rule cannot be proved;
• open receivables, credits, payments, tax, payroll, or ledger totals do not reconcile;
• field users cannot access required work or can access restricted financial, payroll, or configuration functions;
• customer notifications, invoices, payments, payroll, or integrations fire twice;
• a required export, attachment, audit trail, or recovery procedure fails; or
• a critical exception exceeds its approved response window.

Rollback does not mean deleting evidence or improvising another import.

1. Stop new target writes and automated outbound actions safely.
2. Record the decision time and preserve logs, rejected rows, and changed records.
3. Restore the designated source as authority for the affected workflows.
4. Reconcile every legitimate change made after the final source export.
5. Tell staff which schedule, invoice, and communication path controls.
6. Validate the restored workflow with the acceptance plan.
7. Correct the cause in an isolated or vendor-approved environment before another cutover.

Keep customer and employee data in approved systems throughout the process. Restrict exports, use approved transfer methods, remove temporary access, and follow the company’s retention and deletion rules.

Who signs off on the migration?

Do not give one administrator every approval.

The migration is complete when the new workflow is trusted, the financial handoff reconciles, users can perform their roles, and the old system has an approved archive and closure plan. A successful login or imported row count is only the beginning.

For this site’s desk-research and correction standards, read the editorial policy.