Tally to ERPNext migration, reconciled to the last trial balance

Implementations rarely fail on configuration; they fail in the first month-end, when the numbers do not match. The causes are predictable. An opening balance that does not tie to the old trial balance, so every report starts with an unexplained difference. A stock ledger that begins a week after cut-over, so valuation is wrong from day one. A customer master with three spellings of the same company, so receivables split across them. Receivables migrated as one lump per party, so no payment can be matched to an invoice and ageing is meaningless. Tax details missing on masters, so the first GST return is prepared by hand — exactly what the ERP was bought to stop.

Each of those is a migration problem, not a software problem, and none of them is visible in a demo. That is why migration is a workstream of its own in every ERPNext project we deliver, with its own plan, its own owner on your side — usually the person who closes the books — and its own deliverable: a reconciliation pack that finance signs before the first live transaction is entered. At Prem Plumbings the masters and opening balances were migrated rather than re-keyed, and the rollout was staged module by module, so the business kept trading and finance never started a period with a difference it could not explain.

Tally is our most common starting point, and it maps onto ERPNext better than its reputation suggests once the structural differences are understood. Tally's ledgers are both accounts and parties; ERPNext separates the chart of accounts from customers and suppliers, so every Tally ledger is classified before it is loaded. Tally's groups become the account tree; stock groups and items become item groups and items with units of measure; godowns become warehouses; cost centres map directly; GST registration, state and tax classifications on ledgers become the tax templates and categories ERPNext uses to compute GST on every document. The full sequence, from ledger classification to cut-over, is in the Tally to ERPNext Migration Guide.

• Extract — masters and vouchers from Tally Prime or ERP 9 via XML export, ODBC or Excel, for every company and financial year in scope
• Map — Tally groups to ERPNext's chart of accounts; ledgers to accounts, customers or suppliers; stock groups, items, units and godowns; cost centres; GST classifications to tax templates and item tax categories
• Cleanse — de-duplicate parties and items, validate GSTIN and PAN, assign HSN/SAC, standardise units and naming; your team signs off the cleaned masters
• Load masters — accounts, parties with addresses and contacts, items with valuation method, warehouses, cost centres, employees, price lists — through the Data Import tool or scripted loads with validation
• Load balances — opening trial balance as of the cut-over date, invoice-level receivables and payables, stock by warehouse and batch at valuation, bank balances, fixed assets
• Load history (if in scope) — Tally vouchers as ERPNext journal entries, sales and purchase invoices, payment entries and stock entries, with Tally voucher numbers preserved in a reference field
• Reconcile — trial balance, party outstanding, stock valuation, bank and GST liability compared line by line to Tally in a signed reconciliation report

The cut-over date decides most of the work. The start of a financial year is cleanest — one opening trial balance, no part-year history — and the start of a quarter is the usual compromise when the business cannot wait. At that date we load the trial balance by account and reconcile it to Tally's to the rupee. Receivables and payables are loaded invoice by invoice with their original dates and due dates, not as one balance per party, so that ageing reports are right on day one and every incoming payment can be matched to what it pays. Stock is loaded by item, warehouse and batch or serial number at quantity and valuation rate, and the resulting stock value is tied to the balance sheet's inventory figure. Bank balances are reconciled to statements; fixed assets are loaded with cost, accumulated depreciation and remaining schedule so depreciation continues without a break.

The reconciliation pack that comes out of this is the migration's deliverable: account-by-account, party-by-party and warehouse-by-warehouse comparisons between the old system and ERPNext, each difference explained or corrected, and a sign-off from the person who owns the books. Nobody enters a live transaction until it is signed. It is also the document the auditor asks for at year-end, which is why it is written for them rather than for us.

