Ask someone why they are still on software they complain about weekly and the answer is almost never a feature. It is six hundred customers, two thousand stock items, and nobody with a spare fortnight to type them again.
Your masters are already a file
Tally can export its list of accounts as XML. Gateway of Tally → Display More Reports → List of Accounts → Export (Alt+E) → Format: XML. That single file contains your ledgers and your stock items with the details attached — GSTIN, state, phone, address on the ledger side; HSN, unit, rate on the stock side.
That is the part worth carrying across. Not the transactions — those stay where they are, in a system that already has them and can still be opened. The masters are what you would otherwise retype, and they are the only thing you actually need on day one.
A ledger is not automatically a customer
This is where a naive import goes wrong. Tally's list of accounts contains everything: your bank accounts, your suppliers, your expense heads, your capital account. Pulling all of it in as customers gives you a customer list with "HDFC Bank Current A/c" in it, and someone spends an afternoon deleting rows.
The group is what decides it. Ledgers under Sundry Debtors are the people who owe you money — those are customers. Sundry Creditors are suppliers. Bank Accounts are neither. A good import reads the group and keeps only what belongs.
The number to look at is not how many it read
Any import can tell you it scanned a file. The useful pair of numbers is how many entries it looked at and how many it kept — because the gap between them is the import doing its job. Eight ledgers scanned and six customers found means two things were correctly left out. Eight and eight would be the suspicious answer.
What happens to a half-filled record
Real master data is untidy. Some customers have a GSTIN, some do not. Some have a phone in one field and some in another. A sensible import fills in what it can and leaves the rest blank rather than guessing:
- A valid GSTIN gives you the state for free — the first two digits are the state code.
- No GSTIN, but a state name on the ledger, and the state can still be derived from the name.
- A GSTIN that does not match the expected shape should be dropped, not stored. A wrong GSTIN is worse than an empty one, because it will decide the tax split on an invoice.
- A phone number arrives with spaces, country codes and dashes, and should be normalised to the ten digits you would actually dial.
Running it twice should be safe
You will run an import more than once — a first pass to see what happens, then the real one, then again three months later when a batch of new parties has been added in the old system. Matching on name and skipping what already exists is what makes that safe. Without it, the second run doubles your customer list.
How this looks in BizGST Pro
One screen under Settings. Choose the .xml file and it is parsed **in your browser** — the file is not uploaded anywhere. You then see four counts (ledgers scanned, customers found, stock items scanned, items found), a preview of the first eight of each with the fields that were actually extracted, and a button that says exactly how many records it is about to create. Anything already in your account by the same name is skipped.
What this article does not cover
Any requirement about migrating records, what must be preserved from the old system and for how long, or how a change of software is treated for tax. Those are set by rules that change and the sources are the GST portal and your accountant. What is above is about not doing three days of typing.