How to Switch Accounting Software Without Losing Your History

The reason switching accounting software goes badly is almost never the new software. It is that people treat the move as a data transfer problem when it is actually a bookkeeping problem, and they do it at a date that makes both halves of their history unusable.

Here is the thing nobody selling migration tools will lead with. You will lose detail. Not your balances, if you do this properly, and not your ability to file, but the granular transaction level history that made your old file useful for answering questions. How much did I spend with that one supplier in the second quarter of two years ago. What did returns actually cost me last November. Those questions get harder after a migration, and they get impossible if you rush the part where you preserve the old file.

This post is how I would run a switch. It is deliberately not a click by click walkthrough of any particular vendor’s importer, because migration tooling varies by vendor, by source product, by plan and by the shape of your data, and a set of instructions written today would be wrong for half the people reading it. What I can give you is the list of things to verify, the order to do them in, and the specific questions to get answered in writing before you cancel anything.

One disclaimer up front, and it appears again later because it matters. I run ecommerce stores and I price software for a living. I am not a CPA. Nothing here is tax or accounting advice, and how your opening balances should be structured, which accounting method applies to your entity and what your filing obligations are during a transition all need to be confirmed with a CPA or with the taxing authority.

The honest warning first: detail is the thing you lose

Every migration conversation focuses on balances, because balances are what an accountant checks and what a vendor can promise. Balances are the easy part. What sits underneath them is the hard part.

Think about what your current file actually contains. Individual transactions with dates, memos, attachments and categories. Reconciliation records showing which statement each line was matched against. Customer and supplier records with contact details and payment terms. Historical invoices with their line items and the exact wording you used. Recurring transaction templates. Bank rules you built up over years. Audit trail entries showing who changed what and when. Attachments, which are usually receipts and are usually the thing an auditor asks for.

Some of that moves. Some of it moves in a degraded form, arriving as summary journals rather than transactions. Some of it does not move at all, and reconciliation history and audit trail are the two that most often do not, because they are internal to the product rather than being data about your business.

That is not a reason to avoid switching. It is a reason to plan for the loss deliberately rather than discovering it. Which means two things: pick a switch date that makes the split clean, and keep the old file readable for long enough that the lost detail is still reachable when someone asks for it.

What generally transfers and what generally does not

I want to be careful with this section, because the specifics depend entirely on which product you are leaving, which you are joining, and what tooling exists between them on the day you do it. So read the table below as a list of things to verify rather than as a promise about any particular vendor.

Data	Usually straightforward	What to verify before you commit
Chart of accounts	Yes, in some form	Whether account types and numbering survive, or need remapping by hand
Customer and supplier records	Yes	Whether payment terms, tax settings and default accounts come with them
Trial balance as at the switch date	Yes, usually by manual entry	Nothing much, this is the part you control
Open invoices and open bills	Often	Whether they arrive with their original dates and ageing intact
Historical transaction detail	Sometimes, sometimes summarised	How far back, and at what level of detail
Bank reconciliation history	Frequently not	Assume it does not move and plan accordingly
Attachments and receipts	Frequently not	Export them separately before you cancel anything
Bank rules and recurring templates	Usually not	Budget time to rebuild these by hand
Inventory quantities and values	Varies widely	Whether item costs come across, and on what basis
Payroll history	Usually not	Treat as a separate project with its own advice

The inventory row deserves a note. If you hold stock, the value of that stock is a balance sheet number your accountant will care about, and how the destination product costs it going forward may not match how the source product costed it historically. Intuit’s inventory page, for example, names Amazon, Etsy and Shopify among the apps its inventory feature works with, but it does not state a costing method on that page. So if the costing basis matters to your accounts, that is a question to put to the vendor directly rather than a detail to assume carries over.

The general rule I would apply: assume anything that is a record about your business transfers, and anything that is a record about your use of the software does not. Reconciliation marks, audit trail, rules and templates all fall in the second category.

