Moving from Excel and Tally to a CRM or ERP: migration checklist

Move:

• Masters: items, customers, suppliers, ledgers, godowns, employees, price lists.
• Opening balances as on the cut-over date: trial balance, party-wise receivables and payables, stock per item per godown.
• Open documents: unpaid invoices, pending sales orders, open purchase orders, undelivered challans, advances.
• For a CRM: leads and deals active in the last 12 to 18 months, with their next follow-up dates.

Leave behind, but keep accessible:

• Closed transactions from earlier years. Keep the Tally company in read-only mode, and export key reports to PDF and Excel for reference.
• Dead leads older than a year or two. Archive them in a file rather than cluttering the new CRM.
• Filed GST returns. They stay on the GST portal; you do not need them inside the ERP.

Importing ten years of vouchers sounds thorough. In practice it multiplies cleaning work, slows the system, and rarely gets used.

Item masters built up over years in Tally or Excel usually carry the same problems:

• Duplicates under different names. "OPC 53 Cement 50kg", "Cement OPC53 bag" and "OPC-53 (50 KG)" are one item. Merge them and map the old names to the new one.
• Inconsistent units. One item sold in boxes and pieces needs a defined conversion, not two separate items.
• Missing or outdated HSN codes and GST rates. GST rates changed on 22 September 2025, with most goods now in the 5% and 18% slabs. Check every item's rate rather than copying the old one.
• Inactive items. Anything not bought or sold in two years can be marked inactive or left out.
• Categories and brands that let you filter and report properly.

Export the item list to Excel, sort it by name, and go through it with the person who knows the stock best. A distributor with 3,000 items can usually clean them in three or four focused days.

• Validate GSTINs. A GSTIN is 15 characters: a two-digit state code, the party's PAN, and check characters. Format checks catch typos; the GST portal confirms whether it is active.
• Merge duplicates by GSTIN first, then by phone number.
• Standardise phone numbers to one format, so WhatsApp and SMS work and duplicates are easier to spot.
• Fill in the state for every party, because place of supply decides IGST versus CGST plus SGST.
• Agree credit limits and payment terms now, while you are looking at every customer anyway.

For a CRM, add lead source and owner to every record, and record where each contact came from. Under the Digital Personal Data Protection Act, you should be able to say how and when you collected a person's details.

TallyPrime can export masters and reports to Excel or XML from its export option, which is enough for a one-time migration of items, ledgers and party balances. For ongoing integration, Tally can also act as a local server that exchanges XML with other software, which lets a new system read from or post into Tally while both run.

Map Tally's ledger groups carefully. Sundry Debtors, Sundry Creditors, duties and taxes, and bank accounts each need a clear destination in the new chart of accounts. A wrong mapping here shows up later as a trial balance that will not tie.

We have built Tally exchange into several products: Tally XML export in our textile manufacturing ERP, and Tally-importable exports in Takshiva, which also takes bulk student data from CSV and Excel.

• Pick the first day of a month, ideally a quarter. GST periods and payroll then sit wholly in one system.
• Freeze master changes three days before. New items and parties go on a list to be added after cut-over.
• Count physical stock on the evening before cut-over, godown by godown.
• Close the old books up to the cut-over date: all invoices entered, bank reconciled, trial balance printed.
• Load in a fixed order: masters, then opening balances, then open documents.
• Run in parallel for one to two weeks, comparing daily totals.

Never import straight into the live system. Rehearse the full import at least twice on a test copy, and fix the source data each time. Use an import tool that only adds records and shows a preview first; the student import we built for SchoolBill works that way, never updating or deleting existing records, so a bad file cannot damage good data.

Reconcile before anyone starts working in the new system:

• Trial balance totals match the old system to the rupee as on the cut-over date.
• Party-wise outstanding matches for every customer and supplier, not only in total.
• Stock quantity per item per godown matches the physical count.
• Stock value matches the closing stock in the old books, or the difference is explained.
• Record counts match: number of active items, parties and open documents.
• A random spot check of 20 to 30 records, opened side by side in both systems.
• For a CRM: every active lead has an owner and a next action date.

Get the accountant and the store in-charge to sign off on the reconciliation. It turns "I think it's right" into a record you can go back to.

Sales data in Excel has its own habits. Each salesperson keeps a sheet in their own format, statuses are free text, and follow-up dates live in a comments column, if anywhere.

• Map statuses to pipeline stages. "Hot", "interested", "call later" and "quote sent" need to become a fixed set of stages everyone uses. Agree on them before the import.
• Assign an owner to every lead. Leads without an owner are leads nobody calls.
• Convert notes into a next action and a date. "Call after Diwali" becomes a follow-up on a specific day.
• Merge across sheets. The same buyer often sits in two salespeople's files. Decide who keeps the lead before importing, not after a dispute.
• Bring the last few interactions, not every one. The latest two or three notes give context; a five-year history usually does not.

The first week after a CRM import is when salespeople decide whether to trust it. If their own leads show up correctly, with the right dates, they keep using it.

How long does a data migration take?

For a typical SME with a few thousand items and a few hundred parties, cleaning takes one to two weeks, rehearsals another week, and the final cut-over a day or two. Messy or multi-company data takes longer.

Should we migrate closed invoices from previous years?

Usually not. Keep the old system read-only for reference, and move only open invoices and balances.

What happens to our Tally customisations?

TDL customisations do not carry over. List what each one does, and decide whether the new system needs the same feature or whether the need has gone.

Who should do the data cleaning?

The people who use the data: the store in-charge for items, the accountant for ledgers and balances, sales for customers and leads. A vendor can provide templates and checks, but cannot know which of two similar items is real.

Can we keep using Excel for some things after the move?

For analysis, yes. For data that other people depend on, no. If a spreadsheet becomes the system of record again, the migration problem returns within a year.

Make a list of every place your data lives today and name one person responsible for each. Then pick the cut-over date and work backwards. If you would like help, our ERP development and CRM development projects include migration, and the 90-day rollout plan shows where it fits.