A CRM Migration Field Inventory That Makes Exclusions Reviewable

A CRM migration field inventory is a decision log for the fields in the old system. It answers which fields still serve a business process, which can be left behind, and which need investigation before anyone writes a transformation rule. Build it from a source export or schema, then review it with the people who use the data. The useful output is not a spreadsheet containing every column. It is an approved disposition for each field in scope, with evidence and an owner for unresolved cases.

This step comes before the detailed CRM data-mapping specification. A map explains how a field moves. An inventory decides whether it should move at all. Keeping those decisions separate prevents a tidy technical map from becoming an accidental promise to carry years of unused fields into the new CRM.

Set the inventory boundary

Agree which source systems and objects the migration covers. A sales CRM might contain contacts, companies, deals, activities, custom objects, and attachments. The destination may use different object names. List the objects first, but do not assume every object belongs in the same release. A historical support table, for example, may need a separate retention decision even when the sales team wants its contact records migrated now.

For each source object, obtain a field list from an authorized export, schema view, or administrator. Ask for active forms, automation rules, integration mappings, reports, and user views that reference those fields. A field absent from the main user interface might still drive routing or a monthly report. Conversely, a field visible on a form may be obsolete because nobody uses the result. Record where each claim came from so a reviewer can check it.

Use approved access and sample data. Field names and metadata are often enough for the first pass. If the team needs to inspect values, ask the client how samples may be transferred and stored. Do not paste real customer records into an ad hoc working document simply to resolve a column label.

Use one row per source field

The worksheet below is deliberately smaller than a final mapping document. Its purpose is to make the keep-or-leave decision possible. Add columns only when a real review question requires them.

Column	What to record
Source object and field	Exact technical name, display label, and source environment or export version.
Observed use	The form, report, workflow, integration, team task, or retention need that relies on the field. Include a link or named owner.
Value profile	A small approved sample or summary of blanks, formats, option values, and obvious inconsistencies. Do not copy sensitive values into the inventory.
Proposed disposition	Migrate, transform, combine, archive outside the active CRM, exclude, or investigate.
Reason	The business use and evidence supporting the proposal, including what would break if the field is omitted.
Decision owner and status	Who can approve the decision, whether they have approved it, and what question remains open.
Follow-on work	Mapping, cleansing, permission review, test case, or separate scope item created by the decision.

Keep the original technical name even when labels differ. Two fields both called “Source” may mean initial campaign and most recent lead source. A reviewer cannot safely merge them on the basis of the label. The value profile is a clue, not proof of meaning: a mostly blank field might still be essential for the few records that reach a specialist team.

Assign dispositions with evidence

Migrate a field when a named process, report, or user needs the value in the destination and the client approves that use. Transform when the meaning is stable but the representation must change, such as a legacy option code becoming a reviewed destination value. Combine only when the source fields genuinely describe one destination concept; record the precedence rule and what happens when they disagree.

Archive when the value must remain accessible under the client's chosen retention process but does not belong in everyday CRM screens or automation. Archiving needs an owner, retrieval method, and access decision. It does not mean “leave a CSV on someone's laptop.” Exclude when the field has no agreed use and no approved retention requirement in the new system. Record the approver and the location of the source record or backup according to the client's process. Investigate when the meaning or dependency is unknown. A blank approval cell is not a decision.

Consider a fictional legacy contact field named interest_code. The sales team says it drives follow-up, but an administrator finds that the only automation using it was disabled. A report still groups contacts by the code. The inventory row should say “investigate,” link the report and disabled rule, and name the sales owner who will decide whether the report remains needed. It should not immediately map the codes to a new dropdown. Once the report decision is made, the row can become “transform” with a separate mapping task or “archive” with a retrieval plan.

Resolve conflicts before mapping

Review contested fields in a short session with a business owner and someone who understands the source configuration. Show the proposed disposition, evidence, and consequence of being wrong. Ask what decision would be made if the field were absent next month. If the answer depends on another team, assign a question to that team and leave the row open. A consultancy can recommend a technical path, but the client must decide business meaning and permissible use.

Pay particular attention to free-text notes, old identifiers, consent or communication-preference fields, and values copied from another system. These can have hidden dependencies or access implications. Do not claim that copying or dropping them establishes legal compliance. Ask the client to apply its own policy and bring the right owner into the decision.

When scope is tight, prioritize the fields that drive live workflows, customer-facing communication, routing, and required reports. A low-use historical field can be deferred with an explicit disposition. If a field blocks a launch-critical process, record it as a dependency with a decision date. This makes the trade-off visible instead of letting the import script silently decide.

Turn the inventory into a controlled migration plan

Freeze a reviewed version before building the sample migration. For every approved “migrate,” “transform,” or “combine” row, create or link the detailed mapping rule: destination, data type, allowed values, blank behavior, ownership, and validation. For archived and excluded rows, record how the decision will be checked. For open rows, state whether the project can proceed without them and what would trigger a scope change.

A practical review checklist is:

1. Every in-scope source field has a disposition, including custom and integration-created fields.
2. Each field proposed for migration has a named use or documented retention need.
3. Every exclusion and archive decision has an owner and a reason a client can review.
4. Unknown meanings and conflicting dependencies are marked open, not guessed.
5. Source labels, technical names, and export versions are preserved so decisions can be traced.
6. The fields that feed forms, reports, automations, and integrations have been cross-checked with those systems.
7. The next mapping and test tasks are linked to the inventory version they rely on.

For the sample load, choose a few records that exercise kept fields, blank values, old option codes, and a deliberately excluded field. Inspect the destination record and the report or workflow that uses it. The excluded field should not appear unexpectedly, and required operational values should retain their intended meaning. A successful import message alone does not establish either condition.

Hand over the decisions, not just the file

Give the client the reviewed inventory, approval record, open-decision list, and links to the mapping and test evidence. Explain where archived values can be found under the client's process and who handles a later request to restore one. If a field is reintroduced after sign-off, update the inventory and test the affected mapping, reports, permissions, and automation. Do not edit the production schema from an old spreadsheet copy.

The CRM discovery workshop can help identify which processes and owners to consult before the inventory begins. For teams that need bounded delivery help, Syncraft describes its scoped CRM implementation support. The inventory itself remains a client-specific decision document: its value comes from verified dependencies and explicit approvals, not the number of columns it contains.