Switching from Tally or Marg: a practical checklist before you move
Most failed migrations are not technical. They fail because the data was not ready, the cutover date was wrong, or nobody planned for the three weeks where staff are slower on the new system than the old one. This is the list we work through with customers.
The person who will actually do this
If you are the proprietor, an accountant, or whoever got handed the project, this is for you. It assumes nothing about which system you are leaving — the preparation is the same whether you are on a desktop accounting package, a billing tool plus spreadsheets, or a mix of both.
It also assumes you have already decided to move. If you have not, read the choosing guide first; the honest answer for a lot of businesses is that their current setup is fine.
- Businesses moving off a desktop accounting or billing package
- Distributors carrying stock with batches and expiry dates to bring across
- Companies with more than one branch or godown to set up
- Anyone who has been told the migration “just imports” and is rightly suspicious
Get the masters right before anything else
Masters are the part everyone underestimates. Transactions can be rebuilt; a bad chart of accounts will be with you for years. Do this part slowly and the rest gets easier.
The useful discipline is to treat the move as a chance to clean rather than a straight copy. Most party lists that have been running for a decade contain duplicates, dead accounts and three spellings of the same firm.
- Chart of accounts. Decide the structure you want, not the one you inherited. Group parties properly while it is cheap to do so.
- Parties. De-duplicate customers and suppliers. Note which ones are both — those are the records that go wrong in systems that keep two lists.
- Items. Clean the item master: codes, units, HSN, MRP where you use it, and which items need batch or serial tracking.
- Branches and godowns. List every location, with its state and tax registration. This drives most of the rest of the setup.
- Users and roles. Decide who should be able to edit and delete before go-live, not after the first incident.
Opening balances and stock
Pick a cutover date first — usually the start of a month or a financial year — and work backwards from it. Everything in this step is “as at” that date.
Stock is the part that catches distributors out. A plain quantity per item is quick to produce and useless six months later if your business runs on batches. Bring the stock across at the level of detail you will need to operate, not the level that is easiest to export.
- Trial balance as at the cutover date, agreed and signed off. If it does not balance in the old system it will not balance in the new one.
- Party-wise outstanding, both receivable and payable, ideally bill-wise rather than as a single net figure per party.
- Stock quantities with batch, expiry and MRP where you track them, per godown rather than as a company total.
- Open orders and pending challans — what has been promised and what has moved but not been invoiced.
- Bank balances and unreconciled items, so the first reconciliation in the new system starts from a known position.
Run in parallel, briefly and deliberately
A parallel run means entering the same transactions in both systems for a fixed period. It is genuinely painful, which is why it should be short and have an end date decided in advance — two to four weeks is usually enough to expose problems without exhausting the team.
The point is not to prove the new system works in general. It is to compare specific outputs and find the places where your business does something the setup did not anticipate.
Fix the period
Decide the dates before you start, and decide what would make you extend them. Open-ended parallel runs never end.
Enter everything twice
Sales, purchases, receipts and payments. Skipping the awkward ones defeats the purpose — those are exactly where systems differ.
Compare the outputs, not the screens
Daily sales, party balances, stock per godown and the tax summary. Differences are information, not failure.
Decide and commit
At the end of the window, pick a date and stop dual entry. Keeping both running “just in case” is how businesses end up with two half-maintained sets of books.
The people, who are the actual risk
Staff who are fast on the system they know will be slow on a new one, and that dip is the real cost of switching. It is also temporary and largely manageable, if you plan for it rather than hope.
Train on your own data, not on a demo company. People learn the screens quickly; what takes time is learning where their particular awkward cases go. Pick the two or three staff who will become the internal answer-givers and train them deeper than everybody else.
Finally, expect the first month-end close to take longer than usual, and do not schedule the cutover for a month when something else important is happening.
Questions we get asked
How long does a migration take?
It depends almost entirely on how ready the masters and opening balances are. The software setup is the short part; cleaning the data is the long one.
Can we bring our full transaction history across?
That gets scoped case by case. Many businesses bring opening balances plus the current year and keep the old system available read-only for history.
Do we have to run in parallel?
It is not mandatory, but for a business of any size it is the cheapest way to find the problems. Keep it short and give it an end date.
What about stock with batches and expiry?
Bring it across per godown with batch, expiry and MRP intact. A plain quantity is quicker to produce and much harder to live with afterwards.
When is the best time to switch?
Usually the start of a month, with a cutover date fixed in advance. Year-end is tidier for reporting but lands when your accounting staff are already stretched.
Will you help with the migration?
Yes — scoping it is part of the demo conversation. What we will not do is promise that it imports itself.
Planning a move?
Bring your current structure to a demo and we will be direct about the effort involved — including whether it is worth it.
Book a demo