Why the switch date matters more than the tool

If you take one thing from this post, take this. Switch at a period boundary. Ideally switch at a financial year boundary.

The reason is simple. Accounting output is period based. A profit and loss statement covers a period. A tax return covers a year. If your switch date falls in the middle of a month, every report covering that month has to be assembled from two systems, and someone has to do that assembly by hand every time anyone asks a question about it. If your switch date falls in the middle of a financial year, your annual accounts have to be assembled from two systems, and that is a job your accountant will charge you for and be irritated by.

Switch on the first day of a financial year and the split is clean. The old system holds a complete, closed, reconciled year. The new system holds a complete year going forward. Every report in either system covers a whole period, and nothing has to be stitched.

Switch on the first day of a month if you cannot wait for the year. You will still have one stitched annual report, but every monthly report will be clean, which is most of the benefit.

Do not switch mid month for any reason. There is no urgency that justifies it. If the old system is intolerable, run both in parallel until the month turns rather than cutting over on a Tuesday.

The corollary is that a switch is a planned event with a date in the calendar, not something you do on the afternoon you get annoyed with your current software. Give yourself the run up. If you are still deciding on the destination rather than the date, the elimination method in my guide to the five gates that decide accounting software before price will narrow the field faster than any feature comparison.

Keep the old subscription alive and readable

This is the cheapest insurance in the whole process and the step people skip because it feels like paying twice.

Do not cancel the old subscription on the day you cut over. Keep it running, at the cheapest tier that still gives you read access, for long enough to cover the questions that will come. My default would be through the completion of the first annual filing that touches the old data, and at least twelve months in any case. If your accountant is still working on a prior year, keep it until they are finished.

While it is still live, get everything out that a cancelled account will not give you back. Full transaction detail exported to a spreadsheet format, every year of it. General ledger, trial balance, profit and loss and balance sheet for every completed period, exported as files rather than left in the software. Every attachment and receipt, downloaded. Customer and supplier lists. Invoice history. Any report you have ever actually needed.

Store those exports somewhere durable that is not the accounting software, and check that you can open them. An export you have never opened is a backup you do not have.

Then, when you do cancel, understand what cancellation means in that product. Some vendors leave you a read only window. Some archive the data and let you reactivate. Some simply stop your access. That is a question to ask before you cancel, not after, and it is a question with a different answer at every vendor.

Opening balances, the part everyone rushes

Opening balances are how the new system learns what was true on the day you started using it. Get them right and the new file is trustworthy from day one. Get them wrong and every report from the new system is wrong in a way that is very hard to find later.

The source document is the trial balance from the old system as at the day before your switch date, after that period has been fully reconciled and closed. Not an estimate, not a draft, and not a trial balance from a period you have not reconciled. If the old file does not reconcile, fix that before you migrate, because migrating an unreconciled file just moves the problem into a system where you have less history to diagnose it with.

What has to come across as opening balances, at minimum: every bank and card account balance, accounts receivable with the individual open invoices behind it, accounts payable with the individual open bills behind it, inventory value if you hold stock, fixed assets and accumulated depreciation, loans and other liabilities, sales tax payable, and equity. The receivables and payables detail matters because you need to be able to chase and pay individual documents, not just carry a total.

Then check the one thing that catches everyone. The opening balances must balance. Total debits equal total credits, and the balance sheet in the new system as at the switch date must match the balance sheet in the old system as at the day before. If there is a suspense or opening balance equity account with a number in it after you finish, you have not finished.

How those balances should be structured for your entity and your accounting method is genuinely a CPA question, and it is worth an hour of professional time rather than a guess. This is not tax or accounting advice and I am not qualified to give you any.

Reconcile the first month twice

This is the step that turns a migration from hopeful into verified, and it costs one evening.

Reconcile your first month in the new system against the bank statement, the normal way, until it balances. That proves the new system is recording what the bank recorded.

