Changing accounting systems is mostly a data problem, and the sellers who get hurt are the ones who move the ledger without moving the history behind it. A workable migration comes down to six decisions made in order: pick the cutover date, freeze and close the old period, agree on opening balances, decide how much transaction history travels, rebuild the inventory layer, and run both systems in parallel for one full cycle before switching anything off. The platform choice matters less than most sellers expect. The sequencing matters far more.
Decide the cutover date before anything else
The only sane cutover points are the start of a fiscal year or the start of a quarter. Mid month migrations create a period split across two systems, which means every year over year comparison for the next twelve months requires stitching two data sources together by hand.
A fiscal year boundary is cleanest, because the tax return already treats it as a hard line. A quarter boundary works if waiting would mean another year on a system that has stopped working. Anything else trades a few weeks of speed for reporting debt that lasts as long as the records do.
Pick the date first. Every other item on this list is scheduled backward from it.
Close the old period and freeze it
Before any data moves, the final period in the old system has to be genuinely closed: bank accounts reconciled, marketplace settlements matched to deposits, inventory counted, accruals posted, and the books locked so nobody can back date an entry into a period that has already been migrated.
This step gets skipped constantly and it is the source of most migration failures. If the old system keeps accepting entries after the extract is taken, the two systems diverge silently, and the divergence is usually discovered months later when a prior year figure stops matching the filed return.
Lock it. Export a full trial balance, a general ledger detail report, and an inventory valuation report as of the cutover date, and store them somewhere outside both systems. Those three files are the evidence that the opening balances were right, and they are what an accountant will ask for if anything is questioned later.
Agree on opening balances, line by line
Opening balances are not a bulk import. Each one is an assertion that a number is correct, and each should be traceable to a document: bank statements for cash, aged reports for receivables and payables, a valuation report for inventory, loan statements for debt, and prior year equity carried forward.
Inventory is where this breaks. In most product businesses inventory is the largest asset on the balance sheet, and it is the one number that cannot be confirmed from a third party statement. A seller migrating with an inventory figure nobody has physically verified is migrating an error and giving it a fresh start.
Decide how much history travels
Full transaction history is expensive to move and frequently not worth it. Most sellers are well served by opening balances plus two years of summarized monthly totals, with the old system archived in read only form for anything older.
The exceptions are real, though. A seller preparing for a sale inside eighteen months generally wants three years of detail in one place, because a buyer will ask for it and a read only archive in a decommissioned system is an awkward answer. A seller with an open sales tax matter wants the detail for the periods under review. Everyone else is paying for data they will open twice.
Rebuild the inventory and COGS layer deliberately
This is the part that separates ecommerce migrations from ordinary ones. The ledger will import. The connection between SKUs, landed costs, units on hand across multiple fulfillment networks, and the cost of goods sold calculation that depends on all three usually will not.
Before the cutover, settle three things in writing: the valuation method, what counts as landed cost, and which system is the source of truth for units on hand. FIFO and weighted average produce materially different profit in any period when supplier costs are moving. A migration is the last convenient moment to change method. Landed cost is a policy question about whether freight, duty, and inbound fulfillment fees are capitalized into the unit cost or expensed separately, and two systems will rarely default to the same answer.
Whatever tooling sits in this layer, the requirement is that SKU level detail survives the trip into the ledger, because summarized data cannot be disaggregated later. Tools differ in how much of it they preserve, and SKU level profit and loss reporting is one of the specific capabilities worth testing with real data before committing.
Comparing the tooling honestly
Most sellers evaluating this layer end up looking at the same handful of products, and the right answer depends almost entirely on two variables: which accounting system is on the other end, and where the seller’s customers are.
A2X connects Amazon, Shopify, eBay, Etsy, Walmart, and PayPal into QuickBooks Online, Xero, Sage, and NetSuite, and is built around summarized settlement journals that reconcile cleanly to payouts. If a seller is on NetSuite or Sage, or sells meaningfully on Etsy, A2X covers ground that ConnectBooks does not: ConnectBooks syncs Amazon, Shopify, Walmart, TikTok Shop, and eBay into QuickBooks Online, QuickBooks Desktop Enterprise, and Xero, and a seller outside that set should stop reading comparisons and pick the tool that supports their stack.
Link My Books supports Amazon, eBay, Shopify, Etsy, TikTok Shop, Walmart, WooCommerce, and Square into Xero and QuickBooks Online, with built in handling for VAT and GST alongside sales tax. For a UK or EU seller, that is a decisive advantage, and it is the clearest case where a seller should not be choosing a US oriented product at all.
ConnectBooks is built for a narrower case: US sellers running several of those five marketplaces, typically above $2M in revenue, who need automated cost of goods sold, real time inventory, and settlement reconciliation carried at SKU level rather than summarized. Inside that description it fits well. Outside it, the tools above fit better, and a migration is an expensive time to discover the difference.
Run both systems in parallel for one full cycle
Parallel running is the step everyone wants to skip and nobody regrets. For one complete month, post to both systems and compare the outputs: revenue by channel, gross margin, inventory value, and the bank reconciliation.
Differences will appear. Most are explainable, usually a timing or mapping difference, and each one found during a parallel month is one not found during a tax filing. Switch the old system off only when a full month reconciles without hand adjustments.
The paperwork nobody enjoys
A change in accounting system is not by itself a change in accounting method, but migrations often surface one, particularly around inventory. If a seller is changing how inventory or COGS is computed, that is a method question with filing consequences, and the general rules are set out in IRS Publication 538. It belongs with the seller’s own accountant before the cutover rather than after, and the Small Business Administration guidance on financial recordkeeping is a reasonable baseline for what to retain from the old system.
Keep the archived exports for as long as the records they support need to be kept. A decommissioned accounting system is not a records retention policy.
