Migrating from Another System

Switching from your current system to Suprata is the kind of project where most of the cost is hidden. The data export is easy. The import is mostly easy. The hard part is the choices you make about what to bring, what to clean up first, what to deliberately leave behind, and how to run both systems in parallel long enough to catch the things you'll inevitably miss. The shops that migrate cleanly do those things deliberately; the shops that don't end up with a Suprata account that has half their data, half their workflows, and a year of sporadic "wait, what happened to that customer's history?" follow-ups.

This article is the migration playbook. It applies whether you're coming from ServiceTitan, Housecall Pro, FieldEdge, QuickBooks-only ("everything's in QB and I do scheduling on a whiteboard"), or Excel. The specifics of the export differ; the order of operations doesn't.

Why a deliberate order matters

The fundamental constraint of any migration is that data has dependencies. Customers must exist before invoices can attach to them. Items must exist before invoices can have line items. Jobs must reference customers and items, so jobs come third. Payments reference invoices, so payments come fourth. Get the order wrong and you spend days fixing orphaned records that point to things that don't yet exist.

Beyond order, there's a strategic question: how much history do you actually want? Migrating five years of closed jobs is a multi-day project for data of marginal forward value. Most shops do better importing the active customer list, the price list, and any open work — and leaving the closed history in the old system as an archive they query occasionally.

This article walks through the order, the strategic choices, and the parallel-running period that catches what slips through.

Step 0 — Decide what's worth migrating

Before you export anything, decide on three buckets:

