A business that has run on Tally or an on-premise ERP for ten years is not running on software. It is running on software plus a decade of accumulated convention: how a particular ledger is used, which fields were repurposed for something they were not designed for, what a specific narration prefix means, and which reports are trusted versus which are politely ignored. The migration project is mostly about surfacing that, and teams that scope it as a data transfer discover this in month three.
Start with the reports, not the data. Ask which reports the business actually acts on — usually a much smaller set than the ones that exist — and work backwards to the data each one needs. This does two useful things: it bounds the migration to what matters, and it produces an acceptance test that a finance team recognises. A migration is done when the numbers on the reports they use match. Nothing else is a credible definition, and everything else is an argument.
Expect the master data to be worse than described. Duplicate ledgers for the same party created by different people, inconsistent naming, parties that are one entity in reality and three in the system, tax classifications applied inconsistently across years. This is normal and it is not a criticism of the previous team — it is what a decade of operational reality looks like. Cleansing it is a real workstream with a real owner, and it cannot be done by the technical team alone because only the business knows which of two similar ledgers is the real one.
Decide deliberately how much history to bring. Everything is the instinctive answer and usually the wrong one. Opening balances plus two or three years of transactional detail covers almost every operational and statutory need, with the legacy system retained read-only for anything older. Carrying fifteen years of transactions into a new system multiplies both the reconciliation effort and the number of ways the migration can be declared wrong.
Run parallel for at least one full cycle, and pick the cycle deliberately — a month that includes a statutory filing, not a quiet one. Parallel running is unpopular because it means doing the work twice, and it is the only thing that reliably prevents a cutover from becoming an incident. The value is not just in catching errors; it is in the finance team building confidence in the new system before their filing deadline depends on it.
Finally, name what the business gains, because migrations sold purely as modernisation lose support the moment they become inconvenient. Multi-user access without a remote desktop session, real backups, an audit trail, integration with the systems that currently receive data by exported spreadsheet, and access from outside the office are concrete benefits people can feel. Being on the cloud is not one, and framing it that way invites the question of why they should tolerate the disruption.
