Check Your Spreadsheet Before The CRM Import
Do not start a full CRM import just because the spreadsheet opens cleanly. First confirm that tabs and objects are inventoried, contacts, companies, and deals use stable identifiers, duplicates and owners are resolved, fields and statuses are mapped, formulas and automations have replacement plans, access and retention decisions are documented, and a pilot can be validated and reversed. This checklist scores those gates without uploading your spreadsheet.
No file upload, pasted records, customer data, login, or server submission. The browser calculates from checklist statuses and optional aggregate counts only.
Spreadsheet to CRM Migration Readiness Checklist
Answer with the state you can prove today. A favorable percentage cannot override an unanswered row or a critical gate that is Not started.
Optional aggregate context
These values make the exported brief easier to scope. Do not enter customer records, field names, deal values, or private notes.
1. Inventory and scope
Know what exists, who owns it, and what will move.
Every spreadsheet file and tab is inventoried
Record its purpose, owner, approximate row count, and whether it is active, reference-only, archive-only, or excluded.
The migration scope names included and excluded records
Define date ranges, inactive records, historical notes, attachments, and any data that will remain outside the CRM.
A versioned source copy and change cutoff are defined
Keep a protected source-of-truth copy and document how changes are handled between preparation and cutover.
One migration owner and one business approver are assigned
Name the roles responsible for data preparation, import execution, business validation, and the go/no-go decision.
2. Contacts, companies, deals, and IDs
Separate objects and preserve relationships with stable keys.
Contacts, companies, deals, and other objects are separated
One row should represent one record for the applicable target object; repeated company or deal details should not be hidden inside contact rows.
Each applicable object has a stable, unique source ID
Do not rely only on a person's name, company name, or row number when the source can change or contain duplicates.
Relationships use stable IDs or an approved vendor key
Document how contacts connect to companies and deals, and how activities or notes connect to the right parent record.
Duplicate rules and merge authority are documented
Define the match keys, survivorship rule, conflicts that require review, and who is allowed to merge or discard records.
Required formats and blank-value rules are normalized
Standardize dates, time zones, phone formats, country/state values, booleans, numbers, and what a blank value means.
3. Owners, fields, and statuses
Define who owns each record and where every value belongs.
Every active record has a target owner or fallback queue
Resolve departed users, shared rows, blank owners, aliases, and the target CRM's owner identifier before import.
A source-to-target field map is complete
For every source column, record the target object, field, data type, required status, transform, default, and omit decision.
Pipeline stages and statuses are mapped to defined target values
Document entry and exit meaning so labels such as New, Working, Qualified, Won, and Lost do not change meaning during import.
Picklists, dates, numbers, and time zones have test values
Confirm exact spellings, allowed choices, locale, separators, and target behavior with representative rows.
Every unmapped or unused column has a disposition
Choose migrate, combine, transform, archive, or delete; do not let the import wizard make the decision implicitly.
4. Formulas, automations, and reports
Replace spreadsheet behavior, not only spreadsheet columns.
Spreadsheet formulas have named CRM replacements or retirement decisions
List what each formula produces, where its inputs come from, who depends on it, and how the result will be recreated or retired.
Macros, scripts, forms, integrations, and automations are inventoried
Identify triggers, actions, credentials owners, exceptions, and the replacement or shutdown plan for each dependency.
Reports and dashboards have metric definitions and replacement owners
Record filters, groupings, formulas, refresh timing, and the person who will confirm the CRM report matches the old decision.
Assignments, reminders, notifications, and follow-up tasks have a tested replacement
A clean data import is incomplete if the team loses the behavior that tells people what to do next.
5. Permissions, retention, and consent
Decide what should move, who can touch it, and how long it remains.
Sensitive and unnecessary fields are identified before export
Flag data that should be excluded, minimized, restricted, archived, or reviewed by the appropriate privacy, legal, or contract owner.
Export, preparation, import, and validation access is least-privilege
Document which roles need temporary file access and which CRM permissions are required for the pilot and full import.
Retention, archive, deletion, and migration-file disposal rules are approved
Use the business's applicable law, contracts, policies, and adviser guidance; the checklist does not determine those obligations.
Consent, marketing status, opt-out, and processing fields are reviewed
Separate contact storage from marketing eligibility and map any target-specific privacy or subscription fields deliberately.
Migration files have a controlled location and expiry date
Avoid ad hoc email attachments and personal downloads; define access removal and secure disposal after the approved retention window.
6. Vendor-specific import preparation
Recheck the exact target account, template, permissions, and duplicate rules.
Current official import instructions for the exact target account were checked
Verify supported objects, file formats, row limits, required fields, permissions, and subscription-dependent features immediately before the pilot.
Create, update, overwrite, duplicate, and association behavior is understood
Document the exact unique identifiers and what happens to blanks, conflicts, existing values, and related records.
The field map has been tested against the current vendor template
Use sample rows to confirm headers, object choices, date/number formats, owner IDs, and status values before a real pilot.
The exact reversal or cleanup method and its limits are documented
Do not assume every import has a universal undo; distinguish newly created records from updates to existing records.
7. Pilot and validation
Use a representative batch and reconcile what actually happened.
The pilot sample includes normal rows and known edge cases
Include duplicates, blanks, multiple relationships, inactive records, unusual statuses, and representative owner assignments without using the full population.
The pilot owner, time window, and communication plan are set
Define who runs it, who watches for errors, who validates, and when normal spreadsheet edits pause or resume.
Pre-import baseline counts are recorded
Capture counts by object, status, owner, and other decision-critical groups so the result can be reconciled without exposing record data in this tool.
Post-import counts, rejects, duplicates, and associations will be reconciled
Do not treat an import-complete message as validation; compare the target with the baseline and the error report.
Critical workflows and reports have acceptance tests and sign-off roles
Test assignment, tasks, notifications, forms, automations, reports, and permissions using the pilot records before a full import.
8. Rollback and cutover
Keep a reversible source, clear stop conditions, and one system of record.
The frozen source remains read-only and restorable through validation
Keep the source and transformation files intact until the approved validation and retention period ends.
Rollback triggers, decision owner, and deadline are explicit
Name the conditions that stop the import or cutover, who can make that call, and the latest reversible point.
Cutover communication prevents silent double entry
Tell users when the spreadsheet becomes read-only, where new work goes, how exceptions are handled, and when the CRM becomes authoritative.
Import files, logs, mapping versions, and approvals can be audited
Retain only the approved evidence needed to reproduce decisions, then dispose of temporary migration files under the documented policy.
Planning result only. Recheck the exact target CRM documentation before every pilot.
JavaScript is off. The interactive score and exports are unavailable, but every check, weight, formula, and result rule remains on this page. Mark the printed worksheet and calculate the weighted score manually.
| Workstream | Check | Weight | Status |
|---|---|---|---|
| 1. Inventory and scope | Every spreadsheet file and tab is inventoried | Critical 3 | Done / In progress / Not started / N/A |
| 1. Inventory and scope | The migration scope names included and excluded records | Important 2 | Done / In progress / Not started / N/A |
| 1. Inventory and scope | A versioned source copy and change cutoff are defined | Critical 3 | Done / In progress / Not started / N/A |
| 1. Inventory and scope | One migration owner and one business approver are assigned | Important 2 | Done / In progress / Not started / N/A |
| 2. Contacts, companies, deals, and IDs | Contacts, companies, deals, and other objects are separated | Critical 3 | Done / In progress / Not started / N/A |
| 2. Contacts, companies, deals, and IDs | Each applicable object has a stable, unique source ID | Critical 3 | Done / In progress / Not started / N/A |
| 2. Contacts, companies, deals, and IDs | Relationships use stable IDs or an approved vendor key | Critical 3 | Done / In progress / Not started / N/A |
| 2. Contacts, companies, deals, and IDs | Duplicate rules and merge authority are documented | Critical 3 | Done / In progress / Not started / N/A |
| 2. Contacts, companies, deals, and IDs | Required formats and blank-value rules are normalized | Important 2 | Done / In progress / Not started / N/A |
| 3. Owners, fields, and statuses | Every active record has a target owner or fallback queue | Critical 3 | Done / In progress / Not started / N/A |
| 3. Owners, fields, and statuses | A source-to-target field map is complete | Critical 3 | Done / In progress / Not started / N/A |
| 3. Owners, fields, and statuses | Pipeline stages and statuses are mapped to defined target values | Critical 3 | Done / In progress / Not started / N/A |
| 3. Owners, fields, and statuses | Picklists, dates, numbers, and time zones have test values | Important 2 | Done / In progress / Not started / N/A |
| 3. Owners, fields, and statuses | Every unmapped or unused column has a disposition | Important 2 | Done / In progress / Not started / N/A |
| 4. Formulas, automations, and reports | Spreadsheet formulas have named CRM replacements or retirement decisions | Important 2 | Done / In progress / Not started / N/A |
| 4. Formulas, automations, and reports | Macros, scripts, forms, integrations, and automations are inventoried | Critical 3 | Done / In progress / Not started / N/A |
| 4. Formulas, automations, and reports | Reports and dashboards have metric definitions and replacement owners | Important 2 | Done / In progress / Not started / N/A |
| 4. Formulas, automations, and reports | Assignments, reminders, notifications, and follow-up tasks have a tested replacement | Critical 3 | Done / In progress / Not started / N/A |
| 5. Permissions, retention, and consent | Sensitive and unnecessary fields are identified before export | Critical 3 | Done / In progress / Not started / N/A |
| 5. Permissions, retention, and consent | Export, preparation, import, and validation access is least-privilege | Critical 3 | Done / In progress / Not started / N/A |
| 5. Permissions, retention, and consent | Retention, archive, deletion, and migration-file disposal rules are approved | Critical 3 | Done / In progress / Not started / N/A |
| 5. Permissions, retention, and consent | Consent, marketing status, opt-out, and processing fields are reviewed | Critical 3 | Done / In progress / Not started / N/A |
| 5. Permissions, retention, and consent | Migration files have a controlled location and expiry date | Important 2 | Done / In progress / Not started / N/A |
| 6. Vendor-specific import preparation | Current official import instructions for the exact target account were checked | Critical 3 | Done / In progress / Not started / N/A |
| 6. Vendor-specific import preparation | Create, update, overwrite, duplicate, and association behavior is understood | Critical 3 | Done / In progress / Not started / N/A |
| 6. Vendor-specific import preparation | The field map has been tested against the current vendor template | Important 2 | Done / In progress / Not started / N/A |
| 6. Vendor-specific import preparation | The exact reversal or cleanup method and its limits are documented | Critical 3 | Done / In progress / Not started / N/A |
| 7. Pilot and validation | The pilot sample includes normal rows and known edge cases | Critical 3 | Done / In progress / Not started / N/A |
| 7. Pilot and validation | The pilot owner, time window, and communication plan are set | Important 2 | Done / In progress / Not started / N/A |
| 7. Pilot and validation | Pre-import baseline counts are recorded | Critical 3 | Done / In progress / Not started / N/A |
| 7. Pilot and validation | Post-import counts, rejects, duplicates, and associations will be reconciled | Critical 3 | Done / In progress / Not started / N/A |
| 7. Pilot and validation | Critical workflows and reports have acceptance tests and sign-off roles | Critical 3 | Done / In progress / Not started / N/A |
| 8. Rollback and cutover | The frozen source remains read-only and restorable through validation | Critical 3 | Done / In progress / Not started / N/A |
| 8. Rollback and cutover | Rollback triggers, decision owner, and deadline are explicit | Critical 3 | Done / In progress / Not started / N/A |
| 8. Rollback and cutover | Cutover communication prevents silent double entry | Important 2 | Done / In progress / Not started / N/A |
| 8. Rollback and cutover | Import files, logs, mapping versions, and approvals can be audited | Critical 3 | Done / In progress / Not started / N/A |
How The Readiness Score Works
The percentage and result band use only the visible rules below. They are TPTK planning rules, not vendor, legal, privacy, security, or industry-standard thresholds.
Weight: Critical gate = 3; Important = 2; Supporting = 1State multiplier: Done = 1.0; In progress = 0.5; Not started or unanswered = 0; N/A = excludedScore = round(100 x earned weighted points / applicable weighted points)Controlled pilot looks ready
Recheck current vendor instructions, then run the representative pilot and validation plan. This is not a success guarantee.
Finish preparation first
Critical work may still be In progress. Close the listed actions before relying on the pilot plan.
Migration blockers remain
Do not use a high score in easier sections to hide a missing ID, mapping, permission, validation, or rollback gate.
What The Migration Brief Is For
The brief turns the checklist into a handoff for the business owner, CRM administrator, implementation partner, or internal project lead. It records aggregate scope, the result band, open gates, and prioritized actions. It does not contain customer records or promise that the target CRM will accept the import.
Map
Trace each source object, ID, owner, field, status, and relationship into the target data model.
Pilot and validate
Use representative records, compare baseline counts, inspect rejects and associations, and test workflows.
Rollback
Keep the frozen source, vendor-specific reversal method, stop conditions, decision owner, and deadline.
Need Help Turning The Brief Into A CRM Build?
TPTK can help translate the field map, owner rules, forms, automations, reports, pilot, and validation plan into an implementation scope. Share the exported checklist summary, not customer records or credentials.
Vendor-Neutral Planning Stops Where The Target CRM Starts
The checklist defines the planning evidence a team should possess. The target CRM controls the actual import format and behavior. Current official documentation shows why that distinction matters:
HubSpot
Current instructions distinguish objects, unique identifiers, associations, overwrite behavior, import permissions, consent controls, and date/number formats. Import-error guidance separately addresses duplicate IDs, failed associations, blanks, and status mismatches.
Salesforce
Current help describes several match methods, including platform IDs and external IDs. Its mass-delete guidance shows that reversal depends on permissions, object type, created-versus-updated records, and timing.
Zoho CRM
Current duplicate behavior depends on unique fields, modules, permissions, and import choices. A general duplicate rule cannot substitute for the target account’s configured behavior.
TPTK synthesis: treat the vendor step as a fresh pre-pilot verification, not a box checked months earlier. Platform instructions, plan entitlements, object support, and permissions can change.
Methodology, Privacy, And Limitations
Model version: 1.0, published 2026-07-16. The tool contains 36 checks across eight workstreams. Weights reflect the likely planning impact of an unresolved check; they do not estimate migration probability or loss.
Privacy boundary: the browser receives only checklist statuses and optional aggregate counts. The page has no file input, paste target, free-text note field, account, database, or network request for the brief. Analytics events exclude the answers and aggregate context values.
Governance boundary: FTC guidance supports knowing what personal information a business holds, limiting access, keeping only what is needed, documenting retention, and disposing securely. The page does not decide which laws, contracts, policies, or consent rules apply to a specific business.
Not modeled: vendor row limits, API behavior, subscription entitlements, custom-object limits, exact field types, data residency, encryption architecture, record-level permissions, legal duties, migration duration, implementation cost, ROI, or the quality of the source data itself.
Corrections: send source, formula, or reproducibility questions to hello@theprotoolkit.com.
Version history: version 1.0 is the initial public release of the weighted readiness checklist and local brief exports.
Continue With The Right Owner Page
Still choosing the CRM?
Keep product selection separate from migration readiness.
Planning lead intake?
Design the form-to-CRM handoff after IDs, owners, and field rules are stable.
Planning meeting follow-up?
Map notes, tasks, drafts, review, and retention into the CRM workflow.
Spreadsheet To CRM Migration FAQ
Does this checklist upload or read my spreadsheet?
No. The tool does not accept a file, pasted rows, customer data, credentials, or free-text business notes. The checklist and score run in your browser, and TPTK analytics receive only aggregate interaction events such as the result band and export format.
What does the migration-readiness score guarantee?
Nothing. It is a transparent TPTK planning score, not a guarantee of import success, data quality, security, legal compliance, or vendor compatibility. A pilot still needs current vendor instructions, validation, and an approved rollback plan.
Can I use the checklist before choosing a CRM?
Yes for inventory, cleanup, object design, ownership, workflow replacement, and governance planning. Keep the vendor-specific checks Not started until the target CRM and exact account plan are known.
How should a small team handle duplicate contacts or companies?
Choose a stable match key, identify conflicts, define which record wins for each field, and assign merge authority before import. The target CRM's unique-field and deduplication behavior must also be checked in its current official documentation.
Do contacts, companies, and deals always need separate sheets?
The target CRM may accept one or multiple files, but the team still needs a clear object model and stable relationships. Separate staging sheets are often easier to audit; follow the exact vendor template for the final import.
What belongs in a pilot CRM import?
Use a small representative sample that includes normal records and known edge cases such as duplicates, blanks, multiple associations, owner changes, unusual statuses, and records that should be excluded. Reconcile counts and errors before expanding the scope.
What should a CRM migration rollback plan include?
Keep a frozen source, document the vendor's exact cleanup or reversal limits, record import timing and IDs where applicable, define stop conditions, assign the decision owner, and set a deadline after which rollback becomes harder or requires a different method.
Current Official Sources
- Federal Trade Commission, Protecting Personal Information: A Guide for Business: data inventory, access, minimization, retention, and secure disposal guidance.
- NIST Privacy Framework: a risk-management framework for identifying and governing privacy risk. Version 1.1 was still an Initial Public Draft/coming-soon project when checked; this page does not treat it as final.
- HubSpot, Import records for multiple objects and Troubleshoot import errors: current vendor-specific IDs, associations, permissions, formats, consent controls, and error examples.
- Salesforce, What Is Imported for Business Accounts and Contacts? and Using Mass Delete to Undo Imports: match methods and the limits of one vendor-specific reversal path.
- Zoho CRM, Checking Duplicate Records: unique fields, permissions, module boundaries, and import duplicate choices.
Sources checked: 2026-07-16. Product documentation can change; recheck the target vendor immediately before the pilot.