Then reconcile it a second way, against the old system’s logic. Take the same month’s expected figures, revenue by channel, cost of goods sold, each major expense category, and check that the new system produces the same shape of numbers you would have expected from the old one. You are not looking for identical output, because categories may have been remapped. You are looking for anything that has moved by an amount you cannot explain.

Two reconciliations catch two different classes of error. The first catches missing or duplicated transactions. The second catches mapping errors, where transactions exist but have landed in the wrong account, which the bank reconciliation will happily balance around without noticing.

If you can, run the old system in parallel for that first month and compare the two profit and loss statements side by side. Any line that differs is either a mapping decision you made deliberately or a mistake, and you need to know which. After that month, if both agree, you can stop the parallel run with confidence.

Once the first month is clean, the ordinary setup work matters again: bank rules, connectors, the month end routine. The full sequence for a store is in my walkthrough of the QuickBooks setup order that prevents rework, and most of that ordering logic applies whichever product you have landed on.

What your accountant actually needs from you

Tell your accountant before you migrate, not after. This is the single most common source of unnecessary cost in the whole exercise, because an accountant who finds out afterwards has to reconstruct what you did, and an accountant who is told beforehand will usually just tell you the date to use and the balances to carry.

What to give them, in a single message. The date you intend to switch and why. The product you are leaving and the one you are joining. A copy of the final trial balance from the old system as at the day before the switch. Confirmation that the final period in the old system is fully reconciled. A note of anything you know will not transfer, particularly reconciliation history and attachments. And access to the new file once it exists, at whatever level of access the new product gives accountants.

What to ask them, in the same message. Is this the right date given our filing calendar. Are the opening balances structured the way you want them. Do you need anything from the old system before we stop paying for it. And is there anything about our entity or our method that makes this move more complicated than it looks.

That exchange usually takes ten minutes of their time and saves several hours of it later. It also creates a record of the decision, which matters if anyone asks questions about the transition year afterwards. Again, and I will keep saying it, that conversation is the tax and accounting advice in this process. This post is not.

Before you cancel anything, get these answers in writing

Vendor migration tooling varies enormously, and it varies over time. A tool that moved five years of transactions last year may move two this year, or may only exist for certain source products, or may be a partner service rather than something the vendor operates. So do not rely on a general claim that a product “imports from” your current system. Get specifics.

The questions I would put to the destination vendor, in writing, before cancelling anything. Exactly which of my data will your import bring across, itemised. How far back does historical transaction detail go, and does it arrive as individual transactions or as summaries. Do open invoices and open bills keep their original dates and ageing. Does bank reconciliation history come across. Do attachments come across. Do inventory items arrive with cost values, and on what basis. Is this import performed by you, by a partner, or by me, and what happens if it fails.

And one question for the vendor you are leaving. After I cancel, what access do I retain to my data, for how long, and in what format.

If any answer is vague, treat it as a no and plan around it. It is much cheaper to export something you did not need than to discover after cancellation that a promise did not cover your case.

What the destination actually costs

Migrations are multi year decisions, so price them on the steady state rather than on the welcome offer. Here is the field at year two list price, which is what you pay once every promotional period has expired.

Product and plan	Year two annual	What it buys
Wave Starter	$0	Invoicing and bookkeeping, no bank feed auto import
Zoho Books Free	$0	1 user, under $50K revenue, 1,000 invoices
Zoho Books Standard	$180	3 users, 5,000 invoices
Wave Pro	$190	Bank import, branded invoices, reminders, receipts
FreshBooks Lite	$276	5 clients, 1 user, no double entry accounting
Xero Early	$300	20 invoices and 5 bills a month
QuickBooks Simple Start	$456	1 user, no inventory
Zoho Books Professional	$480	5 users, 10,000 invoices
FreshBooks Plus	$516	50 clients, double entry accounting arrives here
Xero Growing	$660	Unlimited invoices and bills, no multi currency
FreshBooks Premium	$840	Unlimited clients, project profitability
QuickBooks Essentials	$1,020	3 users, still no inventory
Xero Established	$1,080	Multi currency, projects, expense claims
QuickBooks Plus	$1,680	Inventory arrives here, 5 users, 40 classes
QuickBooks Advanced	$4,080	25 users, batch invoicing, workflow automation

