“We just need to get our spreadsheet into Salesforce” is one of the more common sentences we hear on a first call — and one of the more misleading, not because it’s wrong, but because “just” is doing a lot of work in that sentence. A spreadsheet migration that goes well is not a copy-paste job. It’s a short, structured project with its own stages, and skipping any of them is exactly how businesses end up with a CRM that’s technically populated and practically unusable.
Here’s a realistic checklist, in the order it actually needs to happen.
1. Data inventory
Before touching Salesforce, know what you’re actually moving. That usually means more than one spreadsheet — a contacts list, a separate deals-in-progress tracker, maybe a support-request log someone kept in email. List every source, who owns it, and roughly how many records and fields are in each. You cannot scope a migration you haven’t inventoried.
2. Cleanup — before mapping, not after
Every spreadsheet accumulates the same problems over time: inconsistent formatting (“NJ” vs “New Jersey” vs “nj”), stale records for people who left or companies that closed, and free-text fields where a dropdown should have been. Cleaning this up before migration is significantly cheaper than cleaning it up inside Salesforce afterward, where every fix touches a live system instead of a spreadsheet. This is also the point to decide what genuinely isn’t worth migrating — not every row in a five-year-old spreadsheet deserves a permanent home in the new system.
3. Field mapping
Every column in the spreadsheet needs a deliberate answer to “where does this go in Salesforce” — an existing standard field, a new custom field, or nowhere. This is where spreadsheet habits and CRM structure collide most visibly: a “Status” column with eleven inconsistent values people typed freehand needs to become a clean picklist with a defined set of options, and someone has to decide what maps to what.
4. Duplicate handling
If the same contact or company exists in more than one source spreadsheet — which is almost always true — decide the matching logic before import, not during. Matching on email address is common but not foolproof; a person might appear with two different addresses, or two different people might share a generic one. Whatever rule you choose, apply it consistently and keep a log of what got merged with what, in case something needs to be unwound.
5. Required fields and validation rules
Salesforce objects often have fields that are required for the record to make sense in downstream processes — an Opportunity needs a Stage, a Contact often needs an Account. If the spreadsheet data doesn’t cleanly supply those values, decide the fallback now (a default value, a flag for manual review) rather than discovering thousands of failed imports during cutover.
6. Relationships
Spreadsheets are flat; Salesforce is relational. A contacts spreadsheet with a “Company” text column needs that text turned into an actual link to an Account record — which means Accounts often need to be created or matched first, then Contacts linked to them, not the other way around. Getting the order of operations wrong here is one of the most common causes of a migration that “worked” but left every record floating unconnected.
7. A real test migration
Migrate a representative sample — not the easiest 50 records, a genuinely representative slice including the messy ones — into a sandbox or test environment first. This is where mapping mistakes and validation-rule conflicts surface while they’re still cheap to fix.
8. User acceptance testing
The people who will actually use the data — sales reps, account managers, whoever pulls reports — should look at the test migration before it goes further. They’ll catch things a technical review won’t: a field that’s technically correct but useless for how they actually work, a report that used to be simple and now needs three extra clicks.
9. Cutover
Plan the actual go-live like a small project, not a weekend favor: a specific time, a way to catch anything created in the old spreadsheets between the final export and go-live, and a rollback plan if something goes wrong. Communicate the cutover date to everyone who touches the data, so nobody keeps editing the old spreadsheet the day after it stopped being the source of truth.
10. Post-migration checks
Once live, verify counts match expectations, spot-check a sample of records against the original source, and confirm reports and dashboards that depend on the migrated data are producing sensible numbers. Budget a short stabilization period — a week or two — where the team can flag anything that looks off before it’s assumed correct.
How long a realistic migration actually takes
For a small business with a handful of interconnected spreadsheets — contacts, an active-deals tracker, maybe a basic support log — a properly run migration through all ten steps above typically runs somewhere in the range of two to four weeks, most of it spent on cleanup and field mapping rather than the technical import itself. Larger or messier data sets take longer, and the honest driver of that timeline is almost always data quality, not Salesforce’s capabilities. A clean, well-organized spreadsheet migrates quickly. A spreadsheet with five years of inconsistent manual entry takes real time to clean regardless of what tool eventually imports it.
A common mistake: migrating structure along with the mess
One of the most avoidable errors is treating the migration as an opportunity to recreate the spreadsheet’s existing structure inside Salesforce, rather than rethinking it. A spreadsheet often accumulates ad hoc columns over time — “Notes 2,” a status column with values nobody fully agrees on anymore — because adding a new column was always the path of least resistance. Salesforce doesn’t have that same friction, which means it’s worth deciding, during field mapping, which of those columns actually deserve to become a permanent, structured field, and which represent years of workaround that shouldn’t be preserved as-is.
Why “just import it” usually costs more
Every step above exists because skipping it creates real cost later: bad field mapping means reports nobody trusts, missed duplicate handling means reps working the same lead twice, and skipped UAT means the team quietly builds a workaround spreadsheet six months later because Salesforce “doesn’t work the way we need it to” — when the actual problem was an unplanned migration, not the platform.
A well-run migration is a bounded project with a clear finish line, not an open-ended cleanup effort. Most of what we do in this kind of engagement is exactly this checklist, run in order, with the cleanup and mapping decisions made deliberately instead of by default.
Getting it right the first time
If you’re staring at a handful of spreadsheets and a Salesforce org that isn’t being used the way it should be, the fastest way to find out what’s actually involved is a short discovery conversation — we’ll tell you honestly what the real scope looks like before anything gets scheduled. It’s the same audit-first approach behind everything in our Salesforce work.