The instinct is to migrate everything; the right answer is to migrate what reporting needs and archive the rest. Opening balances only is the fastest and cleanest option and suits companies whose historical reporting can stay in Tally, kept as a read-only archive. Current financial year transactions are the common middle ground: comparatives, GST reconciliation and ageing all work inside ERPNext from go-live, at the cost of loading and reconciling part-year documents. Multi-year history is justified when contracts, warranties, batch traceability or a regulator require it in the live system — and it is where migration effort grows fastest, because every year's transactions must reconcile to that year's closing balances.

Whatever the depth, the old system is not deleted. Statutory retention for books of account runs for years, so Tally or the legacy ERP is kept as a read-only archive with its data exported to durable formats, and ERPNext documents carry the old voucher or invoice numbers so a query from an auditor or a customer can be traced back in seconds. GST history is a special case: filed returns stay with the period in which they were filed, and e-invoice IRNs and e-way bills generated by the old system are recorded on the migrated documents rather than regenerated.

Before the old system is switched off, both run for one closing period. Transactions are entered in Tally as usual and in ERPNext by the team who will own it, and at the period end the trial balance, GST returns, party statements and stock reports are compared line by line. Differences are almost always process — a voucher type used differently, a warehouse missed, a tax template wrong — and the parallel month is where they are found and fixed while nothing is at stake. It is also the month in which the team learns ERPNext on their own live numbers, which is better training than any workshop.

Cut-over itself is a checklist run on a date agreed with finance: transactions frozen in the old system, the final delta of balances migrated and reconciled, master data locked, users' roles confirmed, and the first documents entered in ERPNext with our consultant in the room. The rollback plan is simple because the old system is still there: if the reconciliation at cut-over does not sign, the business keeps transacting in Tally for another period and we fix the cause. A hypercare month follows, through the first month-end close, GST filing and payroll on the new system.

The other migration is the one an ERPNext already running needs: a version upgrade or a change of hosting. Upgrading from v12, v13 or v14 to v15 is a Frappe framework upgrade as much as an ERPNext one, and it goes wrong where customisations touched core or custom apps have no tests. Our approach is a copy of production on a staging bench, the upgrade run there with every custom app's tests and patches, a list of deprecated features and changed behaviour reviewed with your team — reports, print formats and integrations are the usual casualties — and a rehearsed production cut-over with a timed backup and restore so the rollback is measured in minutes.

Moving hosting — Frappe Cloud to your own AWS or Azure account for cost or control, on-premise to cloud, or an unmanaged server to a proper bench — carries the database, public and private files, site configuration, scheduled jobs and integrations across, with DNS, TLS, backups, monitoring and restore drills set up before the switch. Where data residency is a requirement, the target environment is chosen for the regulator first and for cost second.

As a guide from our own projects: a single-company Tally migration with opening balances only takes two to three weeks and runs inside the implementation; with current-year history and a reconciled parallel month it is four to six weeks; a multi-company, multi-year migration from a legacy ERP with stock, assets and integrations is two to four months. An ERPNext version upgrade is one to three weeks depending on how many custom apps and reports must be tested, and a hosting move is one to two weeks including rehearsal. The implementation page has the timelines for the rollout around the migration.

Five things set the cost: the state of your data — duplicate parties, items without units, ledgers with no tax details; the depth of history; the number of companies, warehouses and financial years; whether stock, batches, serial numbers and fixed assets are in scope; and, for upgrades, the amount of customisation and whether it was built upgrade-safe. Migration is quoted as part of the implementation's fixed price after discovery has looked at the actual data; upgrades and hosting moves are quoted as fixed-price projects after a review of the current bench.

This work fits companies moving to ERPNext from Tally, Busy, Zoho or spreadsheets — distributors and manufacturers in particular, as at Prem Plumbings; groups consolidating several companies' books onto one system; organisations replacing a legacy or licensed ERP; and anyone already on ERPNext who is two versions behind or paying too much for hosting. If you are in Saudi Arabia or the Gulf, the ZATCA and VAT specifics are on the ERPNext in Saudi Arabia page.