Switching from Housecall Pro without losing context

Switching field-service software should not mean abandoning the history that makes your business understandable. Customer relationships, service locations, completed work, estimates, invoices, and catalog information are not clutter. They are the context your office needs on day one.

Local Business Pro now includes a controlled Housecall Pro ZIP-import path for eligible businesses. It is designed to bring supported operational history into Local Business Pro with review points, source-aware decisions, dry runs, and visible outcomes—not with a “click once and hope” migration promise.

The rollout is intentionally gated. The import is not enabled for every account by default; it requires explicit canary-business access while the migration lane is introduced. That restraint is deliberate. A business’s history is too valuable to treat as a casual upload.

What the Housecall Pro import is built to bring over

The import workflow is designed around the records an operating team needs to continue the story of its business:

• contacts and service locations;
• jobs and appointments where supported by the export;
• estimates and invoices;
• catalog information; and
• supported review decisions and source context needed to understand the outcome.

That does not mean every file, custom field, legacy exception, or ambiguous relationship can be recreated automatically. The point is more useful: supported records are evaluated as a connected operating set, and uncertainty is surfaced for review instead of quietly turned into a bad record.

If a source relationship is clear, the workflow can preserve that context. If a relationship is missing, contradictory, or needs an operator choice, it should remain visible. A clean-looking migration that silently attaches the wrong invoice to the wrong customer is not a successful migration.

Review the ZIP before you create records

The workflow begins with the Housecall Pro export ZIP and a review of what is inside. Local Business Pro analyzes the supported source files and gives the operator a chance to understand the proposed import before committing it.

That review is where an office can identify questions such as:

• Which customers and locations are represented by the available source identifiers?
• Which records are ready to import, and which need a decision first?
• Are there records that should be skipped rather than duplicated?
• Does the proposed outcome match the business’s expectations for historical work and billing context?

A broader Import & Export workspace already provides the operating pattern: inspect the source, validate the transfer, and review outcomes. The Housecall Pro path applies that discipline to a provider-specific ZIP package rather than asking a team to rebuild the business from a spreadsheet.

Dry-run first. Then use the actual evidence.

Before a live run, the import can be dry-run so the business can review the expected outcome without creating the proposed records. That is the moment to correct a source issue, settle a review decision, or stop the run if the evidence is not strong enough.

Once an authorized live run is started, it is handled as a queued operation with status and history. The office can come back to see what happened rather than relying on a browser tab that had to stay open for the whole process.

The result is intentionally specific. A run can show records that were created, records that were skipped, items that require review, and outcomes that could not be completed. “Finished” is not a synonym for “every row became a perfect record.” It is a readback of what the system was able to establish from the source and the decisions supplied.

Recovery without creating a second version of the business

Long imports need a recovery path. Networks disconnect. A browser gets closed. A source issue can surface halfway through a run. The Housecall Pro workflow keeps queue and history information so authorized operators can inspect the prior result and take the appropriate next step.

That does not mean a failed import should be rerun blindly. Replaying a migration without understanding the previous outcome is how an office ends up with duplicate customers, invoices, or jobs. The workflow is built to retain enough context for an operator to review the previous attempt, correct what needs correction, and use the supported recovery or replay path deliberately.

For teams evaluating other migration options, our Jobber import update explains the same operating principle in a different source format: source identity and visible exceptions matter more than pretending every historical export is pristine.

What this does not promise

The Housecall Pro import is a controlled data-migration tool, not an account takeover button.

• It does not activate itself for every Local Business Pro business.
• It does not guarantee support for every custom Housecall Pro export, field, or historical variation.
• It does not silently invent missing customer, location, job, estimate, or invoice relationships.
• It does not turn historical invoices or payment context into a new payment attempt.
• It does not replace an operator’s responsibility to review the source and make business decisions.

Those boundaries are what make the migration useful. The goal is a business history your team can work from—not a bulk upload that leaves someone else to untangle it later. For the wider August release story, see the home-service operations release roundup.

Who this guided migration is for

This controlled path is for a Housecall Pro team that has a supported ZIP export, can identify an internal owner for the historical records, and is willing to review proposed outcomes before creation. It is not a self-service promise that any export can be uploaded by any account at any time.

Before requesting canary access, prepare a practical switching checklist:

• retain the original export and its source identifiers;
• identify the contacts, locations, jobs, estimates, invoices, and catalog records your team must recognize on day one;
• decide which ambiguous records need an operator decision rather than an assumption; and
• use the dry run to compare the proposed result with the source before authorizing a live queued run.

Teams that want to understand the related ongoing connection can review the Housecall Pro integration setup guide. This release article documents the gated migration workflow; it does not represent a broad comparison page or a universal migration guarantee.

Who should use the controlled rollout

This path is for Housecall Pro businesses that want to move supported operational history into Local Business Pro and are prepared to review a ZIP export with the right internal owner. Because access is being introduced through explicit canary enablement, the first step is to coordinate with the Local Business Pro team rather than assuming the option will already be available in every workspace.

Bring the complete export you intend to review, preserve the source identifiers inside it, and involve the people who know the difference between a historical record that should be retained and a current workflow that needs a new decision. That is how a migration becomes a launchpad instead of a cleanup project.

Frequently asked questions

Is the Housecall Pro import available to every account?

No. The current rollout is gated and requires explicit canary-business enablement. Eligible businesses should coordinate with the Local Business Pro team before planning a migration run.

Can I test the import without creating records?

Yes. The supported workflow includes a dry-run step so the proposed outcome can be reviewed before a live import is started.

What happens if a record is ambiguous or an import is interrupted?

The workflow surfaces reviewable outcomes and keeps queued-run status and history. An authorized operator can inspect the evidence, correct the source or decision where needed, and use the supported recovery path rather than blindly creating another run.

Does importing invoices or payment history charge customers?

No. Historical import context is not a new payment attempt. Payment collection remains a separate, deliberately authorized workflow.