ERP migration when your current system isn’t an ERP.
What an ERP migration actually involves
An ERP migration moves a business off its existing system of record onto a platform that can carry finance, inventory, purchasing, and production together. The work has three parts: modelling how the business actually runs, moving and reconciling historic data, and operating the new system through its first closing period.
The third part is the one that gets underestimated. A migration is not finished at cutover; it is finished at the first month-end that closes cleanly without anyone reopening the old system to check.
What you’re calling a migration is usually two projects
The first project is the one you’re expecting: extract the data, map it, load it, reconcile it, prove the opening balances tie out.
The second project is the one nobody scoped. Everything the business does that was never in a system has to be designed before it can be migrated, because there is nothing to migrate it from. Purchase approvals that happen in a phone call. Stock counts that live in a register. Production sequencing that lives in one person’s diary and one person’s head.
You cannot move a process that was never written down. You have to build it first, agree it with the people who currently do it their own way, and only then load data into it.
When the second project isn’t scoped, it doesn’t disappear. It surfaces three weeks after go-live as “the system doesn’t do what we need.”
Every source system breaks in its own specific way
The platform you’re leaving determines what the hard part is going to be.
Leaving an accounting package
QuickBooks, Zoho Books, Busy, or any of the packages a business runs as though it were an ERP. The chart of accounts usually transfers without drama. The item list is where it goes wrong. Products have been renamed, merged, and reused across years of transactions, so historic documents reference items that no longer describe what was actually sold. Inventory has been tracked in a spreadsheet alongside, and the two have quietly disagreed for a long time. The migration is the first time anyone has to decide which one was right.
Leaving Tally
Tally is a genuine ledger and it is usually accurate, which is why businesses keep it long past the point it serves them. The problem is scope: it holds the statutory picture and nothing else. Migration off Tally is rarely a data problem. It is the first time purchasing, stock, and production enter a system at all. There is also a filing obligation to protect, which is why we generally keep Tally running read-only through a full filing cycle rather than cutting it dead at go-live.
Leaving a system nobody built on purpose
A spreadsheet estate, or an in-house application written by someone who left. These carry the most operating logic and the least documentation. The rules that matter are embedded in formulas, in file naming conventions, and in what the team knows not to do. Recovering that logic is the engagement. The data load is the easy half.
Sometimes the answer is that you shouldn’t move yet
Two situations account for most of the migrations that should not have started when they did.
The first is timing. A business mid-way through a funding round, an audit, a statutory reassessment, or a peak season does not have the operational attention a migration consumes. Running one anyway is how you get a half-finished system and a team that no longer trusts it.
The second is diagnosis. If the complaint is that reporting is slow and reconciliation is manual, the cause is sometimes process, not platform. Replacing the software rebuilds the same problem on a more expensive foundation. That is worth an honest week of investigation before anyone signs a migration.
The discovery week is scoped to reach a written recommendation, and not proceeding is one of the outcomes it is allowed to reach.
Migrations run as a structured engagement, not an open-ended one
-
01
A paid discovery week
We audit what you actually run. Every system holding operating data, every place two systems disagree, every process that exists only in someone’s practice. You end the week with a written target design, a data assessment, and a cost and duration range you can take to a board. If the recommendation is not to proceed, that is what the document says.
-
02
Design and build against your operating model
Configuration and, where it is genuinely warranted, custom development. We keep customisation deliberately low, because every custom module is something you will pay to carry through every upgrade for the rest of the system’s life.
-
03
Data migration, run more than once
Historic data is loaded, reconciled, and rejected as many times as it takes. Nobody accepts a first load. The measure is whether your finance lead can tie the opening balances without assistance.
-
04
Parallel run and cutover
Both systems live, one period, both closed. The old system stays reachable read-only afterwards for as long as your filing obligations require.
-
05
The weeks after go-live
A significant share of our delivery effort on any migration sits after cutover rather than before it. That is not overrun. It is where a migration is proven, and it is priced into the engagement rather than sold to you afterwards as support.
On platform choice. We recommend Odoo more often than not, and we put the reasoning in writing so you can argue with it. Where ERPNext is the better fit we say so and deliver it alongside certified ERPNext partners; we are not an ERPNext partner ourselves and do not present as one. If neither is right for you, the discovery document says that too.
Questions we get before the discovery call
How long does an ERP migration take?
A migration program typically runs three to twelve months, and the range is that wide because it tracks the second project, not the first. Moving data off QuickBooks or Tally is measured in weeks. Designing purchasing, stock, and production for a business that has never had them in a system is measured in months.
Can we keep our transaction history?
Usually, and rarely in full. Historic documents reference items, partners, and tax treatments that may no longer exist in a coherent form. We migrate open items and balances completely, migrate closed history as far back as it stays meaningful, and keep the source system reachable read-only for anything beyond that.
Do we have to move everything at the same time?
No, and for larger estates you shouldn’t. Finance and inventory generally move together because they cannot be reconciled apart. Production, quality, and field operations can follow in later phases once the core is stable.
What happens to Tally while we’re still filing on it?
It stays live and read-only through the filing cycle. Cutting a statutory system dead at go-live to prove a point is how a clean migration turns into a compliance problem.
Do you migrate to platforms other than Odoo?
We deliver Odoo directly and ERPNext with certified ERPNext partners. If the right answer for your business is a platform we don’t deliver, the discovery document will say so and name it.
What if our last ERP project already failed?
That is a different engagement. A failed or stalled implementation is stabilised before anything is migrated anywhere. See rescue and stabilization →
Start with the week that tells you whether to move.
A paid discovery week ends in a written target design, a data assessment, and a duration and cost range, including the recommendation not to proceed if that is what we find.