Every CRM (customer relationship management software — your customer database, follow-up engine, and automation hub) switch starts with optimism and ends, too often, in the same place: duplicate contacts, lost job history, texting consent records gone, and a team that doesn't trust the new system because "half our customers are missing." The data loss isn't bad luck. It's a skipped process. Here's the process.
This is a Hub post in the 8-system framework — the migration discipline that protects Pillar A: Capture Every Lead, Pillar B: Turn Estimates Into Signed Jobs, Pillar C: 5-Star Review Engine, and Pillar D: Full & Calm Calendar, because every system runs on the customer data you're about to move.
Before you migrate: be sure you should
Migrations are expensive in time, risk, and team patience. Validate the decision first:
- The current tool genuinely can't do what you need — not "I haven't configured it," but a real ceiling (see the field-service software native-SMS ceiling guide for the canonical example).
- You've priced the total switch — new subscription, migration time, team retraining, the parallel-run period. The sticker price is the smallest cost.
- You've confirmed the new tool imports what matters — contacts, job history, notes, tags, consent records. Ask the new vendor specifically: "show me a migrated account with history intact." Screenshots, not promises.
- The team is bought in. A migration the team resents becomes a migration the team sabotages by keeping "the real records" in spreadsheets. Involve the daily users in the choice.
If the current tool can do the job with better configuration, that's a weekend project, not a migration. Migrate for ceilings, not for boredom.
Phase 1: export everything (and verify the export)
- Export contacts with ALL fields. Not just name/phone/email — custom fields, tags, source, lead date, notes. The field you skip is the field you'll need in month two.
- Export job/service history. Past jobs, invoices, estimates — the history that powers reactivation (System 7) and tells you who bought what when. If the old tool can't export history cleanly, screenshot or CSV-dump the critical views.
- Export consent and suppression records. This is the one everyone forgets and the one with legal teeth: texting opt-ins with timestamps, email unsubscribes, STOP suppressions. These records are your compliance — losing them means texting people you can't prove consented.
- Export automation definitions. Screenshot or document every active workflow — triggers, messages, timing. You'll rebuild these in the new tool; the screenshots are the blueprint.
- Verify the export. Open the CSVs. Count the rows against the old tool's contact count. Spot-check ten records for completeness. A corrupt export discovered after you've canceled the old tool is unrecoverable.
- Store the raw exports somewhere safe. Cloud drive, dated folder, untouched. This is your rollback parachute — keep it for at least a year.
Phase 2: clean before you move (the highest-ROI phase)
Migration is the only time you'll ever touch every record. Cleaning before import means the new system starts pristine instead of inheriting years of rot:
- Deduplicate. "Mike Smith," "Michael Smith," and "M Smith" with the same phone number are one person. Merge them now — duplicates imported become duplicates automated (two texts to the same customer, the overlap problem from day one).
- Standardize phones. One format for every number (10 digits, consistent country code). Texting tools match and dedupe on phone format — inconsistent formats break matching silently.
- Purge the dead weight. Bounced emails, disconnected numbers, obvious test records ("Test Testerson"), bot-spam contacts from the pre-honeypot era. Don't migrate garbage — it costs sends and skews every metric.
- Fill the critical gaps. Records missing phone numbers can't be texted; records missing consent status can't be marketed to. Tag the gaps honestly ("no phone," "consent unknown") rather than guessing.
- Segment as you clean. Tag by recency (customer 0–12mo, 1–3yr, 3yr+), by value, by trade/service. The cleaned, segmented file imports as an organized database instead of a pile.
Phase 3: map fields to the new tool
Field mapping is where data gets silently lost — a custom field with no destination in the new tool simply doesn't import. Build the map explicitly:
- List every field in the export. All of them, including the custom ones someone added in 2021 and forgot.
- Assign each a destination in the new tool — native field or new custom field. "No destination" is a conscious decision to drop data, not an accident.
- Pay special attention to: consent/opt-in fields (must survive with timestamps), tags and segments (your automation logic keys off these), source fields (where the lead came from — your attribution depends on it), and notes (often stored in a format that imports badly — verify).
- Test-import 50 records first. Import a small batch, inspect every field, fix the mapping, then run the full import. The test batch catches the mapping errors while they're cheap.
Phase 4: the parallel-run safety window (don't skip this)
The parallel run is the migration's seatbelt: both systems live for 2–4 weeks, with the new tool handling daily work and the old tool kept read-only as the reference and fallback.
- New leads go to the new tool only. From day one of the parallel run, all new contacts, jobs, and automations run in the new system. No split-brain — the old tool is history, not an alternative.
- Keep the old tool read-only. Nobody edits the old system; it's the reference library for "what did we have on this customer before the move."
- Run the reconciliation checks weekly. Contact counts match? Recent jobs visible in both? Automations firing correctly in the new tool? Consent records intact? A weekly 20-minute check catches drift early.
- Rebuild automations one by one, tested. Don't bulk-recreate every workflow on day one. Rebuild the critical path first (lead response, reminders), test each with your own number, then move to the next. The automation screenshots from Phase 1 are the blueprint.
- End the parallel run deliberately. After 2–4 clean weeks: export a final backup from the old tool, cancel the subscription, and announce "the old system is gone" to the team. Lingering parallel systems breed split records.
The five things that get lost (watch these specifically)
- Texting consent timestamps. The import maps name/phone/email fine and drops the "opted in 2024-03-15 via website checkbox" field. Without it, your marketing texts lose their proof. Map consent fields explicitly.
- Suppression lists. Unsubscribes and STOP records must migrate as suppressions, not just as contacts. Importing an unsubscribed email as a fresh contact is how you email someone who opted out — a violation.
- Conversation history. Past text/email threads often don't import. Export the critical ones (disputes, promises, custom quotes) as notes on the contact record.
- Automation enrollment state. "Customer X was on Day 7 of the estimate sequence" doesn't transfer. Decide per active sequence: restart, resume manually, or let it lapse — deliberately, not by accident.
- Custom integrations. The Zapier flows, the website webhook, the Facebook lead connector — these point at the old tool and break silently on migration day. Inventory every integration in Phase 1 and repoint each one.
Compliance note
CRM migration is a compliance event, not just a data event: consent records, suppression lists, and opt-out histories must migrate with the contacts they belong to, and the new tool's texting must be 10DLC business-texting registration-registered (carrier registration for texts sent by software; 1–7 day approval, ~$15–$20 in fees) before any automated texting resumes. Never resume marketing texts from the new tool until you've verified consent data survived the import. This post is general information, not legal advice.
Related guides in this series
The migration protects every pillar — Pillar A: Capture Every Lead, Pillar B: Turn Estimates Into Signed Jobs, Pillar C: 5-Star Review Engine, Pillar D: Full & Calm Calendar — because they all run on the data you're moving. Run the overlap audit after migration; new tools always introduce new duplicates.