Migrating from Spreadsheets to SFA

Spreadsheet-to-SFA migrations fail more often than they should, and they fail for the same reason almost every time: organisations underestimate what is actually in the spreadsheets. Years of outlet data, pricing logic, territory rules, and operational workarounds live in those files - most of it undocumented, much of it inconsistent, and all of it essential to running the field sales operation. Moving to SFA without extracting and cleaning that data first is not a migration. It is a restart with broken foundations.

What Is Actually in the Spreadsheets

Before touching SFA configuration, conduct a full audit of every spreadsheet used in the current field sales process. This means:

• Every rep’s route list or outlet file
• Every sales manager’s territory tracking sheet
• Every pricing file used in the field
• Every SKU list, promotional pricing schedule, or scheme tracker
• Every reporting template used for secondary sales or coverage

Map every column in every spreadsheet to a corresponding field in the SFA system. Where a mapping doesn’t exist, you have identified a configuration gap that must be resolved before go-live. Where a mapping is ambiguous, you have identified a data definition problem that must be standardised before migration.

This audit is not an IT task. It requires someone who understands what each field means operationally - which means it belongs to the sales operations or commercial team.

The Outlet Data Problem

Outlet lists in spreadsheets are typically 30 to 40% incomplete or incorrect. This is not speculation - it is the consistent finding when organisations conduct their first systematic outlet audit before SFA deployment.

The problems are predictable: outlets that closed two years ago are still in the list, new outlets opened by reps are missing, duplicate entries exist under slightly different names, addresses are wrong or absent, tier classifications haven’t been updated in three years, and contact details are outdated.

The migration is the opportunity to fix this. Assigning every rep the task of validating their outlet list during the pre-launch period - confirming each outlet exists, capturing GPS coordinates, verifying contact details, and updating tier classification - produces a clean outlet universe at go-live. Migrating the unaudited spreadsheet data carries the mess into SFA, where it corrupts coverage reporting from day one.

Pricing and SKU Complexity

FMCG companies operating through distribution networks typically carry significant pricing complexity that was never formally documented. It evolved through negotiation, promotional programmes, channel tiers, and regional adjustments - and lives in spreadsheets that individual reps or managers maintain informally.

Before go-live, surface every active pricing tier, promotional scheme, and channel-specific price. Compare them against what is formally recorded in the ERP or pricing system. The gaps between the two represent pricing that reps are applying in the field without authorisation, or authorised pricing that was never loaded into the formal system.

Migrating this without resolution means SFA-captured orders will carry prices that don’t match ERP expectations, creating invoice reconciliation problems immediately after launch.

The Parallel Running Trap

The instinct to run spreadsheets alongside SFA “just in case” is understandable and damaging.

When both systems are live simultaneously, reps have a choice. The spreadsheet is familiar. The SFA system is new, slower at first, and requires behaviour change. Most reps will enter data into SFA when monitored and default to spreadsheets when not. At the end of the parallel period, SFA data is incomplete, the comparison is inconclusive, and management cannot make a definitive call to cut over.

Set a hard cutoff date. Communicate it before go-live. On that date, the spreadsheets stop. If the SFA data is incomplete in the first weeks, the team works to fill the gaps - which is what drives adoption. Maintaining a fallback prevents it.

Who Owns the Migration

Not IT. The technical work of data loading, field mapping, and system configuration is an IT function. The ownership of the migration is a commercial function.

The sales ops or commercial team must own:

• The outlet data audit and correction
• The pricing and SKU validation
• The beat plan design in SFA (translating existing territory logic into the system)
• The definition of coverage KPIs that will be tracked post-launch
• The rep training and behaviour change programme

IT can load clean data when it is provided. They cannot determine what clean looks like for a field sales outlet list or a channel pricing structure. That judgement belongs to the people who run the commercial operation.

Realistic Timeline

For a 50-rep team, a properly executed spreadsheet-to-SFA migration requires 6 to 8 weeks of pre-launch work before a rep opens the app on day one. This covers:

• Weeks 1–2: Spreadsheet audit and field mapping
• Weeks 2–4: Outlet data validation and correction (rep-assisted)
• Weeks 3–5: Pricing and SKU data preparation and ERP reconciliation
• Weeks 4–6: SFA configuration, beat plan loading, and system testing
• Weeks 6–8: Rep training, parallel testing (internal, not field-parallel), and go-live preparation

Organisations that compress this to 2 to 3 weeks launch with dirty data and insufficient training, and then spend months fixing problems that should have been resolved before go-live.

The First 30 Days After Migration

The first month after go-live will surface data errors that the spreadsheet system had been masking for years. Outlet duplicates that weren’t visible across multiple files become apparent when consolidated. Pricing inconsistencies that were invisible in siloed spreadsheets appear when compared across territories.

This is not a sign that the migration failed. It is the normal output of bringing inconsistent data into a single system where inconsistencies are visible. Have a defined process to fix errors fast: a single person or team that receives data issue reports, validates them, and loads corrections within 24 to 48 hours. Errors that sit unresolved for weeks erode rep confidence in the system and become adoption risks.

The first 30 days are the most important for long-term adoption. Reps who see their data errors fixed quickly trust the system. Reps who see their errors ignored return to spreadsheets.