To move from spreadsheets to Salesforce, treat it as a redesign rather than a file upload. List every sheet and who owns it. Find the columns people actually use and the logic hidden in formulas. Split wide rows into related records, clean them, then load on a fixed date. Rebuild the reports the sheets produced, keep the old files read-only, and give people a reason to stop exporting.
How do you know the spreadsheet has reached its limit?
The sheet has hit its limit when people argue about which version is right. Other warning signs follow from that one.
- Each rep keeps a personal copy, and the weekly roll-up is a copy-and-paste job someone dreads.
- Nobody can say who changed a deal amount, or when, or why.
- A departing employee takes the only current list of their customers with them.
- Access is all or nothing, so either everyone sees every client or someone emails extracts around.
- Formulas break when a column is inserted, and one person knows how to repair them.
- Managers ask for the same pipeline view every Monday and get a different answer each time.
Two or three of these is normal for a growing team. Most of them at once means the business now depends on a file nobody controls.
What actually changes when the team moves into Salesforce?
Four things change: each record has an owner, each customer exists once, edits leave a trail, and access follows rules. Those gains come with a real loss of freedom.
In a sheet, anyone can add a column, type a note into a cell or colour a row red. Salesforce asks for structure first: a field with a type, a picklist with agreed values, a stage with a definition. People will miss the speed of improvising.
Design for that loss rather than pretending it away. Give each role a short page layout and a few list views that feel like their old tabs. Allow inline editing on list views where it is safe. Leave a free-text field for the notes people genuinely need. If the new screen takes longer than the sheet for daily work, people drift back.
Which sheets should you inventory first?
Start with every file that someone opens weekly, wherever it lives. Shared drives, email attachments and personal laptops all count.
For each file, record the owner, how often it changes and who reads it. Then look inside. You are hunting for the rules the business runs on that nobody wrote down.
- Columns that are filled in, versus columns that are mostly blank or stale.
- Formulas that calculate commission, margin, renewal dates or a priority score.
- Macros or scripts that send reminders, copy rows or build a summary tab.
- Colour coding and bold text that carry meaning, such as red for at risk.
- Hidden tabs, lookup tables and dropdown lists that act as reference data.
- Free-text columns where people have been storing three facts in one cell.
Ask the owner to show you how they use the file day to day. The colour that means a customer owes money is rarely documented anywhere else.
How do spreadsheet columns map to Salesforce objects?
Most wide sheets hold several kinds of thing in one row. Mapping means separating companies, people, deals and anything else into their own related records.
A typical sales sheet repeats the company name, a contact name and email, a deal value, a stage and a close date on every line. In Salesforce, the company becomes an Account and the person becomes a Contact. The deal becomes an Opportunity linked to both. If one company appears on six rows, you want one Account with six Opportunities, not six Accounts.
Some sheets track things Salesforce has no standard object for. Policies, projects, sites or equipment may need a custom object. Keep that list short in phase one, and only add an object when people will report on it separately.
Write the mapping down as a simple two-column document: source column, target field. Mark every column you are deliberately leaving behind, with the reason. That document becomes the build spec and the test plan.
| Spreadsheet habit | Salesforce equivalent | What to configure | Adoption risk |
|---|---|---|---|
| One personal file per rep | Records owned by each user | Record ownership, sharing settings, a My Records list view | Reps fear losing control of their accounts |
| Colour coding for status or risk | Picklist field or formula flag | Picklist values with definitions, highlighted list view columns | Old meanings get lost if nobody captures them |
| Notes typed into a cell | Activities and notes on the record | Activity logging, a short notes field, email integration | Typing notes feels slower than a cell |
| Filtering and sorting tabs | List views | Shared list views per role, inline editing where safe | Too many views and people get lost |
| Formula columns for totals | Formula and roll-up summary fields, reports | Formulas rebuilt and tested against the sheet's numbers | Results differ from the sheet and trust drops |
| Weekly summary tab | Reports and dashboards | The same metrics, same definitions, scheduled to the same people | Managers keep asking for the spreadsheet version |
| Copying rows to a manager | Shared records and report subscriptions | Manager visibility through role hierarchy or sharing rules | Shadow copies continue out of habit |
Should you clean the data before or after the load?
Clean before you load. Duplicates and messy values are far cheaper to fix in a file than in a live org with automation running.
Merge copies of the same company and person across every rep's file first. Standardise country, state and stage values to the picklists you designed. Fill or flag missing email addresses. Settle on one rule for which record wins when two copies disagree, such as most recently updated.
Then turn on duplicate and matching rules in Salesforce so the problem does not return. Our guides to duplicate data cleanup and the data import tools cover the mechanics of matching and loading.
How much history should come across?
Bring what people will act on or report on, and archive the rest. For most teams that means open deals, active customers and a defined window of closed business.
Closed deals from years ago rarely need full detail in Salesforce. A summary record, or a link to the archive, is often enough. Decide this with whoever owns reporting, because year-on-year comparisons may need older closed-won data.
Activity notes are the hard call. Years of free-text notes in a column do not map neatly to dated activities. Common options include loading the last note per customer, attaching the full text to the Account, or leaving notes in the archive. Pick one deliberately.
Which reports do people need on day one?
The reports the sheet already answered, built to match its numbers. If Monday's pipeline total in Salesforce differs from the spreadsheet, people will trust the spreadsheet.
Collect the actual questions, not report names. How much is closing this quarter? Which customers renew this quarter? Who has not been contacted lately? Build a report for each one, then reconcile the totals against the final spreadsheet before cutover. Explain every difference, because some will be duplicates that the cleanup removed.
What should happen to the old files?
Keep them, lock them, and label them. A read-only archive answers future questions without inviting anyone to keep editing.
Copy the final version of every file into one restricted folder. Set it to view-only for everyone except an administrator. Rename each file with an archive label and the cutover date. Remove edit access from the originals so nobody keeps a live copy by accident.
Check whether any of the data has retention rules attached, such as client or financial records. That decides who may see the archive and how long it is kept.
How should cutover day work?
Pick a freeze date, stop edits to the sheets, load, check, and switch. Everyone should know the date well in advance.
- Announce the freeze date and the single place people will work from afterwards.
- At the freeze, set every sheet to view-only and take the final extract.
- Run the cleaned load into Salesforce, starting with Accounts, then Contacts, then Opportunities.
- Spot-check records with the people who own them, and reconcile totals against the sheets.
- Open Salesforce to users, with someone available to answer questions during the first few days.
- Keep a short log of anything missing, and fix it quickly so confidence holds.
Do a full rehearsal in a sandbox first. A practice load finds the broken mappings before anyone is waiting for them.
How do you get people to actually use it?
Train people on their own records, in their own daily tasks, close to go-live. Then watch usage and fix what slows people down.
Generic product tours do little for someone who has lived in a spreadsheet. Show a rep their own accounts, their pipeline view and how to log a call in a few clicks. Show a manager the report that replaces the weekly summary. See our training plan and our guide to why adoption stalls.
One Sales Cloud case shows how far this can go. At a building-products manufacturer, reps recorded customer interactions on handwritten forms and posted them in. The company moved to Sales Cloud, with dashboards and an automated scorecard emailed to each rep. New accounts grew from 34 to 103 in one year, and even long-time paper users came on board.
How do you stop shadow spreadsheets after go-live?
Make Salesforce the faster way to answer the question, and make exporting a choice rather than a default. Policy alone will not do it.
When someone exports a report to rebuild it in a sheet, ask what the sheet does that the report does not. Usually it is a missing field, a grouping or a chart, and you can add it. Limit export rights to roles that need them; confirm the exact permissions with your admin or Salesforce account team. Subscribe managers to the reports they used to request by email.
A multi-agent insurance agency that had tracked customers, policies and performance in Google Sheets moved to Sales Cloud. Its spreadsheet structure was mapped into Leads, Accounts and Opportunities with carrier, policy type and commission fields. Individual and team dashboards replaced manual spreadsheet tracking, and a private sharing model kept agents' clients separate.
What should the first phase of the move include?
Phase one should replace the sheets people rely on routinely, and nothing more. Everything else waits until the team trusts the system.
- Accounts, Contacts and Opportunities, plus at most one custom object the business genuinely runs on.
- Cleaned, de-duplicated data with an agreed history window.
- Role-based layouts and list views that mirror how people used their tabs.
- The reports and dashboards that replace the weekly summary, reconciled to the old numbers.
- Ownership, sharing and permissions that match who should see what.
- A locked archive of the original files and a clear cutover date.
Leave advanced automation and integrations for phase two unless a launch depends on them. A technology consultancy that had tracked its pipeline in spreadsheets and email started with Sales Cloud pipeline views, reports and web-to-lead capture. It added segmented Marketing Cloud campaigns as part of the same relaunch.
If you want help planning the move, our migration team can review your sheets and propose a scoped first phase.