Three warnings for anyone choosing a destination on price. Wave Starter is free but excludes automatic import and merging of transactions, branded invoices, late payment reminders, receipt digitisation and dashboard insights, which is a strange set of exclusions to accept immediately after a migration. Zoho Books Free applies only while your revenue for the financial year stays under $50K. And Xero Early permits 20 invoices and 5 bills a month, which is a limit a real business hits fast, so treat Growing at $660 as the honest Xero entry point.

One timing note that matters more to switchers than to anyone else. Xero’s pricing page states its promotional offer is available until 30 September 2026 and is limited to new US customers making a first purchase with Xero, so a store already on Xero cannot use it to price a plan change. If you are planning a migration for a financial year boundary after that date, do not budget on a promotional figure you saw earlier in the year. Price the move on year two either way, and the reasoning behind that arithmetic is laid out in my breakdown of every plan costed for year one and year two.

A note on QuickBooks Desktop, because it sends people here

A good number of migrations start with a rumour about QuickBooks Desktop, so it is worth stating what Intuit actually said rather than what people repeat.

Intuit stopped selling QuickBooks Desktop Pro Plus, QuickBooks Desktop Premier Plus, QuickBooks Desktop Mac Plus and QuickBooks Desktop Enhanced Payroll to new US subscribers after 30 September 2024. Its own announcement page states that existing subscribers are not impacted by this change, and that existing QuickBooks Desktop Plus and Desktop Payroll subscribers can continue to renew their subscriptions after that date. Enterprise is unaffected.

So the accurate summary is that new buyers in the US cannot buy those products, and existing subscribers can keep renewing. Desktop is not dead and you are not being forced off it. If you are on it and it works, “everyone says it is going away” is not a reason to run a migration. A real reason to move would be needing something Desktop does not give you, such as multiple people working in the file from different places, or a connector ecosystem that only exists for cloud products.

A sequence you can actually follow

Put together, here is the order. Pick the destination first, on capability rather than price, then pick the date. Tell your accountant and get the date confirmed. Reconcile and close the final period in the old system completely. Export everything out of the old system, including attachments, and check the exports open.

Then take a trial of the destination and run a test import if one is available, so you find out what your data looks like on the other side before any of it matters. Ask the vendor the itemised questions above and keep the answers. Set up the destination properly, chart of accounts before connectors, and enter the opening balances from the closed trial balance. Confirm the balance sheet matches across the boundary.

Cut over on the date. Run parallel for the first month if you can. Reconcile that first month twice, once against the bank and once against expectation. Fix mapping errors while there is one month of them rather than nine. Rebuild rules and recurring templates as they come up rather than all at once.

And keep the old subscription alive, readable and paid, until the last filing that touches its data is finished. Only then cancel, and only after you have checked what cancellation leaves you with.

If it turns out mid process that the destination was the wrong choice, stop rather than push through. It is far cheaper to reconsider before the opening balances are entered, and the problem led comparison in my guide to alternatives organised by the problem that sent you looking exists precisely for that moment.

Running the business behind the books

A migration is housekeeping. It makes the numbers legible, it does not make them better, and the things that make them better sit upstream in what you sell and at what margin.

Margin is a product selection decision long before it is a software decision, which is why I keep a working list of profitable high ticket niches and revise it as categories stop working.

If the model is new to you, start with how the high ticket model actually works, because a store built on a few large orders a day carries a very different bookkeeping load than a high volume low ticket one.

Supplier terms shape your cash cycle more than any subscription does, and my complete supplier sourcing guide covers finding and qualifying them properly.