Bring with full fidelity. Active customers (anyone you've billed in the last 12 months), the current price list, open jobs, open invoices, saved payment methods if your processor supports portability.
Bring as a static archive. Closed jobs older than a year, paid invoices older than a year. These can come in as read-only reference data, or they can stay in the old system as a queryable archive.
Don't bring. Notes that referenced UI features specific to the old system. Custom fields you never used. Tags that didn't earn their keep. Vendor records for vendors you no longer work with. Inactive customers older than two or three years.

The default impulse is to bring everything. Resist it. A clean Suprata setup with the data you actually use is more valuable than a junked-up Suprata setup that mirrors all of your old system's accumulated debris. Migrations are a rare opportunity to clean house. Take it.

Step 1 — Clean the source data

Before exporting, work in the source system. Catch and fix what you can:

Duplicate customers. Merge them in the source if the source has a merge tool, or document the mapping for post-import cleanup.
Inconsistent address formats. "123 Main St" vs. "123 Main Street" vs. "123 Main St." matters when you're trying to dedupe across customers. Pick a canonical form.
Phone number formatting. Same idea. "5551234567" vs. "(555) 123-4567" vs. "555-123-4567" should all become one format.
Bad email addresses. If your source data has 200 customers with "noemail@noemail.com" or your former office's email in the email field, decide whether to import those as blank (and follow up to collect real emails) or carry the placeholders forward.
Customer types. If your old system didn't distinguish residential from commercial, and you have a hodgepodge, take time before export to tag each customer correctly.

This cleanup is the most boring part of the migration and the part that pays back the most. A data-cleaning week before migration saves a data-cleaning month after.

Step 2 — Import accounts and contacts

This is the foundation. Everything else hangs on it.

The accounts list — your destination for the customer import

Suprata's import tools accept CSV. Map your source columns to the Suprata fields:

Account name (organization name for commercial, or contact name for residential).
Account type (residential vs. commercial).
Billing address fields (street, city, state, zip, separately).
Service address(es) if separate.
Phone, email (Account-level main contacts).
Default terms (Net 30, Due on Receipt, etc.).
Default tax category.
Tags to carry forward.

Then a separate Contacts pass importing the people, with:

Name fields (first, last separately — don't put "John Smith" into a single name field).
Title or role.
Personal phone, email.
Account assignment (which Account each Contact attaches to).

Run a small batch first — fifty customers, say — and check the result. Confirm:

Names display correctly (residential vs. commercial logic).
Addresses geocoded (a quick check on a sample).
Tax categories applied.
Contacts attached to the right Accounts.
No duplicates introduced.

Once a small batch looks right, run the full import. See Can I import data from my old system? for the import-tool mechanics.

Step 3 — Import the price list

Your catalog of items, with names, prices, costs, and tax categories.

The integrations and import tools — your tax category and price list mapping live near here

Decisions to make during the price list import:

Skinny or fat? Some shops have hundreds of price-list items, many used once or twice. Others have fifty heavily-used items and the rest is noise. Migration is a chance to skinny down — only import items you've billed in the last 12 months. Anything else can be archived in a spreadsheet for reference.
Tax categories. Each item needs a tax category. If your old system didn't track this cleanly, you'll need to assign at import time. Don't skip — items without tax categories will tax wrong on every invoice they touch. See How tax categories work and Picking the right tax category strategy.
Costs. If you track margins, bring costs over. If you don't, skip — you can add costs later as items move.
Vendor links. If you track which vendor each item comes from, link during import. See Vendors and vendor price books.

See Importing a price list from CSV.

Step 4 — Selectively import history (or don't)

This is the most contested decision in any migration. Three patterns:

Pattern A — Don't migrate history at all

Most aggressive. The cleanest. Your Suprata account starts on day one with current customers and current pricing; everything historical lives in the old system as a read-only archive. When a customer asks "what was the last service I had?", you check the old system for anything before cutover, and Suprata for anything after.

When this works: the old system is queryable, you don't bill ongoing services that depend on history (no recurring contracts mid-cycle), and your team can tolerate "two systems for a while."

When it doesn't: ongoing recurring contracts, mid-period agreements that need to keep billing, customers expecting to see their full history in the customer portal.

Pattern B — Migrate active history only

Middle path. Bring open jobs, open invoices (anything not yet paid), and active service agreements. Leave closed/paid records in the source system. At cutover, every active piece of work is in Suprata; the long tail of closed work is in the archive.

When this works: most shops. Strikes a good balance between clean start and operational continuity.

Implementation note: open invoices need their balance, terms, due date, and customer link. Open jobs need scheduled date, status, customer, location.

Pattern C — Migrate everything

Most thorough. Brings five years of closed jobs, closed invoices, paid history, all of it. Requires more import work and more validation; rewards you with a single source of truth and a customer portal that shows full history.

When this works: you have time and patience, the export from the source is high-fidelity, and the historical view is genuinely valuable for ongoing work.

When it doesn't: if the source's exported data is messy (inconsistent customer references, missing fields, dirty line items), bringing all of it in just imports the mess. You'll spend weeks cleaning up.

The default recommendation is Pattern B. Pattern A if you want a maximally clean start and your old system can stay as an archive. Pattern C only if you have explicit reasons to want full history in Suprata and you've budgeted the effort.

Step 5 — Cut over jobs and scheduling

Pick a cutover date. From that date forward, no new jobs go into the old system; everything new is in Suprata. The week before the cutover, do a dry run with a couple of dummy jobs to make sure your team is comfortable.

On cutover day:

Existing open jobs. Already imported (per the previous step). Continue them in Suprata.
New jobs. All in Suprata.
Old system. Stop scheduling. Stop creating new records. Read-only mode.

Communicate the cutover to your team. Hand them a cheat sheet of "where to find X in Suprata that used to be in [old system]." Walk through the dispatch board, the calendar, the account search, the invoice creation. Twenty minutes of training prevents two weeks of confusion.

Customers don't need to be told about the cutover unless something visibly changes for them (new email format, new payment portal). For most customers, the migration is invisible. Their invoices still come, their appointments still get confirmed, their experience just improves quietly.

Step 6 — Run in parallel for a few weeks

This is the step shops most often skip and most often regret. Keep the old system available for read-only access for at least 30, ideally 60 days after cutover. Two reasons:

Catching gaps. A customer calls about something that happened pre-cutover and you can't find it in Suprata. You check the old system; the data's there. Maybe the migration missed it for some reason; maybe it was in Pattern A's "static archive" bucket and that's expected. Either way you can answer the customer without scrambling.
Validation. Run reports in both systems for the first complete month post-cutover. Numbers should reconcile (allowing for the obvious differences from anything that didn't migrate). If they don't, something is leaking.

Don't extend the parallel period indefinitely. Set a clear sunset: "60 days, then read-only access continues but no daily checking." After 90 days, the old system can be archived to a backup and decommissioned.

What you should expect to lose in translation

No migration is perfectly fidelitous. Things that commonly don't survive:

Custom fields that the old system supported and Suprata doesn't (or vice versa). Capture the data in notes if it's worth keeping.
Free-form notes that referenced features specific to the old system. ("See attached file in HCP message thread.")
Tags and labels that were just informal. Migrate the structured ones; abandon the noise.
File attachments if the export tool didn't include them. Often you can re-upload selectively for active customers.
User-specific preferences (notification settings, dashboard layouts, saved searches).
Email and SMS history in many cases. Threaded conversations don't always export cleanly.
Payment method tokens unless your processor supports portability. New processors usually require re-tokenization on first use.

Document what you knowingly aren't migrating, so you can answer the inevitable "where did X go?" question later.

What can go wrong

Importing dirty data. Garbage in, garbage out. Spend the cleanup week up front.
Skipping the small-batch test. A 1,000-row import that bombs is a much harder problem than a 50-row test that bombs and tells you what to fix.
Not mapping tax categories during the price-list import. Then every invoice taxes wrong until you fix it. Get the tax-category mapping right at import time.
Cutting over without telling the team. Office staff still create jobs in the old system "out of habit" for a week. Now you have data in two places. Hard cutover with announcement and training.
Ending the parallel period too early. Two weeks isn't enough. The questions that surface in week six are the ones that catch you off-guard. Plan for 60 days minimum.
Migrating too much history. Five years of closed jobs nobody ever queries is five days of import work for marginal benefit. Be ruthless about what's worth bringing.
Trying to perfectly preserve the old system's structure in Suprata. Suprata's data model is different from ServiceTitan's, different from HCP's, different from yours-rolled-by-hand. Accept the differences. Force-fitting old structure on new system creates frustration in both directions.
No reconciliation in the first month. Run total revenue in both systems for the first month post-cutover. Numbers should agree (within whatever tolerance you can explain). Discrepancies caught now are fixable; caught in October, they're forensic.

A pragmatic timeline

For a small-to-medium shop migrating from ServiceTitan or Housecall Pro:

Weeks -4 to -2: Source-data cleanup. Decide what to bring.
Week -2: Import accounts and contacts. Validate.
Week -1: Import price list. Validate. Import open work and active history (Pattern B). Train the team.
Cutover day: New work in Suprata. Old system goes read-only.
Weeks +1 to +4: Run in parallel. Reconcile reports.
Weeks +5 to +8: Phase out parallel use. Begin archive prep.
Week +12: Decommission old system to backup.

Larger or more complex shops add weeks at each phase. Solo operations or whiteboard-and-Excel shops can compress the whole thing into a week or two.