Migrating off Tally is mostly a discipline problem, not a technology problem. The data export is mechanical, the import is mechanical, and most modern manufacturing ERPs (ours included) handle 80% of the mapping automatically. What actually slows the migration down is the human decisions in the middle — which ledgers to merge, which customers to dedupe, which obsolete items to retire, and who has the authority to make those calls without rerouting through the founder for every question.
This playbook is written for the operations owner who has been told to “just get us off Tally by month-end.” If that is you, read this once end-to-end before you touch a single export. The order matters more than the speed.
Pre-flight: Days -3 to 0
Four things must happen before Day 1, or the rest slips by a week.
1. Pick one migration owner
One person. Not a committee. The migration owner makes every mapping call, decides every dedupe question, signs off on every cutover step. In a 50-person factory this is usually the founder, the operations head, or the finance lead. If three people are deciding, nobody is deciding.
2. Set a hard data-freeze date for Tally
On the freeze date, no new sales invoices, purchase entries, or stock journals get posted to Tally. Everything from the freeze date onward goes into the new ERP. The freeze date is usually 24-48 hours before Day 1 of the playbook. Without a freeze, the data you export on Monday is stale by Tuesday and you re-do the work.
3. Take an offline Tally backup
Full backup of the Tally company folder, not just an export. Store it on a separate drive. You will not need it — until you do, two weeks after go-live, when someone asks about an invoice from January and your CA wants the original voucher.
4. List every custom voucher type and ledger in use
Open Tally → Display → List of Accounts. Print the chart of accounts and the voucher type list. Walk through it with the finance person and mark each entry as KEEP / MERGE / RETIRE. This is the input to Day 3, the slowest day in the playbook. Doing it during pre-flight saves the most time.
The factories that finished in 7 days did this pre-flight properly. The ones that took 14 days skipped it and discovered on Day 3 that nobody could decide whether “Freight Outward” and “Transportation Charges” should be merged. Decisions delayed at this stage compound every day after.
Day 1-2: Export masters from Tally
Day 1-2
Export the masters
Everything that does not change daily — the static data your factory references when posting a transaction.
- Chart of accounts (all ledgers with their groups)
- Items / stock items with HSN codes, UoM, GST rate, opening stock placeholder (real values come Day 4)
- Customers (Sundry Debtors) with GSTIN, addresses, payment terms, credit limits
- Vendors (Sundry Creditors) with GSTIN, addresses, payment terms
- Godowns / warehouses
- Units of measure and any compound-UoM conversions
- HSN/SAC codes with rate slabs
- Job workers if you track them as a master (most Tally setups don't — they live as a customer/vendor sub-ledger)
- Bill of Materials from Tally if you maintain BOMs there. Most factories actually maintain BOMs in Excel and re-import to the new ERP from there.
Tally exports to Excel via the standard Export → Other Formats → Excel option. For larger datasets, the XML export is cleaner. Either way, the output is a spreadsheet per master. Save them in a versioned folder (masters-v1/, masters-v2/) so you can always roll back to a known-good state.
The dedupe pass nobody warns you about
Every Tally company we have ever opened had duplicate customers. Sharma Industries and Sharma Inds. and SHARMA INDUSTRIES P LTD are usually the same vendor whose name got entered three different ways by three different people over four years. Same for items: Nut M8, M8 Nut, Bolt-Nut-M8. The fastest dedupe is a 30-minute meeting with the finance person and the senior storekeeper, looking at the export side by side, calling them out from memory.
Day 3: Map the chart of accounts
The slowest day. Even with automated suggestions, this needs human judgment for 20-50 of your ledgers.
The new ERP has its own chart-of-accounts structure (group → sub-group → ledger). You have to decide, for every Tally ledger, where it lands in the new structure. The mechanical 80% is straightforward: Cash → Cash-in-hand, HDFC Current → Bank Accounts, SGST Input 18% → GST Input Tax Credit. The 20% that requires thought:
- Multiple input GST ledgers. Many Tally setups have GST Input 5%, GST Input 12%, GST Input 18% as separate ledgers. Most modern ERPs use one consolidated input ledger with the rate captured at line-item level. Merge.
- Sub-vendor ledgers. Some factories create a sub-ledger per vendor under Sundry Creditors. The new ERP handles this via the vendor master, not the chart of accounts. Collapse all sub-ledgers into the vendor record.
- Discount, freight, packing, insurance. Tally usually has these as separate income/expense heads. The new ERP probably has line-level discount and freight built in. Decide: keep the separate ledger (for reporting) or absorb into line-level (for clean data).
- Obsolete ledgers. Anything with zero activity in the last 12 months should be retired, not migrated.
Output of Day 3: a signed-off mapping spreadsheet, two columns — Tally ledger on the left, new ERP account on the right. This is the artefact your CA needs to attest the migration.
Day 4: Opening stock and opening trial balance
Day 4
Import opening balances
The numerical foundation. Get this wrong and every report from Day 7 onwards will be slightly off.
- Opening stock per item, per godown, per batch (and expiry, for chemicals / food). Valuations should match the closing valuation report from Tally on the freeze date.
- Opening trial balance — the closing trial balance from Tally on the freeze date becomes the opening balance in the new ERP.
- Customer balances (open debtor invoices per customer)
- Vendor balances (open creditor invoices per vendor)
Reconcile two totals before moving on:
- Trial balance closing total in Tally == Trial balance opening total in new ERP. To the rupee. If there is a delta, find it. The most common cause is a forgotten suspense / round-off ledger that didn't get mapped.
- Total stock value in Tally == Total stock value in new ERP. Common cause of delta: items with multiple UoMs where the conversion factor is wrong in one system.
The trial balance reconciliation is the one thing your CA will be asked about at the next audit. Loop them in for 30 minutes, send them both reports, get their email confirming the reconciliation. Do this on Day 4, not on Day 7.
Day 5: Open transactions and WIP
Day 5
Import the open work
Anything that is in-progress at the freeze date and will be invoiced, dispatched, or received after the cutover.
- Open sales orders (not yet dispatched)
- Open purchase orders (not yet received)
- Work-in-progress on the shop floor — partly completed work orders with their current operation
- Open job-work challans — material sent to a job worker that hasn't returned yet (this is where the new ERP starts the ITC-04 clock; see our ITC-04 guide)
- Outstanding debtor and creditor invoices — the invoices behind the customer/vendor balances imported on Day 4
Closed historical transactions — everything that is already paid and settled — stay in Tally. Do not migrate them. Importing closed history doubles your migration time, risks introducing rounding deltas, and the new ERP’s reports are not designed to look back into a prior FY anyway.
Day 6: Parallel run
Day 6
One day in both systems
Every transaction posted on this day goes into both Tally and the new ERP. At end of day, reconcile.
- Sales invoices total — both systems
- Purchase entries total — both systems
- Stock movements (issues, receipts, transfers) — both systems
- Trial balance — both systems
The point of parallel run is not to find data-entry errors (you will find some, that’s expected). It is to find workflow gaps — where someone says “wait, how do I post a credit note in this system?” on a live transaction. Better to find that on Day 6 with Tally as a fallback than on Day 7 with no safety net.
What we tell launch customers
Parallel run is one full operating day, end to end. Not two days, not a week. After one day you have enough signal to spot 90% of process gaps, and continuing parallel-run longer increases the burden on your team without finding new issues. The trade-off is sharper after one day — commit to Day 7.
Day 7: Go-live and Tally close-out
Day 7
Cutover
The new ERP becomes the system of record. Tally goes read-only for historical lookups.
- All new transactions go into the new ERP only
- Tally users get read-only access
- Print and frame the Day 4 trial balance reconciliation (we are only half joking)
- Schedule the 7-day, 30-day, and 90-day post-go-live reviews
For the next 60-90 days, expect 3-5 small questions per day from the team. “Where is the e-way bill printout?”, “How do I add a freight charge to a delivery?”, “The GSTR-1 report shows a different total than I expected.” Have one person on the OEMup side and one on your side dedicated to these questions for the first month. Volume drops to near-zero by week 6.
5 things that always go wrong (and how to handle)
1. The trial balance doesn’t match on Day 4
The classic cause is a hidden suspense ledger in Tally with a small balance that nobody mapped. Sometimes it’s a round-off entry, sometimes it’s a stale opening entry from three years ago.
Fix: open both trial balances side by side, sort by amount descending, find the row that doesn’t have a counterpart. It will be obvious once you look.2. Stock valuations differ by a few rupees per item
Tally uses one of three stock-valuation methods (FIFO, weighted average, fixed cost). The new ERP may default to a different one. If you don’t set them the same, the closing valuation in Tally and the opening valuation in the new ERP will be off.
Fix: confirm the valuation method on Day 1, not Day 4. Most factories use weighted average; some use FIFO for items with expiry.3. Customer GSTINs don’t validate against the GSTN portal
Half the customer GSTINs in long-running Tally databases are stale, mistyped, or belong to a now-cancelled registration. The new ERP will refuse to generate an e-invoice for these.
Fix: run a bulk GSTIN validation as part of Day 1-2 master export. The new ERP usually has this built in. Flag invalid ones for the sales team to update with the customer.4. The BOM in Tally doesn’t match the BOM the production team actually uses
Tally BOMs were maintained for the accounting journal. The actual production BOM lives in the supervisor’s Excel sheet or his head. They are not the same. The new ERP wants the real BOM.
Fix: walk the shop floor with the supervisor and rebuild the BOM from scratch in the new ERP for your top 20 SKUs by volume. Tail SKUs can be lazily imported and corrected over the first month.5. The CA didn’t sign off and the migration month’s GSTR-1 doesn’t balance
If the cutover happens mid-month, GSTR-1 for that month draws data from both systems. Without explicit CA sign-off on which invoices come from where, the filing can double-count or miss invoices.
Fix: cut over on the 1st of a month whenever possible. If not, prepare a one-page hand-off memo for the CA listing exactly which invoice numbers came from Tally and which from the new ERP for the migration month.When not to migrate (stay on Tally)
This playbook assumes you have already decided to switch. If you are still deciding, three signals say stay on Tally for now:
- You have fewer than 5 active users and your finance person is genuinely happy with Tally.
- You don’t do job-work or sub-contracting. Tally’s manufacturing limitations bite hardest at job-work; if you don’t do any, you avoid the worst pain.
- You will replace the system in <18 months anyway — perhaps after a merger, an acquisition, or a planned ERP RFP. Don’t migrate twice.
For the full vs-Tally analysis with feature table and 3-year TCO, see OEMup vs Tally: Which ERP Actually Fits an Indian Manufacturer?. For the operational case — the five concrete things Tally cannot do for a factory — see 5 Things Tally Cannot Do That a Manufacturing ERP Can.
Bring a Tally backup to your demo
The fastest way to see whether OEMup fits your factory: send us a sample Tally backup before your demo. We’ll import your masters, opening trial balance, and one open work order live during the 20-minute call.
Book a Demo →FAQ
How long does a Tally-to-ERP migration actually take?
For a single-location Indian manufacturing SME with under 10 users, 7 working days is realistic for the basics — masters, opening balances, open orders, parallel run, go-live. Full deployment of every module (HRMS, payroll, BI dashboards) usually takes 2-4 more weeks of training and tuning.
Should I import all my historical Tally data into the new ERP?
No. Import only opening balances and open transactions. Closed historical vouchers should stay in Tally as read-only archives. Importing closed history doubles the migration time and risks corrupting the trial balance with rounding differences.
When during the year should I cut over from Tally?
The cleanest cut is 1 April of a new financial year — the new ERP runs the entire FY from day one, and Tally becomes a closed archive of prior years. Mid-year migration is possible but it forces you to carry a half-year opening trial balance and split GSTR-1/3B filings between the two systems for one cycle.
What happens to my Tally licence after migration?
Keep it active for at least 18 months after go-live. You’ll need read-only access for GST returns of the migrated year, audit queries, and the occasional historical lookup. After 18-24 months, when all open audits and returns are closed, you can let the licence lapse.
How do we handle GSTR-1 and GSTR-3B during the migration month?
File the migration month from whichever system holds the majority of the period. If you cut over on the 15th, file from Tally for that month (it has 15 days of data) and start fresh from the new ERP next month. We recommend a clean 1st-of-the-month cutover to avoid this entirely.
Do we need our CA’s involvement?
Yes. Your CA should sign off on the closing trial balance from Tally and the opening trial balance in the new ERP. They are the same number, but they live in two systems and the CA is the person who attests they reconcile. Brief them a week before cutover so they aren’t surprised at filing time.
What if our team resists the change?
Resistance is almost always about workflow change, not the software. Sit with the two or three power users in Tally for 60 minutes each before Day 1 and walk them through how their daily tasks look in the new ERP. People who feel consulted during pre-flight rarely resist on Day 7.