Most Indian SMBs considering a move to Business Central are leaving Tally. The Tally-to-BC migration is the single most common project our Business Central practice runs. The playbook below is what we've calibrated across roughly thirty of these projects. It assumes a mid-sized business — ₹50 to ₹500 crore in revenue, 20 to 200 users — and a non-negotiable need to keep the CA on board.
Why the CA matters more than vendors usually admit
Indian CAs work in Tally. They know its menus, its keyboard shortcuts, its specific quirks. A CA who has spent fifteen years closing books in Tally will not happily move to BC just because the CFO bought a new system. Ignore the CA, and the books migration becomes a fight. We've watched projects fail at this stage. We will not run another.
So the playbook starts with the CA, not with the CFO. Bring them into the project in week one. Let them keep their workflow during transition. Plan a clean cutover only when they're comfortable.
Phase 1: Discovery (weeks 1-2)
The Discovery goal is to learn enough to write the SOW. We meet the CFO, the finance head, the IT lead, the warehouse manager and the CA, in that order, separately. Each conversation is two hours. We do not show slides; we ask questions and take notes.
Outputs:
- Current Tally setup — companies, branches, ledgers, voucher types, custom features
- Pain points ranked — what specifically is breaking
- Required migration scope — masters, opening balances, history (how many years?)
- Non-Tally systems in scope — POS, Excel sheets, custom apps
- The CA's red lines — what they need to be able to do post-migration
- A list of unique processes that need AL extensions
The SOW gets signed at the end of week 2 or the project doesn't start.
Phase 2: Design (weeks 3-4)
This is schema-first work. We document the future-state BC tenant in plain English — chart of accounts mapping, customer master structure, vendor master, item master, dimensions, GST configuration, posting groups, approval workflows. The customer reads it and tells us where it's wrong.
The chart of accounts mapping is the longest single artefact. Tally's account hierarchy is flexible; BC's is structured. A line-by-line mapping document — Tally ledger → BC account → BC posting group → BC dimension — is what the CA signs off on. They will not sign until they're convinced the new structure can produce every report they currently produce in Tally.
Approval workflows, bill formats and custom fields are scoped into AL extensions in this phase. We give each extension a separate quote.
Phase 3: Build (weeks 5-8)
The BC tenant is provisioned. Masters are imported in test mode. AL extensions are written and tested in a sandbox. We run two demos:
- A mid-build demo at end of week 6 — finance team and CA see opening-balance posting, a few invoices, a few payments
- A near-complete demo at end of week 8 — full month of dummy transactions, full reporting suite
The CA's feedback at the week-6 demo is gold. They will catch things the CFO doesn't see — a missing TDS section, a wrong GSTIN format, an export invoice that needs LUT details that BC isn't capturing.
Phase 4: Migrate (weeks 9-10)
The migration weekend is when we copy real data into the new tenant. The playbook:
- Lock Tally on Friday evening — no new entries allowed
- Export masters and opening balances from Tally (Friday night)
- Import into BC (Friday night / Saturday morning)
- Manual reconciliation by the CA against trial balance (Saturday)
- Customer signs off the opening balance match (Saturday evening)
- BC goes live for Monday morning operations
The reconciliation step is the one people skip and regret. The CA needs to see that the BC trial balance matches the Tally closing trial balance to the rupee. If it doesn't, we hunt the difference before going live. We've never gone live without this match.
Phase 5: Go-live (weeks 11-12)
Monday morning, BC is the system of record for new transactions. Tally stays open for read-only access to history. Our consultant is on-site for the first 72 hours and remotely available for the next two weeks.
Issues in the first week are almost always:
- A user who doesn't know where a menu has moved
- A bill format that needs a small tweak
- A dimension that wasn't migrated correctly for a specific ledger
- An integration that needs its credentials updated
None of these are crises if we're on-site to solve them in real time. They become crises if we're not.
Phase 6: Hypercare (weeks 13-16)
Four weeks of daily standups. The customer's finance team gets used to BC. The CA learns the report packs. We measure adoption — login frequency, transactions posted in BC versus residual entries in Tally, time-to-close month-end.
The metric we watch most closely is month-end close time. Pre-migration this was typically 5–8 working days for the kind of business we work with. We expect it to lengthen for the first month-end after go-live (8–12 days is normal) and then compress to 3–5 days by month three.
What we don't do
We don't run two systems in parallel for six months. Some vendors do this; we think it's a tax on the customer. The intent of parallel running is to validate; the result is staff confusion, double-entry and a delayed cutover. Our cutover is hard — Monday morning, BC is the truth.
We also don't migrate Tally history into BC. Years of historical data don't belong in the active ERP. We export the history to a parquet archive that the CA can query separately. BC's opening balances are the snapshot; transactions roll forward from go-live.
A note on cost
A typical Tally-to-BC migration for a 50-user, ₹100-crore-revenue business runs ₹18-30 lakh for the SourceForge implementation, plus Microsoft BC licensing at around ₹4500 per user per month. AL extensions add ₹3-8 lakh depending on scope. AppSource extensions (including SourceForge's own AI Assistant and OCR Payable Agent) add monthly subscriptions. The numbers move with scale.
We quote on fixed-price for the implementation. The licensing and AppSource subscriptions are pass-through.
When this playbook doesn't apply
When the business is too small (under 10 users, under ₹10 crore revenue) — Tally is fine, save your money.
When the business is too big (over 1000 users, multi-country, complex consolidation) — you're in S/4HANA territory, not BC.
When the CA isn't on board — pause the project. Bring them in. Don't proceed without them. We've held a project at Discovery for three months waiting for the CA to be ready. It was the right call every time.