Bookkeeping software is usually the first real system a growing business buys, and it is usually still there long after it stopped being enough. Sage and products like it do accounting properly. What they do not do is run orders, inventory and shipping, so those end up being managed manually alongside the books.
That is the pattern we found at a US consumer electronics brand selling through Amazon, Walmart, Shopify, eBay and more than a dozen retail trading partners. Sage handled bookkeeping, while orders, inventory and shipping decisions were all managed by hand around it. The accounting was not the problem. Everything the accounting did not cover was the problem.
The fear that delays the decision
When we talk to businesses in this position, the blocker is almost never whether a new system would be better. It is the history.
Years of customers, vendors, items and transactions sit in the current system, and that record is what the business runs on: who bought what, what a vendor charged last time, which items are still active. Nobody wants to be the person who signed off a migration that lost it.
That fear is reasonable and it is also the thing to design around rather than to argue with. The question is not whether to keep the history but which parts of it have to be live in the new system versus readable somewhere else.
What actually needs to move
On that engagement, customers, vendors, items and transaction history were migrated from the bookkeeping system into a browser-based ERP covering order-to-cash and procure-to-pay, with a full general ledger, receivables and payables, so the business changed systems without losing its records.
Those four categories are worth thinking about separately, because they behave differently.
Customers and vendors are the easiest, and the ones people worry about most. They are relatively few, relatively structured, and the fields map cleanly. The work is in deduplication and in deciding what to do with records that have not been touched in years.
Items are where migrations get stuck. Item data in a long-running system accumulates: duplicates created when someone could not find the existing code, retired products nobody deactivated, inconsistent units of measure, descriptions that encode information in a convention only one person remembers. Moving that without cleaning it means importing the mess into a system you just paid to build.
Transaction history is the category that needs a decision rather than a default. Live history that the business queries routinely has to be in the new system. History it only needs for reference or compliance can often stay readable in the old system or in an export, which is usually far cheaper than modelling it into a new schema.
The ledger is a separate problem again, because it has to balance. Opening balances that do not reconcile are not a data issue to fix later; they are a reason not to go live.
Structure, not just records
The part that surprises people is that the records are often less work than the shape they sit in.
Bookkeeping systems let a business grow in whatever direction it grew. Multiple company files, entities that exist for historical reasons, chart of accounts codes that encode a structure somebody stopped maintaining. Before data moves, that structure has to be understood and mapped to how the business is actually run now.
This is usually the most valuable conversation in the whole project, because it is the first time in years anyone has asked why the structure is the way it is. Some of it turns out to be deliberate. Some of it turns out to be a workaround for a limitation the new system does not have.
Changing over without a leap
A migration is only as good as the confidence people have in the result on the first Monday. Two general practices earn that confidence, and they are worth building into the plan rather than improvising.
The first is running both systems for a period, with the same transactions going into each, so the new system can be compared against the old one on real activity rather than on test data. The second is reconciling the numbers that have to agree, balances in particular, before anyone depends on the new system alone. A difference found during a parallel period is a data question. The same difference found after cutover is an emergency.
Neither of these is exotic. They are the standard way to de-risk a change of record-keeping system, and the reason to name them explicitly is that under time pressure they are the first things dropped.
What the business actually gained
The outcome on that engagement was that the business moved from bookkeeping-only software to one ERP running orders, inventory, purchasing, shipping and accounting. Orders from every marketplace and wholesale channel are managed from one system instead of separate portals, and inventory is tracked across warehouses, 3PLs and marketplace fulfillment programs, with quantities pushed to connected channels except Walmart.
Reading that back, the accounting is the smallest part of the list. That is the point. The reason to move off bookkeeping software is rarely that the bookkeeping is bad. It is that everything else has been running alongside it by hand, and bringing those into one system is what changes how the business operates.
If you are weighing this up
Start with the structure rather than the data. Map how your current system is organised and why, because that determines the shape of everything downstream and it is the part you cannot discover from a field list.
Then decide, explicitly, how far back the live history has to go. That one decision moves the cost of a migration more than any other.
We do this work as custom ERP development, and where the old system stays in place for part of the picture it becomes ERP integration instead. The system described here is set out in full in our multi-marketplace ERP case study. If you are carrying years of history you cannot afford to lose, get in touch and tell us one thing first: how far back do your staff actually look when they need an answer?
Common questions
Do we have to migrate every year of transaction history?
Not necessarily, and the answer should be a decision rather than a default. Decide how far back the business genuinely needs to query, and keep the rest readable in the old system or an export rather than forcing it into a new schema.
Can we keep using the bookkeeping software for accounting only?
Some businesses do, and it is a legitimate halfway position. The cost is that you keep two systems in step, which is the reconciliation work the move was supposed to remove.
What usually takes the longest?
Item data. Customers and vendors tend to be tidier than people expect, while items accumulate duplicates, retired codes and inconsistent units across years of use.