Answer Capsule: Apex Prometheus AI Labs defines a contractor software migration as complete only when the new system preserves stable identities and business relationships, reconciles against the source, survives real office and field workflows, and earns acceptance from named human owners. A green “import complete” notice is not proof that your shop can answer a call, dispatch a crew, document the job, send the invoice, or collect the money.

A contractor software migration can look clean on a laptop and still wreck Monday morning.

The customer list appears. The dashboard says 12,406 records imported. Everybody goes home. Then dispatch opens the new system at 6:15 a.m. and finds three John Smiths, two missing properties, an active Brooklyn project attached to a closed Staten Island estimate, and a technician who cannot see today’s work orders.

That is not a software problem anymore. It is an operating problem with payroll, customer trust, and cash attached.

The contractor’s standard must be tougher: the move is done when the business works.

The Contractor Software Migration Checklist Starts With Authority

Before mapping one column, name the people who own the decisions.

You need an operations owner, a finance owner, an implementation owner, and a records or security reviewer where the scope requires one. You also need one person with final go/no-go authority. “The vendor said it imported” cannot be the final authority for your company.

Then list every source that currently acts like the truth:

  • Field-service software
  • Accounting software
  • CRM records
  • Estimating sheets
  • Dispatch calendars
  • Technician mobile apps
  • Shared drives and document folders
  • Price books
  • Equipment lists
  • Payment references
  • Side spreadsheets that the office quietly depends on

Pick the authoritative source for each business object. Do not declare one system the winner by convenience. A customer may be authoritative in the CRM while invoice balances remain authoritative in accounting. Write the decision down, name its owner, and preserve the source receipt.

Inventory Objects, Not Just Rows

A migration inventory should cover customers, contacts, properties, equipment, estimates, jobs, appointments, service agreements, price-book items, invoices, payment references, documents, notes, users, roles, integrations, and reports.

For every object, record:

  1. Source system
  2. Approximate record count
  3. Stable identifier
  4. Business owner
  5. Sensitivity
  6. Known quality problems
  7. Target destination
  8. Retention status
  9. Decision: migrate, archive, rebuild, exclude, or send for qualified review

Rows alone are cheap. Relationships are where the money lives.

A property record with the correct address is still wrong if it is attached to the wrong customer. A $38,500 exterior repaint can exist in the target and still be useless if its estimate, signed document, production notes, invoices, and payment references are disconnected. A rooftop unit can have every field populated and still send the wrong technician if it is tied to another location.

Preserve stable IDs wherever the platforms allow it. If the target creates new IDs, maintain a controlled crosswalk from source ID to target ID. That crosswalk becomes part of the evidence when someone asks why Job 7842 became Work Order 10931.

Map Fields Before You Clean Anything

Build a mapping register before changing source data. For each field, document the source name, target name, data type, required state, transformation, allowed values, stable ID, parent relationship, duplicate rule, validation check, exception owner, and rollback effect.

Do not “clean up” the only copy until it looks pretty. Preserve the raw export, record its date and file integrity, and work from a controlled copy. Normalize phone numbers, addresses, statuses, and employee names only under an approved rule set.

Ambiguous records belong in quarantine, not the trash.

If two customers share a phone number, automation can flag them as duplicate candidates. It should not merge them on sight. One may be a property manager, the other a building owner. The same warning applies to similar addresses, spouses sharing an email, and commercial accounts with multiple sites.

AI can suggest mappings, spot anomalies, classify notes, and rank duplicate candidates. It does not get final authority over merges, deletions, financial treatment, access, retention, or production writes. Those decisions stay with authorized people.

And keep raw payment credentials, passwords, API secrets, and access tokens out of improvised CSV files. A migration folder is not a vault.

Rehearse With Realistic Work, Not a Toy File

Run representative trial loads before the cutover window. Use synthetic data unless production records are separately authorized and properly controlled.

A useful test set should include:

  • One customer with three properties
  • An active $24,000 project with change orders
  • A recurring maintenance agreement
  • Equipment tied to a service location
  • An unpaid invoice and a partial payment reference
  • Photos and signed documents
  • Two likely duplicate customers that must not be auto-merged
  • An invalid row
  • An unmapped custom field
  • A former employee whose access must stay disabled

Test the ugly work. Anybody can move ten perfect contacts.

Reconcile each trial in layers: file integrity, counts, IDs, relationships, controlled dollar totals, attachments, permissions, integrations, and critical workflows. Record every failed row, correction, retest, reviewer, and decision.

Suppose the source has 12,406 customer records and the target shows 12,401. “Close enough” is not a result. Five records need dispositions. They may be approved exclusions, duplicates held for review, or import failures. Until each difference has an owner and an explanation, the count is open.

