Data migration is the phase of an ERP rollout that nobody puts on a brochure and almost every project underestimates. It is unglamorous, slow and detail-obsessive. Get it right and the new system starts life with numbers the team trusts. Get it wrong and the most beautifully configured ERP becomes a parallel reporting layer nobody believes, because opening balances do not tie back to Tally and stock value is off by a few lakhs.
For Indian SMBs the story is almost always the same shape — years of Tally for accounts and GST, a sprawl of Excel for production and dispatch, a standalone tool for barcode or weighbridge entries, and WhatsApp groups carrying decisions that never made it into any system. Pulling all of that into one ERP without losing the trust of finance and stores is the real test of an implementation.
Why Data Migration Decides Whether the ERP Survives Year One
An ERP rollout is judged by finance on day one of the first month-end close. That close runs on the data that was migrated in — opening balances, party and item masters, GSTINs, outstanding, stock quantities and valuations. If those numbers tie to the rupee against the old system, the team accepts the new ERP as the source of truth. If they do not, every report afterwards is suspect, staff quietly keep parallel Excel sheets "just to be safe", and the system that was supposed to end the spreadsheet era becomes another one to ignore.
The cost of poor migration is rarely an outright failure — it is a slow drift. Stock value drifts further from the stores register each month because duplicate item codes split receipts. GSTR-1 mismatches take days to investigate because two spellings of the same buyer landed in two ledgers. None of these break the ERP, but together they corrode confidence until the team works around the system instead of through it. The migration is not a weekend technical task — it is weeks of cleansing, mapping and rehearsing before a single live transaction touches the new system. If you are planning the wider rollout, the seven-phase ERP implementation roadmap shows where migration sits inside the larger project.
The Data Migration Plan: 7 Phases From Assessment to Live
Assess & Inventory the Data
List every place data currently lives — Tally companies, Excel sheets, standalone inventory or weighbridge tools, the barcode app, the WhatsApp decisions that exist nowhere else. For each, note record counts, owner and whether it is authoritative. This map decides what is in scope and where the duplicates between systems hide.
Cleanse the Masters
Export party, item, ledger and GSTIN masters and audit them. Merge duplicate parties, unify item codes, standardise units (KG vs KGS), fill missing HSN codes, remove dead ledgers. Cleansing happens in the export sheet, before import — fixing the same problems inside the ERP later costs many times more.
Map to the ERP Structure
Decide how each old-system field lands in the new one. Tally ledger groups map to the new chart of accounts, item categories to the product hierarchy, old branch codes to godowns. HSN codes are validated against the current GST list. Mapping is captured in a single sheet so the import is repeatable.
Mock Migration & Validation
Load the cleaned, mapped data into a test environment exactly as it will be loaded at cutover. Run validation reports — trial balance, stock value, outstanding — against the source system. Discrepancies are fixed in the source data or mapping, not the result. The third run is the rehearsal for the real thing.
Cutover Weekend
At a clean month-end aligned to the GST period, the old system closes and freezes. Final exports run, the verified import lands in production, and open documents (SOs, POs, job work challans, unreconciled receipts) are loaded as live records. The team starts Monday on the new system with reconciled opening numbers.
Reconcile & Sign Off
Trial balance, stock value and outstanding are reconciled on the new ERP against the closed old system, to the rupee. Finance signs off in writing that opening balances match. Any difference is investigated immediately, not parked. This sign-off is what gives the team permission to trust the new numbers.
Parallel Run & Retire the Old System
For one full GST cycle the old system runs alongside for reference while the team enters live transactions on the new ERP. After one clean month-end close that matches the parallel old-system close, the old software is retired to read-only archive. The migration is complete only when the old system is genuinely switched off.
The Migration Capabilities That Make Each Phase Land
The features below quietly decide whether a migration reconciles to the rupee or turns into a month of re-keying — the import tooling, validation reports, mapping sheets and cutover discipline that separate a clean go-live from a half-trusted one.
Templated Imports
Standardised templates for each master and transaction type, so exports from Tally and Excel land in a predictable shape rather than being hand-coded.
- Templates for ledgers, party masters, item masters, opening balances and outstanding
- Bulk import for sales orders, purchase orders and open job work challans
- Column-level validation flags missing GSTINs, HSN codes and units
- Same template for mock runs and the real cutover — no separate paths
Duplicate Detection
Catches the duplicates that destroy reports later — the same party spelt four ways, the same item under two codes, the same supplier with three GSTINs.
- Fuzzy match on party names, GSTINs and addresses
- Item duplicate detection across code, description and HSN combinations
- Unit standardisation (KG / KGS / kilograms collapsed)
- Dead ledger detection so the new chart of accounts starts clean
GST & HSN Mapping
Validates HSN codes, tax rates and place-of-supply settings against current GST structure so the first GSTR-1 does not bounce.
- HSN codes validated against the current GST master list
- GST rates mapped per item and per state
- GSTIN format validation on every party master
- RCM, exempt and zero-rated flags carried correctly
Reconciliation Reports
The reports finance needs to sign off — trial balance, stock value and outstanding — comparable line-by-line against the old system.
- Group-wise trial balance comparison against Tally
- Item-wise stock quantity and valuation comparison against the stores register
- Party-wise outstanding comparison against Tally outstanding reports
- Variance flagging and sign-off audit log so the close is defensible later
The Indian SMB Landmines to Plan Around
Every migration has its own quirks, but the landmines that catch Indian SMBs out are remarkably consistent. Naming them up front turns each one from a surprise into a checklist item.
Duplicate party and vendor masters
The single most common problem. Years of casual data entry leave the same buyer recorded as "Sharma Industries", "Sharma Inds", "Sharma Industries Ltd" and "Sharma Industries (Mumbai)" — sometimes with different GSTINs, sometimes the same one. Imported as-is, sales reports split four ways, outstanding looks confused, and payment reminders chase the wrong ledger. Fix: merge in the cleansing phase with a clear rule about which spelling becomes the master and which addresses, GSTINs and contacts carry forward.
Opening balance reconciliation
Trial balance, stock value and outstanding are the three reconciliations that have to tie to the rupee. Trial balance is the most visible — every group total on the new ERP must match Tally on cutover date. Stock value is the most painful because it forces a real physical count and surfaces years of small errors. Outstanding is the most political — old, written-off receivables that were never formally written off in Tally have to be cleaned up so the new system does not inherit them as live debt. The wider financial management setup depends on these opening numbers being right.
GST mapping of legacy item HSN codes
HSN codes in older Tally companies are frequently incomplete, outdated or wrong — set up before mandatory HSN reporting tightened up, never revisited. Migration is the one chance to validate every item's HSN against the current GST master list and fix gaps before the first GSTR-1 fires from the new system. Catching a wrong HSN at import is a five-minute fix; catching it after three months of e-invoices is a return-filing problem. The GST e-invoicing flow depends on this mapping being clean from day one.
Inventory valuation cutover (FIFO vs weighted-average)
If the old system used weighted-average costing and the new ERP is set up for FIFO (or the other way round), opening stock value will not match unless the cutover is handled deliberately. The safest approach is to set the new ERP's opening stock at the closing valuation from the old system as a single opening cost layer, then let the new methodology take over. Trying to back-fill historic receipts to reconstruct FIFO layers is rarely worth it. The decision belongs to finance, documented in writing, before any data is loaded.
Historic transactions versus go-live-only
The instinct is to migrate seven years of vouchers "for completeness". For most Indian SMBs this is a costly mistake — it multiplies cleanup time, surfaces legacy quality problems nobody cares about, and rarely earns its cost. The cleaner approach is opening balances plus current-year transactions, with the old system kept as read-only archive for audit reference.
Open documents and multi-branch structure
Unbilled sales orders, pending POs, open job work challans and unreconciled receipts all have to be migrated as live records, not history, so the team can complete them on Monday morning. Businesses with more than one GSTIN or branch often also discover the Tally setup never modelled the branch structure properly — migration is the moment to fix this so consolidated and branch-wise reporting works from day one. The multi-branch management blog covers the structure this lands on.
| Migration Activity | Without a Plan | With ApicalERP's Phased Migration |
|---|---|---|
| Data Assessment | "We'll figure out scope as we go"; sources keep surfacing | Every data source inventoried up front, scope agreed in writing |
| Master Cleansing | Duplicates dumped in; reports split across variants forever | Cleansed in the export sheet before import; one master per real entity |
| HSN & GST Mapping | Old, missing or wrong HSN codes carried over; first GSTR-1 mismatches | Validated against current GST master list, fixed before import |
| Opening Balances | Loaded once, never reconciled; finance never trusts the numbers | Trial balance, stock and outstanding reconciled to the rupee, signed off |
| Inventory Valuation | FIFO/weighted-average mismatch surfaces on first stock report | Cutover method agreed in writing; opening value set deliberately |
| Mock Runs | Cutover is the first time the real import is attempted | Two or three mock runs in test, with reconciliation each time |
| Cutover Date | Mid-period switch; data splits across two return periods | Clean month-end aligned to GST period; old closes, new opens |
| Old System | Switched off too soon; no fallback when a gap surfaces | Parallel run for one full GST cycle, then retired to read-only |
| Outcome | Numbers nobody trusts; quiet revert to parallel Excel | Reconciled opening numbers the team genuinely runs on |
Benefits of a Disciplined Migration
Migration Best Practices
The migrations that land cleanly tend to follow the same disciplined patterns. None of them are technical — they are about sequence, ownership and proof.
1. Cleanse in the source, not in the ERP
- Export masters early and audit them in spreadsheets where bulk edits are fast, before any import
- Merge duplicate parties, standardise units, fill HSN codes and retire dead ledgers in the export, not after
- Treat the cleansing sheet as a deliverable — reviewed, signed off and version-controlled
- Importing dirty data and "fixing it later" multiplies effort tenfold and breaks reports in the meantime
2. Reconcile three things to the rupee — trial balance, stock and outstanding
- Trial balance: every group total on the new ERP must match Tally on cutover date, group by group
- Stock: item-wise quantity and valuation must match the stores register and Tally stock summary
- Outstanding: party-wise receivables and payables must match Tally outstanding reports, party by party
- Variances investigated and fixed before go-live, not parked — every parked variance returns as a finance complaint
3. Run at least two mock migrations
- Load cleaned, mapped data into a test environment exactly as the production load will run
- Run the three reconciliations against the source system; fix discrepancies in source data or mapping
- The second mock proves the fixes; a third is the rehearsal for the real cutover
- The first time the real import runs should never be the cutover itself
4. Cutover at a clean month-end aligned to the GST period
- Pick a month-end that aligns with the GST period so the old system closes and files the return cleanly
- Avoid mid-period cutovers — splitting data across two return periods creates an audit headache
- Communicate the cutover window in writing — finance, stores, dispatch and sales all need to know the rules
- Take a full backup of the old system before final export, kept indefinitely as the audit record
5. Run in parallel for one full GST cycle, then switch off
- Live transactions go into the new ERP from day one; the old system is reference only
- Finance reconciles the new GSTR-1 and GSTR-3B against what the old system would have produced
- After one clean monthly close that matches, retire the old system to read-only archive
- Leaving it running indefinitely "just in case" is how teams maintain two sets of books forever
Real-World Success Story
🧾 Case Study: Pune Auto Components Manufacturer
Company Profile: ₹42 crore turnover auto components manufacturer in Pune (Maharashtra) producing precision turned and machined parts for Tier-1 automotive suppliers, with a main machining unit, a finished-goods warehouse, an offsite raw-material godown and a network of outside job workers handling heat-treatment and surface finishing. Team of 108 — 14 in accounts and administration, a production and stores team across both units, a quality desk, a dispatch desk and a small sales team servicing OEMs and Tier-1 customers across Maharashtra, Karnataka and Tamil Nadu. The business ran on Tally for accounts and GST, three Excel workbooks for production planning, a standalone barcode-printing tool for finished goods, a separate Excel sheet for job work tracking, and a WhatsApp group where dispatch decisions and last-minute customer changes were recorded.
Challenges Before the ApicalERP Migration:
- Three different versions of the same buyer everywhere: A single Tier-1 customer was listed in Tally as four ledgers — full name, short name, "Mumbai division" and "Pune division" — sometimes against the same GSTIN, sometimes against different ones; outstanding reports were impossible to read at a glance, and the sales team often did not know which ledger to chase
- HSN codes were a mix of right, missing and outdated: The Tally item master had been set up before strict HSN reporting tightened, and roughly 18% of items either had no HSN code or an outdated one; GSTR-1 filing each month involved a manual cleanup pass on the export before upload
- Stock value and the stores register disagreed by ₹6-8 lakh routinely: The barcode tool, the production Excel and Tally never quite matched; the gap had to be explained at every month-end close and was usually absorbed as an adjustment entry rather than traced, eroding trust in stock numbers
- Job work material at outside processors was tracked on Excel and WhatsApp: An estimated ₹14-16 lakh of material was lying at job workers at any time, with the running balance maintained by one supervisor; when he was on leave, reconciliation slipped, and there had been at least one instance of a job worker claiming material that had already been received and not recorded
- Open sales orders and pending POs lived in spreadsheets: The previous attempt to introduce an ERP three years earlier had failed largely because open documents were not migrated as live records — staff had been told to "re-enter them as they came" and many never were, leaving the previous system always partly empty
- Month-end close took 8-10 working days: Most of which was reconciling Tally to the stores register, to the barcode tool and to the job work Excel, with the accountant manually chasing discrepancies before being able to close
The Migration Plan That Was Followed:
- Assessment listed every data source explicitly: Two Tally companies, four production Excel files, the barcode tool's database, the job work Excel, and a one-time exercise to capture WhatsApp-only decisions that needed to land in the system; each source was scoped as in or out before any work began, ending the previous project's habit of sources surfacing mid-rollout
- Cleansing was a six-week exercise, not a weekend pass: Party masters were deduplicated — the four-way Tier-1 customer collapsed to one master with multiple GSTIN-tagged shipping addresses; item masters were merged where duplicates existed, units standardised, and HSN codes validated against the current GST master list, fixing the 18% that were missing or outdated; dead ledgers were retired so the new chart of accounts started clean
- Mapping was captured in a single sheet: Tally ledger groups mapped to the new chart of accounts, item categories to the new product hierarchy, branch codes to godowns; the mapping sheet became the repeatable rule book so the second and third mock runs produced identical results to the same source data
- Three mock migrations were run before cutover: The first surfaced 240 master-data issues and a GST mapping gap; the second proved the fixes and surfaced the FIFO-vs-weighted-average decision; the third was a full rehearsal that matched trial balance, stock value and outstanding to the rupee against Tally — and that was the moment the accounts team stopped being sceptical
- Inventory valuation cutover was decided in writing: The decision was to take the closing weighted-average value from Tally as a single opening cost layer in ApicalERP and let FIFO take over from day one, rather than attempt to reconstruct historic FIFO layers; documented, signed off by the CA, and applied at load
- Cutover landed on a clean month-end aligned to GST: Final exports were taken on the cut-off Saturday, the verified import ran Sunday, open sales orders, pending POs, open job work challans and unreconciled receipts were loaded as live records, and the team started Monday on ApicalERP with reconciled opening numbers — the first time in the project's history the new system genuinely opened ready to use
- Tally ran in parallel for one full GST cycle: Finance reconciled the new GSTR-1 and GSTR-3B against what Tally would have shown; after one clean monthly close that matched, Tally was retired to read-only archive
Results After the Migration (within the first year):
- The unaccounted job work material was traced and recovered: Migrating open job work challans as live records, plus the cleansing exercise that matched material sent against material returned for every outside processor, brought the unaccounted material down from an estimated ₹14-16 lakh to under ₹3 lakh of genuinely in-process stock — recovering roughly ₹12 lakh of working capital that had effectively been lost in spreadsheet handovers
- Stock value and the floor finally agreed: The pre-cutover physical count and the new continuous tracking dropped the routine ₹6-8 lakh month-end variance to near zero; the accounts team stopped absorbing adjustment entries each month, and stock numbers became something dispatch and sales could quote from with confidence
- HSN cleanup ended the monthly GSTR-1 manual pass: With every HSN code validated and current at import, GSTR-1 exports from ApicalERP went directly to the portal without the cleanup step, saving the accountant an estimated 2 working days per month — about 24 days a year of recovered finance capacity
- The four-way Tier-1 customer became one: Outstanding reports stopped being split, payment follow-up stopped landing on the wrong ledger, and the sales team could finally see the true exposure at a single customer at a glance — leading to a structured collection conversation that recovered an additional ₹6-7 lakh of long-overdue receivables in the first quarter alone
- Month-end close dropped from 8-10 days to about 2: Because the reconciliation work that used to happen at close had been done once at migration and was now maintained continuously, the accountant freed about a week each month for receivables work and management reporting rather than gap-chasing
- The previous failed attempt's lesson was honoured: Open documents were migrated as live records this time, so staff did not have to "re-enter them as they came"; the new system opened genuinely ready to use, which was the single difference between a rollout that stuck and the one three years earlier that had quietly failed
Total Annual Financial Impact: Roughly ₹12 lakh of working capital recovered from job work material that had been untracked; an additional ₹6-7 lakh of long-overdue receivables recovered once the duplicated customer ledgers were collapsed into one and exposure became visible; month-end close cut from 8-10 days to about 2, freeing an estimated ₹4-5 lakh of recovered accounts-team capacity each year and accelerating receivables visibility; elimination of the monthly GSTR-1 cleanup pass, saving roughly 24 finance-days a year; and — hardest to price but most important to the family — a migration that actually landed where the previous attempt had failed, giving the business a system it runs on instead of one it works around. The plant head's summary at the year-end review: the previous attempt had not failed because the software was wrong; it had failed because the data was never cleaned, never reconciled and never rehearsed. This time every step had a reconciliation, a sign-off and a mock run before it went live — and that was what made the difference.
Key Success Factors: Cleansing the masters in the export sheet over six weeks, before any import — the decision that single-handedly fixed the four-way customer, the missing HSN codes and the dead ledgers. Three mock runs with full reconciliation against Tally, so the cutover was rehearsal, not first attempt. Reconciling trial balance, stock and outstanding to the rupee before go-live, with written CA sign-off — the proof that ended the accounts team's scepticism. Migrating open documents as live records, learning from the previous failed attempt. And running Tally in parallel for one full GST cycle before retiring it, so finance never had to take the new numbers on faith — they proved them first.
Common Migration Mistakes to Avoid
ERP migrations fail in a small set of predictable ways. Naming them in advance is the cheapest protection.
- Treating migration as a weekend technical task. Cleansing, mapping, mock runs and reconciliation are weeks of work, not a Saturday-Sunday import job.
- Importing dirty masters and planning to clean later. Every duplicate and wrong HSN code imported as-is breaks reports immediately and costs many times more to fix inside the new ERP.
- Skipping mock runs. If cutover is the first time the real import is attempted, every issue surfaces under maximum pressure with no time to fix it.
- Loading historic transactions "for completeness". Multiplies cleanup time and rarely earns its cost. Opening balances plus current year is almost always the right cut.
- Forgetting open documents. If unbilled sales orders, pending POs and open job work challans are not migrated as live records, many will simply never be re-entered.
- Cutover in the middle of a GST period. Splits return data across two systems and creates an audit reconciliation problem. Cutover belongs at a clean month-end.
- No written sign-off on opening balances. Without finance formally signing that the three reconciliations tie to the rupee, scepticism lingers indefinitely.
- Retiring the old system too early — or too late. One full GST cycle in parallel, then retire to read-only. Either extreme undermines trust.
Frequently Asked Questions
How long does ERP data migration take for an Indian SMB?
Focused data migration usually takes 3 to 6 weeks inside the wider implementation. About half is cleansing — merging duplicate parties, fixing units and HSN codes — and the other half is mapping, mock loads and reconciliation. The cutover itself is a single weekend, but only after two or three mock runs have proven trial balance, stock value and outstanding tie to the rupee against the old system.
Do we migrate historic transactions or only opening balances?
Go-live opening balances plus the current financial year's transactions is the right balance for most Indian SMBs. Bringing in five or seven years of vouchers multiplies cleanup time and rarely earns its cost — historic data lives in the closed old system for audit reference. Open documents that must continue (unbilled SOs, pending POs, open job work challans, unreconciled receipts) are migrated as live records, not history.
What is the biggest landmine in ERP data migration?
Duplicate and inconsistent master data — the same party spelt four ways, the same item under two codes, units recorded as KGS in one place and KG in another, HSN codes missing or wrong. If duplicates are imported as-is, every report afterwards is split across the variants and finance loses trust within the first close. Cleansing must happen before import, in the export sheet.
How do we reconcile opening balances against Tally?
Three reconciliations have to tie to the rupee — trial balance (group totals match Tally), stock value (item-wise quantity and valuation matches the stores register and Tally stock summary), and outstanding (party-wise receivables and payables match Tally outstanding reports). Any difference is investigated and fixed before go-live. Once these match, finance has the proof to sign off and switch.
Do we need a parallel run after data migration?
Yes. Running the old system in parallel for one full GST cycle is the safest practice. The team enters live transactions in the new ERP and finance reconciles GSTR-1 and GSTR-3B against what the old system would have shown. After one clean monthly close that matches, the old software is retired to read-only archive. Skipping parallel run is how migrations end up reversed.
Conclusion
Data migration is the phase that quietly decides whether an ERP becomes the system the business runs on or another one it works around. Software, configuration and training matter, but if opening numbers do not tie back to Tally and stock value does not match the floor, no amount of well-designed screens will earn the team's trust. The migrations that land cleanly treat the work as weeks of disciplined cleansing, mapping, mock runs and reconciliation — not a weekend technical task.
The phased plan — assess, cleanse, map, mock, cutover, reconcile, parallel run — is not glamorous and is not negotiable. Each phase exists because skipping it produces a predictable failure: dirty data nobody trusts, GST mismatches at the first return, stock values that drift from reality, open documents that never made it across. For Indian SMBs the realities are local — Tally as the starting point, Excel and standalone tools as the sprawl, GST-aligned cutoffs as the rhythm. If you are planning the wider project, the ERP implementation roadmap and the ERP selection checklist sit either side of this work, and the full ApicalERP feature set and manufacturing solution show what the cleaned, reconciled data goes on to power.
ApicalERP is migrated this way by design — templates, duplicate detection, GST and HSN validation, mock runs and full reconciliation against your existing Tally — so the cutover earns trust on day one. Bring us your data sources and we will plan an honest migration with you and prove the numbers tie out before you commit.