Tally does accounting extremely well. Businesses outgrow it not because it is bad, but because they start needing things it was never meant to do — production planning, multi-warehouse stock, approval workflows, role-based access across fifty users.
Decide what actually migrates
The instinct is "everything, since 2011". That is expensive and rarely useful. Our default:
- Masters — ledgers, items, parties, tax structures. All of it, cleansed.
- Opening balances — as of the cutover date. Trial balance, stock with valuation, party-wise outstanding with ageing buckets.
- Open transactions — unfulfilled orders, pending POs, unreconciled bank items.
- History — usually stays in Tally, kept read-only for reference and audit. Bringing five years of vouchers across costs weeks and gets consulted twice.
Cut over at a period boundary
Start of a financial year is ideal; start of a quarter is workable. Mid-month cutovers create a period that exists half in each system and satisfies nobody at audit.
Run parallel for exactly one period
Both systems, same transactions, one full accounting period. At the end, three reconciliations must pass:
- Trial balance matches to the rupee.
- Stock quantity and value match per warehouse.
- Party outstanding matches per party, with the same ageing buckets.
If they do not reconcile, you have found a real configuration error — which is exactly what the parallel run is for. Do not extend it to three periods "to be safe"; that just doubles everyone's data entry and burns goodwill.
The part people underestimate
Your accountant has fifteen years of Tally muscle memory. Shortcut keys, a familiar voucher flow, a report they can produce in four keystrokes. Budget real time for training, configure keyboard-first data entry, and expect a productivity dip in the first fortnight. It recovers — but only if you planned for it rather than treating it as resistance.