A Go result means the source file, field mappings, duplicate rules, and recovery plan are ready for a controlled pilot. A Conditional Go means the pilot can proceed, but the full import needs smaller batches or extra review. A Hold means the team still cannot predict how important records will be created, updated, linked, or assigned.
Treat the result as a release gate, not permission to upload every row at once. Cleaning up an import after sales, support, or office staff have started editing records is far harder than stopping for a structured review.
Start With the Type of Import
The risks change with the size and shape of the data.
A flat contact list is usually the simplest case. A contact-and-company migration needs association rules. A transfer involving contacts, companies, deals, tickets, activities, and owners needs a documented import order.
Use the checklist to review five areas before the pilot:
- Source-file integrity: consistent headers, one intended record per row, standardized values, and a reliable identifier.
- Field mapping: every incoming column has a destination CRM property, a transformation rule, or a deliberate exclusion.
- Duplicate control: the team knows how the CRM will identify an existing record before creating a new one.
- Relationship dependencies: parent and related records load in an order that preserves associations.
- Recovery readiness: the team has a pre-import export, a batch log, and a named person responsible for exceptions.
For a basic contact import, field mapping usually deserves the closest review. For multi-object migrations, association order becomes just as important. A contact with the correct name and email is still incomplete if it lands without the right company, owner, deal history, or status.
Small teams benefit from a dry run because one person often prepares the spreadsheet and runs the import. That is efficient, but it also means the same person can miss a mapping mistake they introduced. Have a second person review the mapping and pilot outcome before the first production batch.
Compare the Spreadsheet to the CRM Data Model
A spreadsheet header is not automatically a CRM property.
A column called “Status” might mean lead stage, customer tier, account health, payment status, or an internal follow-up label. Map it based on what the value means in the business, not because the names look similar.
Review the destination field type as well. Text, dates, numbers, checkboxes, dropdowns, multi-select fields, user fields, and relationship fields do not handle incoming data the same way.
CRM import comparison matrix
| Import condition | Safer setup | Risky setup | Dry-run action |
|---|---|---|---|
| Contact list with email addresses | Match using normalized email addresses | Shared inboxes, family emails, or contacts without email | Add a secondary identifier and route exceptions for review |
| Company records with website domains | Match using normalized company domains | Parent companies and subsidiaries using the same domain | Use a company ID or a separate matching rule |
| Dropdown fields | Use CRM option values exactly | Aliases, abbreviations, outdated labels, or inconsistent capitalization | Standardize source values before the pilot |
| Date fields | Use one format across the whole column | Mixed formats such as 03/04/2025 and 4 Mar 2025 |
Convert the full column to one agreed format |
| Contact-company links | Import companies first and use a stable company identifier | Matching contacts to companies through free-text company names | Build a company crosswalk before syncing |
| Record ownership | Map records to active CRM users | Former employees, inconsistent owner names, or blank owners | Assign a default owner and flag exceptions |
| Blank cells in update files | Define whether blanks mean no change or clear the existing value | Allowing the import to interpret blanks without a field rule | Set overwrite behavior field by field |
| Notes and free-text fields | Keep only content with a clear destination and purpose | Moving business logic hidden in vague notes | Separate notes for review or map them to a defined field |
For a simple contact list, start with a single record type and a cleaned CSV. That approach works when the file has reliable contact identifiers and clearly defined fields. It breaks down when business logic is hidden in free-text notes, inconsistent labels, or unclear owner names.
A 25-record pilot is a useful starting point. Do not choose the first 25 clean rows in the file. Pick records that expose likely problems:
- A duplicate record
- A blank optional field
- A record with punctuation or special characters
- A multi-value field
- A reassigned owner
- A contact with a company association
- A contact without an email address, if those exist in the source
- A record that could trigger an automation
The pilot should show what happens at the edges, not merely prove that clean rows can be uploaded.
Decide What Blank Cells Mean Before You Import
Blank source values are one of the easiest ways to damage existing CRM data.
A blank cell can mean three different things:
- The source system does not contain that value.
- The existing CRM value should remain untouched.
- The existing CRM value should be cleared.
Those are separate instructions. If every blank is treated as an update, an import can erase phone numbers, account notes, lifecycle stages, or consent data. If every blank is treated as no change, outdated data may remain in place.
Set the rule for each field before the dry run. Fields such as phone number, address, owner, consent status, lifecycle stage, and account notes often need different handling.
Keep the working files separate as well:
- One locked source file
- One cleaned staging file
- One field-mapping document
- One post-import exception log
This is more disciplined than working from one spreadsheet, but it prevents staff from editing the original export, reusing an old version, or re-importing rows that were already handled.
Choose the Right Import Path
Solo operator cleaning a contact list
Use a flat-file import and a 25-record pilot. Match by a stable field such as email when each contact has a unique address. Leave out vague columns such as “priority,” “type,” or “notes” until the team has defined what those values should mean in the CRM.
This route suits a cleaned list of individual contacts. It is not enough for shared inboxes, household records, contacts without email addresses, or files where one row contains information about several related records. Put those cases into a manual review queue instead of forcing them through a simple match rule.
Office manager combining several spreadsheets
Create a staging workbook before importing. Standardize headers, phone formats, dates, owner names, states, country names, and dropdown values. Add a source-system column so every imported record can be traced back to its original spreadsheet.
This approach is useful when the same customer may appear in an event list, an old mailing list, and a staff-maintained file. Without staging and deduplication, those separate rows can become separate CRM records.
Small team moving contacts, companies, and deal context
Use staged imports. Load parent companies first, then contacts, followed by deals or tickets and any remaining activities or notes. Maintain a crosswalk that connects the old record ID to the new CRM record ID.
This method preserves more context than a flat contact upload, but it requires a clear order of operations. Avoid placing companies, contacts, deals, and association logic into one all-purpose CSV when the CRM expects those objects to be handled separately.
Team syncing a recurring external system
Use the dry run to review the sync rules, not just the first file. Decide which system owns each field. For example, billing software may own billing status while the CRM owns sales stage and contact notes.
Recurring syncs need more discipline because a bad rule repeats. One incorrect owner mapping or date conversion can affect every later update until the process is paused and corrected.
Keep a Short Import Record
A reliable CRM import process does not need a large manual. It does need a mapping sheet that records:
- Source field
- Destination CRM field type
- Allowed values
- Transformation rule
- Overwrite rule
- Duplicate rule
- Field owner or responsible person
Update this record after material changes, including:
- A new custom CRM property
- A renamed dropdown option
- A revised lead-routing rule
- A new sales rep or departed employee
- A source-system export change
- A duplicate rule change
- A new automation triggered by imported records
Run a smaller pilot after any of these changes. A source export can look familiar while a renamed field, required property, routing rule, or workflow changes the import result.
Handle rejected rows separately from accepted rows. Assign someone to correct each exception and document the correction. Re-uploading the entire source file to fix five failed records creates duplicate risk and makes it harder to understand what changed.
CRM Rules That Can Block or Alter an Import
Each CRM sets its own limits and rules for imports, bulk jobs, record types, and associations. Review the platform’s documented import rules before preparing the full batch.
Pay attention to:
- Maximum rows and file size per import job
- Supported record types and association methods
- Required fields for each record type
- Read-only fields, formula fields, and system-managed timestamps
- Duplicate matching options and match precedence
- Whether imports trigger automations, notifications, assignments, or workflows
- Active-user requirements for record ownership
- API, bulk-job, or daily request limits for integrations
- Attachment and activity-history migration rules
Automations need special attention. A workflow that sends welcome emails, creates tasks, changes stages, or notifies account owners can turn a data import into an accidental communication event.
During the pilot, pause or narrow automations when the CRM provides that control. Use pilot records to confirm whether imports create tasks, change ownership, send messages, or move records into another stage.
Do not assume an “update existing records” option resolves duplicate handling. Email matching misses records without email addresses. Name matching can create false matches. Domain matching can merge separate contacts at the same organization. Use the identifier that reflects the CRM’s real identity rule for that record type.
Quick Checklist: CRM Import Dry Run Gate
Mark each item complete before the first production batch.
- The source file has one header row and one intended record per row.
- Every column has a destination, an exclusion decision, or a transformation rule.
- Dates, phone numbers, states, country names, and dropdown values use one standard format.
- A stable identifier exists for update matching or association building.
- Duplicate handling is defined for records with missing or shared email addresses.
- Required CRM fields have valid values for every pilot record.
- Blank-cell behavior is defined for any field that could overwrite existing CRM data.
- Parent records load before dependent records.
- Imported records will not trigger unwanted emails, assignments, tasks, or lifecycle changes.
- A pre-import export and batch-level change log are stored in the shared workspace.
- The 25-record pilot includes difficult cases, not only clean records.
- One person runs the import and another person reviews the pilot result.
Go: The pilot creates the intended records, updates the intended fields, preserves associations, and causes no unexpected automation activity.
Conditional Go: The pilot is clean, but the full import needs smaller batches because of relationship complexity, exception volume, or automation risk.
Hold: The team cannot clearly explain how duplicates, blanks, ownership, or associations will behave.
Bottom Line
For a single cleaned contact list, keep the first import narrow. Use clear email matching where appropriate, run a representative 25-record pilot, and review the result before loading the remaining rows.
For data coming from several spreadsheets or systems, do more preparation before syncing. Standardize the source data, import related objects in order, keep an ID crosswalk, and isolate exceptions rather than forcing them through the first batch. That work helps keep contacts, companies, owners, and automations from drifting out of alignment.
FAQ
What is a CRM import dry run?
A CRM import dry run is a controlled pilot using a small, representative set of records before the full sync. It reveals issues with field mappings, duplicates, associations, ownership, and automation behavior without exposing the full database to the same problem.
How many records should a CRM import pilot include?
Use at least 25 records for a basic flat-file import. Include duplicate emails, blank optional fields, unusual punctuation, multi-select values, inactive owners, and records that need company or deal associations.
Should CRM automations be turned off during an import?
Pause or limit automations that send emails, create tasks, assign owners, or change stages during the pilot when the CRM supports that control. Imported data can meet workflow conditions immediately, creating actions that are difficult to separate from normal staff activity afterward.
Can a CRM import be rolled back?
Rollback options depend on the CRM’s import controls and the changes made during the import. Keep a pre-import export, preserve the batch reference, and use pilot records to understand the platform’s delete or reversal process before a larger sync.
Should blank spreadsheet cells overwrite CRM data?
No, not by default. Define blank-cell behavior field by field before importing. A blank should clear an existing CRM value only when the team intends that result and has reviewed the affected records.