Short answer: document the business problem, the current workflow, the required outcomes, and the exceptions that matter. You do not need a finished technical specification, but you should give prospective implementers enough detail to distinguish a real solution from a generic software pitch.

A useful preparation packet can be only a few pages. Include these six sections:

1. The decision you are trying to make

State whether you are evaluating a new CRM, improving an existing system, automating a handoff, replacing spreadsheets, or integrating two platforms. Name the decision deadline and who will approve the work.

1. The current workflow

Describe where the process starts, each major step, who owns it, which systems are used, and where work commonly waits or gets re-entered. A simple numbered list is often more useful than polished diagrams. Include one representative example using fictional or redacted data.

1. The required outcome

Define what must be better in observable terms. Examples include one accountable owner per request, fewer duplicate records, visible failure queues, consistent approval history, or a reliable way to report status. Avoid prescribing a feature before explaining the operational result it must support.

1. Users, roles, and permissions

List the people who create, review, approve, assign, complete, and report on the work. Note what each role must see or change. This prevents an estimate built around administrator access while overlooking daily users.

1. Data and integrations

Identify the important records, their current sources, required fields, approximate data condition, and any systems that must exchange information. For every integration, describe the direction of data, trigger, timing expectation, and which system should be authoritative.

1. Exceptions and constraints

Document the cases that do not follow the happy path: duplicates, missing information, cancellations, reassignment, offline work, failed payments, unavailable APIs, or records that require manual review. Also disclose security requirements, retention rules, budget boundaries, internal technical capacity, and dates that cannot move.

Ask every proposer to separate assumptions, standard configuration, custom work, integrations, migration, testing, training, ongoing ownership, and out-of-scope items. Require them to explain how failures are detected and recovered, not only how the normal path works.

You do not need to choose the software first. In fact, documenting the workflow before selecting a platform makes it easier to compare options against the same needs and exposes where process decisions—not technology—are still unresolved.

Which part of your current workflow would be hardest to explain accurately to an implementation partner?

Treat CRM migration as a business-decision project, not a bulk copy. The safest goal is not “move every record.” It is “move the records people need, in a structure they understand, with enough traceability to trust the new system.”

Start with these six decisions:

1. Define what must move. Separate active customers, open opportunities, current contacts, required historical records, and data that can remain in a read-only archive. Keeping everything often preserves duplicates, obsolete fields, and unclear ownership.
2. Assign an owner to each data set. Sales should decide what makes an opportunity active. Finance should confirm which account identifiers matter. Operations should define the customer and job details needed after handoff. A technical team can map fields, but it should not invent business definitions.
3. Create a field-level mapping. For every source field, document the destination field, data type, allowed values, transformation rule, and what happens when the value is blank or invalid. Mark fields that will be retired. This catches ambiguity before import day.
4. Clean by rule, not by intuition. Agree on repeatable rules for duplicate contacts, inconsistent company names, stale statuses, malformed email addresses, and records without owners. Preserve original IDs so questionable records can be traced back to the source.
5. Rehearse with a representative sample. Include ordinary records and difficult cases: multiple contacts at one company, closed and reopened opportunities, missing values, unusually long notes, and records connected to several objects. Have actual users check search, ownership, timelines, reports, and downstream handoffs.
6. Reconcile after each test import. Compare source and destination counts by record type and status, then investigate differences. Spot-check key fields and relationships. “The import finished” is not the same as “the migration is correct.”

Before the final cutover, write down the freeze window, final export time, import sequence, validation owners, rollback threshold, and how changes made during the freeze will be handled. After launch, keep the old system read-only for an agreed period instead of immediately deleting access.

One practical test: ask a salesperson to find an active account, understand its recent history, identify the next action, and hand it to operations. If that flow is confusing in the migrated sample, more mapping work is needed before go-live.

This community is support by Hexagon IT Solutions

Which part of CRM migration has created the most uncertainty for your team: deciding what to keep, cleaning it, mapping it, or validating the result?