That answer changes if reporting depends on source, owner, stage, or product line, because those fields have to survive the move intact. A light migration fits solo operators and small teams with one pipeline. Shared inboxes, service cases, and multi-step automations require stricter validation before cutover.
What to Prioritize First
Start with active records, not total records. Open deals, current contacts, and live tasks belong in phase 1 because they support revenue and follow-up.
Use this table to decide what stays in the first move.
| Record type | Phase 1? | Why it belongs here | Trade-off |
|---|---|---|---|
| Active contacts | Yes | Supports current follow-up and segmentation | Requires duplicate cleanup |
| Open deals | Yes | Protects pipeline continuity and forecast views | Stage mapping takes time |
| Current tasks and activities | Yes | Preserves handoffs | Sync rules need QA |
| Custom fields tied to reports | Yes | Prevents broken dashboards | Increases mapping burden |
| Closed-lost records older than 12 months | No | Low operational value | Keep in archive or read-only system |
| Legacy tags and test data | No | Adds clutter | Delete after export validation |
| Attachments for unresolved cases | Yes | Preserves context | Raises storage and file review load |
Rule of thumb: if a field does not feed a report, route a lead, or drive a task, leave it out of the first move. Every extra custom field adds mapping work, user training, and future cleanup. That hidden admin footprint matters more than raw record count for a small team.
What to Compare
Compare the source CRM and the target CRM by data model, not by brand language. A field named status in one system and stage in another is not a match unless the values and reporting rules line up.
Focus on these comparisons:
- Ownership rules, because tasks and follow-ups break when the assignee logic changes.
- Required fields, because a blank value in the old system becomes an import failure in the new one.
- Picklists and stages, because reporting drifts when one CRM has more steps than the other.
- Activity history and notes, because timeline data gives context that contact rows do not.
- Attachments and file links, because file storage and search order change with the new structure.
- Integrations and automations, because email, calendar, forms, and accounting sync rules rarely transfer cleanly.
- Permissions and audit trail, because a shared setup needs more than a contact export.
Ownership mismatches break follow-up faster than missing contact names. The export looks clean until a task lands without an assignee or a deal lands in the wrong stage, and then your first month of reporting starts with manual repair.
The Trade-Off to Weigh
Simplicity lowers risk. Capability preserves context. Small businesses feel this tension most when the old CRM has accumulated fields no one edits but everyone still has to map.
Most guides recommend moving every field. That is wrong for small teams, because any field without an owner becomes maintenance debt. It clutters search, complicates imports, and creates blank dashboards that nobody trusts.
Use this split:
- Keep fields tied to revenue, service, or compliance.
- Drop fields that only mirror old internal habits.
- Preserve attachments only for active accounts, unresolved cases, or legal records.
- Keep the old CRM read-only if the new system does not need the full history on day one.
Attachment storage is part of the trade-off. A file-heavy archive adds storage and search footprint, then slows users who need a clean daily view. The space cost shows up in admin time long after the import finishes.
The First Filter for Crm Migration Checklist For Small Business
Sort the export into 4 buckets before mapping anything. This first filter prevents the common mistake of treating every record as equally valuable.
| Bucket | What goes in | What happens next |
|---|---|---|
| Migrate now | Active contacts, open deals, current tasks, unresolved cases | Goes through full field mapping and test import |
| Migrate next | Recent closed deals, notes tied to active accounts, recent account history | Moves after core workflow validation |
| Archive separately | Closed-lost history, dormant contacts, old attachments, inactive campaigns | Stored outside the daily workflow or kept read-only |
| Delete | Duplicates, test records, obsolete campaign entries | Removed after export validation |
A record with no active owner, no open task, and no current revenue value belongs in archive unless a retention rule says otherwise. If more than one-third of the export sits in archive or delete, the project is data hygiene first and migration second.
Most migration failures come from record selection, not import buttons. The cleanest import still fails if the team moves stale data into a new workflow and calls it progress.
The Use-Case Map
The right scope changes with workflow density. A solo operator does not need the same history depth as a service team with recurring accounts and shared assignments.
| Setup | Migrate first | Delay | Main trade-off |
|---|---|---|---|
| Solo operator | Active contacts, open tasks, recent notes | Old tags, stale leads, duplicate archives | Less searchable history, faster daily use |
| Office manager or admin | Ownership, permissions, shared inbox history | Dead leads and obsolete campaign data | More QA on roles, fewer assignment errors |
| Sales team | Pipeline stages, source fields, closed-won and closed-lost totals | Old workflows that no one uses | Stage mapping takes time, reporting stays intact |
| Service-heavy team | Case IDs, SLA dates, attachments tied to open work | Closed ticket archives | File migration slows cutover, service context survives |
The mistake here is copying the old structure just because it exists. New CRM defaults should reflect how work moves now, not how the old system labeled it.
Constraints You Should Check
Check these constraints before you commit. They decide whether migration is a one-week cleanup or a multi-stage project.
- Every required field in the new CRM needs a source value or a default.
- More than 10 custom fields on the core object demands a written field map.
- Large attachment or email archives need a separate file plan, not a last-minute upload.
- Old IDs need a cross-reference file if the sales or service team uses external records.
- Calendar, email, form, bookkeeping, and support integrations need reconnect testing.
- Permissions and audit trail rules need validation, because role hierarchy does not move cleanly by default.
Do not assume notes and tasks transfer with the same fidelity as contacts. Those records carry chronology, and chronology breaks first when sync rules are loose. A field-level pass is not enough when the team relies on a timeline for handoffs.
Storage matters here in a practical way. File-heavy archives add storage, but they also add search space and admin time, which is the part that small teams feel first.
When Another Path Makes More Sense
A fresh start makes more sense when the source CRM is dirty and the team does not depend on its history for forecasts or compliance.
Choose a different route in these cases:
- Start fresh when duplicates, stale campaigns, and unused fields dominate the export.
- Preserve full history when renewals, long sales cycles, or legal holds depend on it.
- Use phased migration when two or more teams share the same account record.
- Keep the old CRM read-only when lookups continue after cutover.
A fresh start loses old search history. That trade-off is rational only when the old system blocks adoption or turns every update into cleanup work. A full-history move with no reporting need creates more admin burden than value.
Decision Checklist
Use this checklist before cutover. If any item stays open, the move is not ready.
Minimum standard
- Active records are separated from archive records.
- Every custom field that matters has a source value.
- Duplicate rules are defined before import.
- A 25 to 50 record test import passes without manual fixes.
- Open deal totals match between old and new systems.
Higher standard
- Owner assignments are verified for leads, contacts, deals, and tasks.
- Attachment scope is defined by business value, not by habit.
- Integrations are retested in the new CRM.
- The old CRM is set to read-only.
- The first reporting cycle review is on the calendar.
Treat this as a go-no-go gate. A migration that passes the import but fails the checklist still creates a support burden after launch.
Common Mistakes to Avoid
Most guides recommend a one-shot full import. That is wrong for small businesses with messy source data, because it moves old confusion into a new interface and calls it progress.
Watch for these mistakes:
- Migrating every note and attachment. Old clutter survives in the new search layer, and users stop trusting the timeline.
- Keeping old stage names unchanged. Users follow labels, not history, so stale naming creates reporting drift.
- Treating duplicate cleanup as a one-time task. Inbox sync and manual entry create new duplicates after go-live.
- Ignoring import error logs. Failed rows point to the mapping rule that breaks the rest.
- Cutting over before one reporting cycle. Dashboard drift hides until month-end, then the team spends time reconciling totals.
- Skipping a rollback plan. Parallel edits without a fallback create mismatched ownership and lost notes.
The common thread is maintenance. A CRM migration does not end at import. It shifts the maintenance burden into the new system, and the team feels that cost every week.
The Practical Answer
The sensible move for most small businesses is a lean migration: active contacts, open deals, current tasks, and the fields tied to reporting or routing.
Leave stale records, obsolete tags, and duplicate archives outside phase 1 unless compliance or forecasting needs them. Keep the old CRM read-only until the first reporting cycle closes and the team stops reaching back for old references.
Smaller teams win with simpler scope. Shared workflows win with stronger history preservation. The right checklist follows that split instead of trying to preserve everything by default.
Frequently Asked Questions
Should a small business migrate every record into the new CRM?
No. Move active records and history tied to revenue, service, or compliance. Archive the rest outside the daily workflow.
What breaks a CRM migration fastest?
Ownership, custom fields, and duplicate rules break it fastest. Contact names import cleanly while tasks, stages, and permissions drift.
How many records should the test import use?
Use 25 to 50 records from one real workflow, not a random sample. That size exposes mapping and permission errors without turning the test into a second migration.
Should the old CRM stay open after cutover?
Yes, in read-only mode, until the first reporting cycle ends and the team stops needing old references.
What if the export is mostly old or unused data?
Use an archive-first plan. Move only the records tied to current work, then keep the rest in a separate export or read-only archive.