Hardly any SME replaces its ERP because it feels like it. You do it because there is a date in your vendor's calendar. That makes one question more important than the question of which package to buy: which data has to stay yours, wherever you end up?
You outgrow a CRM gradually. An ERP you usually replace because you have to. The large vendors have given their older generation of packages an end date over the coming years, and those dates are not moving. SAP has confirmed several times that mainstream maintenance for ECC stops at the end of 2027. Microsoft has not sold new Dynamics GP subscriptions since 1 April 2026.
That also explains why you have been reading about it everywhere these past weeks. Consultancies started publishing migration playbooks in bulk in September, and that is no coincidence: the closer the deadline, the scarcer the consultants and the higher the rate. For you the relevant conclusion is not that you should hurry, but that you want something of your own in hand before you start negotiating with that market.
Microsoft no longer sells new subscriptions. Existing customers carry on, but the package is not growing along with anything anymore.
No standard support and no statutory updates. Extended maintenance is available, at a premium.
No more enhancements, tax updates or technical support. Security updates run until 30 April 2031.
This is where an ERP migration differs from a CRM migration, and it is exactly the difference most projects underestimate. In a CRM almost everything you need is stored as a fact: a contact, a quote, a note. In an ERP a large part of what you see on screen is not stored at all, but calculated. Your stock position is a sum. Your open item is a balance. Your cost price is the result of a valuation method that sits somewhere in the settings.
So do not ask your vendor for "an export". Ask what you get per category.
Accounts, items, orders, invoices, journal lines. This is what someone once entered or what an integration delivered.
usually comes out fine, as csv or through an apiBalances, stock positions, cost prices, open items, margins. Stored nowhere as a fact, but calculated from lines plus settings.
ask by which rules this gets calculatedChart of accounts, VAT codes, units and conversions, dimensions, number series. Not data in your vendor's eyes, but the meaning of every figure you have.
ask for the full list, not just the active valuesCustom fields, reports, workflows and integrations built up over the years. Falls outside the standard migration scope.
ask for an inventory, including what looks inactiveAn ERP migration rarely fails loudly. It fails quietly. The conversion runs, the record counts match, everyone goes home, and three weeks later the accounts receivable subledger turns out not to tie back to the general ledger. That is not a technical problem but a meaning problem: data was moved without the rules that gave it meaning.
The four classics, in the order we run into them. Open items that do not reconcile, because partial payments, credit notes and currency differences were combined differently in the old system. Items that lost their unit conversion, so an order for ten boxes suddenly reads ten pieces. Configuration loaded in the wrong order, so records look valid but refuse the moment anyone tries to post a transaction against them. And customisations that were never in scope, because nobody remembered they were there.
All four come from the same gap: nobody counted and recorded up front what had to add up. How to do that, in what order and what you produce at each step, is in the data migration plan. It holds for every migration, including one that stays inside the same ecosystem.
The standard route is: your vendor sets a deadline, you buy the successor, you pay for an implementation, and eight years later you are in the same spot. That is not a disaster, but it is a choice you make once a decade and do not reverse afterwards. Worth a week of thought.
The alternative is not "no ERP". You need an ERP, and for stock, production and accounting a standard package is often simply the best answer. The alternative is about where your data lives. Put your customer, order and history data in an open database you run in-house and have the ERP connect to it, and the next migration is no longer a move but the replacement of one component. That is the idea behind the AI Native Data Layer: the package is interchangeable, the data is not. What such a layer actually is, and when you do not need one, is explained in what is a data layer.
All data moves into the successor, including the customisations you pay to have rebuilt.
Your data sits in an open database in-house; the ERP connects to it and does what it is good at.
You do not have to decide anything to do something useful. Ask your vendor for two things in writing: the end-of-support date for your version, and the exhaustive list of data categories that are transferable under your contract. The second is a right under the European Data Act since September 2025, and from 12 January 2027 a switch may cost you nothing at all. What those rules do and do not cover is in the article on the Data Act.
With those two answers on paper you will have a much calmer conversation with whoever sends you a quote. And you will know straight away whether you are dealing with a source system we have a separate guide for, such as SAP or Dynamics 365.
Four kinds, and each one asks something different of you. Recorded data (accounts, items, orders, invoices, journal lines) usually comes out fine. Derived data (balances, stock positions, cost prices, open items, margins) is stored nowhere as a fact but calculated, so it has to be made to add up again in the new system. Configuration (chart of accounts, VAT codes, units and conversions, dimensions, number series) is the meaning of your figures and is rarely part of a data export. Customisations (custom fields, reports, workflows, integrations) fall outside the standard migration scope, which is why they disappear unnoticed most often.
Less into the new ERP than you think, and more outside the new ERP than you think. Day to day you mainly need open items, current stock and running orders. Moving old years costs a lot and returns little, but you cannot throw it away either: your statutory retention period runs on and you need the history the moment someone asks a question about last year. The practical answer is to put the history in your own open database, separate from the package, and start the new ERP clean.
It differs per package and is set out in your vendor's lifecycle documentation. Two dates affecting many SMEs right now: mainstream maintenance for SAP ECC ends on 31 December 2027, and Microsoft stopped selling new Dynamics GP subscriptions on 1 April 2026, with enhancements, tax updates and technical support ending on 31 December 2029 and security updates running until 30 April 2031. Ask for the date in writing if you do not know it, because your entire planning depends on it.
Until 12 January 2027 only the costs actually incurred, without a profit margin. From that date a vendor may charge nothing at all for a switch under the European Data Act, including for exporting your data. On top of that, the contract has to contain an exhaustive list of the data categories that are transferable. That last point is already usable today: ask for that list before you choose a package.
Your data first. As long as you do not know what is in your current system, what of it is derived and what you can actually get out, you cannot assess any package and you cannot check any quote. The inventory is also the only part of the work that keeps its value: it holds for whichever package you choose, and for the migration afterwards.
In the free migration scan we map out together what is in your current systems, what of it is derived and what you can actually get out. You get a concrete migration plan, even if you continue with another party.
Request the migration scan