None of the bookkeeping means much until the entity exists and is genuinely separate from you, which is the argument in my walkthrough of business formation for high ticket dropshipping.

For the operating stack, I run stores on Shopify because the accounting connector ecosystem around it is the deepest of any platform. For the formation paperwork, Bizee files it without the markup a law firm charges for identical forms.

And once you are shipping physical goods, liability cover stops being optional, which is where Hiscox is worth a quote.

Frequently Asked Questions

When is the best time to switch accounting software?

The first day of a financial year, because it leaves you one complete closed year in the old system and complete years going forward in the new one, with nothing stitched. The first day of a month is the acceptable fallback and keeps your monthly reporting clean at the cost of one stitched annual report. Mid month is never worth it. If the current system is unbearable, run both in parallel until the month turns rather than cutting over on an arbitrary day.

Will my transaction history come across?

Some of it, probably, and how much depends entirely on which products are involved and what tooling exists between them when you do it. Balances and open items are usually manageable. Reconciliation history, attachments, bank rules and recurring templates frequently do not move. Get an itemised answer in writing from the destination vendor rather than relying on a general claim that it imports from your current product, and export everything from the old system regardless.

How long should I keep paying for the old software?

Until the last filing that touches its data is complete, and at least twelve months. It feels wasteful and it is the cheapest insurance in the process. Before you finally cancel, ask the old vendor what access you keep afterwards, for how long, and in what format, because the answer differs by vendor and you want it before the decision rather than after.

Do I need my accountant involved?

Yes, before rather than after. They will tell you the right date given your filing calendar, how they want opening balances structured, and what they need out of the old system before you stop paying for it. That is a short conversation that prevents a long one. Nothing in this post is tax or accounting advice, and the structuring questions in particular belong to a CPA or the taxing authority.

Is QuickBooks Desktop being discontinued?

Not for existing subscribers. Intuit stopped selling QuickBooks Desktop Pro Plus, Premier Plus, Mac Plus and Desktop Enhanced Payroll to new US subscribers after 30 September 2024, and its announcement states that existing subscribers are not impacted and can continue to renew. Enterprise is unaffected. So new US buyers cannot purchase those products, and current users are not being forced to migrate.

What is the most common migration mistake?

Cancelling the old subscription too early, closely followed by switching mid period. The third is entering opening balances from a period that was never properly reconciled, which quietly poisons every report in the new system and is very hard to trace back to its cause once a few months have passed.

Bottom Line

Switch at a period boundary, ideally a financial year boundary, and pick the date before you pick the day of the week. Reconcile and close the old system completely before you take a trial balance off it, because opening balances taken from an unreconciled period are worse than useless. Export everything, attachments included, and check that the exports open. Keep the old subscription alive and readable until the last filing that touches it is done, then ask what cancellation leaves you before you press it.

Get the vendor’s import promises itemised in writing before you cancel anything, because migration tooling varies by vendor and by source product and a general claim is not a commitment about your data. Then reconcile the first month twice, once against the bank and once against what you expected, because those two checks catch different mistakes. And accept the trade honestly: you keep your balances and your ability to file, and you lose some of the granular history, which is exactly why the old file has to stay readable.

Everything in this post that touches your filings, your accounting method or how your opening balances should be structured is a question for a CPA or the taxing authority, not for me. If you want the adjacent reading on the expense side, my guide to deducting ecommerce business expenses carries the same caveat.

If you would rather hand the whole build over and start from a store that is launched with the stack already chosen and configured, that is what our done for you high ticket dropshipping build and launch service exists to do.

Related Articles

How to Choose Accounting Software: The Five Gates That Decide It Before Price

How to Set Up QuickBooks for an Ecommerce Store: The Order That Prevents Rework

QuickBooks Pricing 2026: Every Plan Costed for Year One and Year Two

QuickBooks Alternatives 2026: Organised by the Problem That Sent You Looking

How to File a Tax Extension in 2026: Form 4868 Explained