Leaving QuickBooks: What Comes With You and What Does Not

The finance manager is relaxed about the migration because the accounting data is small and clean. Six years of transactions, a chart of accounts with about a hundred and forty lines, a customer list, a supplier list. She is right that this transfers without drama.

What she has not accounted for is that the company does not actually run on QuickBooks. It runs on QuickBooks plus eleven spreadsheets, a shared folder of quotations, a stock count somebody maintains monthly, a pricing file with four versions in circulation, and the fact that three people know which customers are allowed to exceed their credit limit. The accounting package holds the record of what happened. The business logic lives everywhere else.

That is the migration. Not the ledger — the everything else, most of which has never been written down, some of which is contradictory, and all of which the new system will insist on knowing before it will let anybody raise an invoice. It is the concrete version of the condition that starts almost every selection exercise in the complete guide to choosing an ERP here — the package did not fail, it simply stopped being where the company's operations lived.

What transfers easily

Be clear about the easy half, because it is where most of the planning effort mistakenly goes.

Master records. Customers, suppliers, the chart of accounts, the item list. These export cleanly from any of the small packages — QuickBooks, Tally, Zoho Books — and import cleanly. The work here is cleaning rather than moving, and the cleaning is worth doing before the export rather than after, because a duplicate customer imported is a duplicate customer for ever.

Open balances. Trial balance at the cutover date, open customer invoices, open supplier bills, bank balances. This is the standard and correct approach: bring the position, not the history.

Open documents. Unfulfilled sales orders, outstanding purchase orders, undelivered items. Modest in volume and important to get right, because these are what people will be working on in week one.

Everything in that list is a known exercise with a known method. If a proposal treats it as the hard part, the proposal has not understood the project.

What does not transfer, and has to be built

Historical detail. Transaction-level history usually stays behind. The correct pattern is to bring balances forward and keep the old system readable for a defined period, or take an export and archive it in a form somebody can query. Migrating six years of transaction detail is expensive, it imports data structured by a different product's assumptions, and it is almost never used. Decide this deliberately rather than by omission, and check what your retention obligations require before you switch anything off.

Stock, properly. This is the largest single piece of work in most of these migrations and it is not a data problem. The accounting package tracked stock by value, or by quantity with no locations, or not at all. The new system wants locations, unit costs, valuation method, and a count that is actually true on the day. Almost every company discovers at this point that its stock figure has been an estimate — which is the general condition rather than a local embarrassment, and it is far better discovered in a migration than in an audit.

Pricing and discount rules. In the small package there were no price lists; there was a spreadsheet and a sales manager. The new system will ask which customer gets which price, on what basis, and who can override it. This is a business decision nobody has ever had to make explicitly, and it takes longer than expected because the honest answer is often that the rules are inconsistent.

Credit control. Who has a limit, what it is, what happens when they exceed it. Currently this is judgement exercised by a person. The new system will enforce whatever you tell it, which means somebody has to decide.

Approvals. The small package had none, and the control was that the owner saw everything. The new system can enforce thresholds, and the temptation is to enforce many. Start with few, because an approval nobody has time for produces a workaround rather than a control.

Documents. Quotations, delivery notes, signed acknowledgements, supplier invoices — currently in email and folders. Deciding what lives inside the new system and what stays outside is a decision that gets made by default if nobody makes it deliberately.

The three arguments that actually happen

The chart of accounts. Everybody agrees it needs restructuring and nobody wants to do it at the same time as the migration. The right answer is usually to fix it now, because you are re-entering the opening balances anyway and this is the last cheap opportunity you will have. The wrong answer is to redesign it into something twice the size in the belief that more accounts equals better reporting; the analysis you want almost always belongs on dimensions — department, project, cost centre — rather than on account codes.

How much history to bring. Finance wants everything, the budget wants nothing. Balances plus one comparative year satisfies almost everybody and is defensible; anything more should have a named person who says what they will do with it.

Whether to change processes now or later. The honest answer is that you have no choice about some of it. A system that requires a purchase order before a supplier invoice changes how purchasing works on day one whether you planned it or not. The list of process changes forced by the software should be written down during selection, not discovered during training, and it is the substance of what the cutover weekend is actually for.

Sequencing that works

Choose a cutover date at a period end, and ideally a quiet one. A month end is the minimum, a quarter end is better, and the financial year end is best if the timing is anywhere near it. Migrating mid-period means running two sets of figures and reconciling them, which is a genuine cost.

Clean the master data before the export, not after. Duplicates, dead customers, items nobody has sold in three years, suppliers who no longer exist. Doing this in the old system is faster and the result is checkable by the people who know.

Count the stock properly, once, close to the date. Not a rolling estimate. A real count, reconciled, with the differences written off deliberately. If this is not done, the new system starts with a wrong number and everybody blames the new system for the next six months.

Run parallel for one period only, and decide in advance what "passing" means. Parallel running is expensive and it decays fast — people stop maintaining the old system honestly by week three. One period, with a defined test: the trial balance agrees, the aged receivables agree, the stock valuation agrees.

Keep the old system readable, not running. Read-only access for a defined period costs almost nothing and removes the argument for migrating history you will never use.

The mistake specific to this migration

Companies leaving a small accounting package tend to make one particular error: they buy a system sized for the company they want to be and implement it as though it were the package they are leaving.

The symptom is that six months later, the ERP is being used as an accounting system with a much worse interface. Stock is still counted in a spreadsheet, quotations are still in a folder, the approvals were switched off because they were slow, and the only thing that changed is the licence cost.

That happens for an understandable reason: the accounting package required nothing of anybody, and the new system requires discipline from people who never needed it. The remedy is not more training. It is to pick two or three operational processes — stock, purchasing, quotations — and insist that they genuinely move, with an owner each, rather than deploying everything and letting each area choose. The comparison work behind that choice is set out in what changes when you move up from a small package.

The short version

The accounting data is the easy part and it is where most migration planning goes. Master records, open balances and open documents transfer with known methods.

What does not transfer is everything the package never held: stock with locations and a true count, pricing rules that were previously a spreadsheet and a person, credit limits that were previously judgement, approvals that did not exist, and documents that live in email. Those are business decisions, not data tasks, and they are the project.

So fix the chart of accounts now while you are re-entering balances anyway, bring balances plus one comparative year rather than six years of detail, count the stock for real before you start, run parallel for exactly one period against a defined test, and keep the old system readable rather than migrating history nobody will query.

And insist that two or three operational processes actually move, with a named owner each. A company that migrates the ledger and nothing else has bought a more expensive accounting package, which is the one outcome that makes the whole exercise indefensible — and the way to avoid it is to name those processes during scoping rather than during training.