CRM Data Migration Checklist: Moving Off Excel in India

The distributor in Nagpur has been maintaining his outlet master in the same Excel since 2018. The national sales head's laptop has a folder called FINALbeatplanv7ACTUAL.xlsx. The pharma company's legacy CRM — a desktop application that requires Internet Explorer — holds five years of medical representative visit logs that nobody can export cleanly.

This is the real reason CRM switches stall in India. It isn't the product comparison. It isn't the pricing. It's the quiet fear that the moment you commit to a new system, three years of hard-won outlet relationships, route logic and order history will vanish into a corrupted CSV.

That fear is legitimate. A badly managed migration can set a field team back months. But staying on Excel because the migration feels risky is the same logic as not servicing a vehicle because the workshop might scratch the bumper. The damage from inaction compounds invisibly, every quarter.

Here is the checklist that de-risks the switch itself.

Step 1: Audit before you touch anything

The first instinct when migrating data is to start exporting. Resist it.

Spend one week auditing what you actually have. Ask three questions about every data source:

• Is this the master copy, or a regional variant of something else?
• When was it last verified against ground truth?
• Who owns it, and who else has edited it?

In most Indian field sales operations, you will find at least four versions of the outlet master — one with the ASM, one with the distributor, one on the sales head's laptop, and one inside the legacy tool — none of which are identical. Exporting all four and merging them later is expensive. Deciding which one is canonical before the migration begins is cheap.

Run a rough deduplication count on your outlet list. Match on a combination of outlet name, PIN code, and phone number. A multi-year Excel outlet master almost always turns up a meaningful share of duplicate, inactive, or misassigned records — outlets sitting on the wrong beat, or accounts nobody has serviced in a year. Migrating that noise into a new CRM doesn't clean it — it just makes it harder to find.

Step 2: Clean the data to a defined standard

This is the unglamorous centre of any migration, and the step that most teams underfund.

Cleaning does not mean making data look pretty. It means enforcing a schema every record must meet before it's allowed into the new system. For a field sales operation in India, the minimum standard for an outlet record looks like this:

• Outlet name (no shorthand, no abbreviations that only one ASM understands)
• Full address including PIN code
• Beat assignment (single beat, not "TBD" or "Misc")
• Outlet category (modern trade, general trade, pharmacy, etc.)
• Active/inactive flag with a last-verified date
• Primary contact number

If a record can't meet this standard, it goes into a quarantine sheet — not the migration. You clean it separately, or you decide it isn't worth migrating. What you don't do is move ambiguous data into the new system and hope someone fixes it later. Nobody fixes it later.

For historical order data, set a cutoff. Three years of transaction history is usually enough for trend analysis. Migrating twelve years of daily secondary sales data from a legacy system nobody trusts is a lot of effort for very little return.

Step 3: Map your old fields to new fields before anyone opens the import tool

Field mapping is where migrations die quietly.

Your Excel has a column called "Outlet Type" with values like "MT", "GT", "Pharma", "H&G", and thirty rows that say "Other". Your new CRM has a field called "Channel" with a defined picklist. Someone has to decide how "H&G" becomes "Home & General" — or whether it merges into "General Trade" — before import, not after. Post-migration field reconciliation is significantly harder than pre-migration field mapping.

Build a mapping document. One row per source field. Columns for: source field name, source field values (all unique values, not a sample), target field name, transformation rule, owner. It sounds bureaucratic. It takes about two days for a mid-sized field team's data. It prevents the kind of corruption where thousands of pharma outlets get imported as "General Trade" because someone skipped the mapping step.

Beat plan data deserves special attention here. A beat plan in Excel is usually a set of implicit relationships — outlet X appears on row 47, which is under the tab "ASM North", which implies a regional hierarchy. That structure is invisible to an import tool. You have to make it explicit: beat name, territory, ASM, outlet IDs, visit frequency. Write it out as a flat table before you map it.

Step 4: Run a pilot migration on a single region

Do not migrate everything at once.

Pick one region — ideally a mid-sized territory, not your largest or smallest — and run the full migration for that region alone. Import the outlets. Import the beat plan. Import 90 days of order history. Then ask the ASM and two field executives to spend three days working off the new system, with the old Excel still available as a fallback.

Ask them to report every discrepancy they find: wrong beat assignment, missing outlet, order history that doesn't match what they remember, contact number that's gone wrong. A first pilot run on real data almost always turns up a batch of issues — that's normal, and it is far better to find them in a pilot than after you've cut over nationally.

Fix the issues in the source data and the mapping rules. Then run the pilot again. The second run should produce noticeably fewer discrepancies. If it doesn't, something is wrong in the cleaning or mapping step — go back, don't proceed.

Step 5: Verify before you cut over, not after

Cutover is the moment the old system is switched off and the new one becomes the system of record. Treat it as a gate, not a deadline.

Before cutover, verify three things independently:

Outlet count. Total outlets in the new CRM should match the agreed clean count from Step 2. Any meaningful gap needs an explanation before you proceed.

Beat coverage. Every active executive should have a populated beat in the new system. Run a report: executives with zero outlet assignments are a migration error, not a data absence.

A sample order audit. Pick 50 random orders from the last 90 days in the old system. Find those same orders in the new system. Check that outlet, product, quantity, date and value all match. Multiple mismatches in that sample means the historical data migration has a systemic problem worth pausing over.

Once all three checks pass, cut over. Not before.

The counterintuitive point here: running old and new systems in parallel for more than two to three weeks after cutover is usually counterproductive. It creates two sources of truth, people default to whichever system confirms what they want to believe, and new data stops being entered cleanly into either. Set a hard cutover date and hold it.

The real blocker was never the migration

Most field sales teams that have been on Excel for five years are not on Excel because they chose it. They're on it because the last CRM evaluation ended in a two-hour demo, a proposal that nobody read, and an implicit decision to do nothing.

The migration checklist above is not the hard part. The hard part is deciding to start. And the decision to start is easier when you know exactly what the migration involves — which is why the checklist exists.

If your team runs on field force operations — FMCG, pharma, banking, logistics or any distribution-heavy business — Kinematic handles the import process as part of onboarding, including outlet master mapping and beat plan structure. The Kini AI layer starts finding patterns in your historical data once it's clean and inside the system.

If you're at the stage of evaluating whether a switch makes sense at all, talk to us. Bring the messy Excel. That's what the conversation is for.