The same rule applies to money. If the approved migration scope includes 186 open invoices totaling $742,650, reconcile both the count and the controlled total. That example does not establish a universal migration standard or an Apex result; it shows the level of evidence a finance owner should demand.

Control the Freeze, Final Delta, and Cutover Window

A baseline import goes stale the moment somebody changes the source.

Define the freeze timestamp, the source write state, the target write state, and how work created after the baseline will move. That final change set is the delta migration.

For a Friday-night cutover, write down what happens to every call, reschedule, estimate, site visit, invoice, payment, and technician note created between the baseline export and Monday go-live. “We will catch it later” is not a control.

Consider a six-truck shop that bills about $18,000 on a strong weekday. If broken scheduling, missing notes, and invoice delays cut one day’s completed billing by 25%, $4,500 gets pushed out before counting callbacks or office overtime. That is scenario math, not a promised outcome. It explains why a rollback plan is cheaper than bravado.

Set entrance criteria before the window starts. Examples include:

  • Approved source exports are complete and readable
  • Trial imports passed defined checks
  • Critical exceptions have owners
  • Field and office testers are scheduled
  • Backup and rollback paths are verified
  • Vendor support contacts and escalation windows are confirmed
  • The final decision owner is available

Then set stop conditions. A missing active-job relationship, unexplained financial variance, broken dispatcher access, failed mobile workflow, or uncontrolled duplicate merge may be enough to call no-go. The threshold depends on scope, but it must be decided before pressure hits.

Prove the Shop Can Work After Go-Live

Post-import validation is not a dashboard screenshot. Put named people in the system and make them perform the work.

Have the office create a customer, attach the correct property, schedule a job, move an appointment, send an estimate, locate a signed document, produce an invoice, and find an old note. Have a field user receive the assignment, open the correct location, add notes and photos, record completion, and sync the result. Have finance confirm the approved balances and references within its scope.

Run next-day readback. Check late transactions, failed integrations, permission drift, duplicate candidates, missing attachments, and anything created during the cutover. Keep an exception ledger until each item is corrected, accepted, archived, or escalated.

This is where the trades perspective matters. Apex Prometheus AI Labs uses Churchill Painting Corp as the operating lens: systems must survive real estimates, changing schedules, active jobs, field notes, documents, billing, and crews moving across Staten Island, Brooklyn, and the tri-state area. That is not a claim that Churchill completed this migration or proof of a migration outcome. It is the field standard behind the questions.

The middlemen want the clean screenshot. The contractor needs the business to run.

Do Not Cancel the Old System on Import Day

Keep the legacy platform available until required exports are readable, reconciliation is complete, critical workflows pass, retention and legal-hold questions receive qualified review, rollback needs are closed, and named owners accept retirement.

Contract terms and record duties may require longer access. Export formats may preserve rows but not usable reports, attachments, audit history, or relationships. Test the archive before trusting it.

The vendor selling the new platform wants the subscription started. The vendor holding the old platform wants another renewal. Neither party owns your operational risk. You do.

Do not let a salesperson, importer, or outside consultant turn your shop into a hostage between two dashboards. Demand the source receipts, mapping register, reconciliation results, exception ledger, workflow evidence, rollback criteria, and signed acceptance decision.

That is how builders control a software move instead of letting software control the builders.

Frequently Asked Questions

What contractor data should we migrate?

Start with customers, contacts, properties, equipment, estimates, jobs, appointments, agreements, price-book items, invoices, payment references, documents, notes, users, roles, integrations, and reports. Assign each object a migrate, archive, rebuild, exclude, or qualified-review decision based on business need, source quality, platform capability, contracts, retention duties, privacy, and cost.

How do we avoid duplicate customers during migration?

Choose the authoritative source, preserve stable identifiers, document duplicate-candidate rules, test overlapping imports and integrations, and route ambiguous matches to a named human owner. Never merge records only because names, phone numbers, emails, or addresses look similar.

What is a delta migration?

A delta migration moves records created or changed after the baseline export. It needs an authoritative cutoff timestamp, defined source and target write states, a repeatable method for identifying changes, exception handling, and reconciliation after the final load.

Who approves contractor software go-live?

Name one final go/no-go authority before cutover. Operations, finance, implementation, records, security, and platform owners should approve evidence within their scopes. Technical import completion alone is not business acceptance.

When should we cancel the old contractor software?

Only after required exports are readable, the target passes approved data and workflow tests, open work and financial references reconcile, users and integrations are verified, retention questions are resolved, rollback needs are closed, and named owners approve retirement.

Come see what time it is — apexprometheus.ai