Who takes care of evolving the ERP after go-live?
The project ends, the system does not. Where that handover is missing, the implementation ages faster than necessary.
Contents
We clarify who develops the system further before it stalls.
After go-live the system needs three named roles: a business owner per core process who decides what may change, technical support for updates and extensions, and a small body that prioritises change requests. Without those three, evolution falls back on IT, which cannot decide on business questions, and the system stays at the state it had at go-live.
What happens to customisations during updates: customisations and cloud updates
Why a system should grow with you: Never starting over
Why the time after go-live decides
Go-live is the moment the system starts to live. Users discover workflows nobody considered during testing, the business changes, new requirements arise, sometimes the business model turns. An ERP that absorbs this movement stays useful. One that freezes becomes, over the years, the old system that was just replaced.
In practice the project organisation ends after go-live and nothing takes its place. The project manager returns to the line, the external consultants leave, and change requests land as tickets with IT. There they are assessed technically, but nobody decides on the business question.
The consequence is a familiar pattern: changes take a long time, business areas build workarounds beside the system, and after three years part of the company works in spreadsheets again. That is not a software problem but a gap in the operating model.
The three roles that must be filled
The first role is the business owner per core process. This person decides whether a requested change serves the process, and carries responsibility for the master data in their area. Without them, every change becomes a negotiation between departments.
The second role is technical support. It installs updates, tests, maintains extensions and keeps contact with the partner. That can be staffed internally or bought in. What matters is that there is a named responsibility and not a collective role alongside other duties.
The third role is a small body that meets every four to six weeks and prioritises change requests. It does not need a large group: the business owners, technical support and one person who decides in case of doubt. This body is the continuation of the steering committee in miniature.
How much capacity is realistic
A sound rule of thumb from practice: plan a budget for ongoing evolution in the order of a small single-digit percentage of the implementation cost per year. That covers updates, smaller extensions and adaptation to changed requirements.
On the internal side the business owners do not need much time, but they need reliable time. Half a day a month per core process is enough in quiet phases, provided it actually happens. Technical support depends on the number of extensions and interfaces.
More important than the exact figure is that this budget exists and does not have to be applied for each time. Where every small item needs an application, maintenance is skipped and the backlog grows quietly.
How to tell that aftercare is missing
There are three reliable signs. The first are new spreadsheets beside the system. When business areas start keeping data outside, the system has stopped reflecting their work and nobody has changed it.
The second sign is a growing list of open change requests without prioritisation. A long list is not a problem, an unsorted one is, because it means nobody decides.
The third sign is the sentence that the system cannot do that. In most cases it can, but nobody has set it up. When that sentence comes up more often, what is missing is not functionality but responsibility.
“
Go-live is not a conclusion but a handover. Where it does not happen, the implementation ages faster than necessary.
Frank Maier, founder of DGP
Frequently asked questions
Maintaining AI features after go-live
An accounting module calculates today as it did five years ago. An AI feature does not: models, interfaces and capabilities change with two release waves a year, and its behaviour depends on your data, which also changes. The state on go-live day is a snapshot. Without an operating routine, every AI feature ages within months: it keeps working, only nobody knows how well any more.
The routine has four elements:
- One owner per feature, and in the business department, because that is who can tell whether results are professionally correct. Document recognition in purchasing belongs to purchasing, not to the administrator.
- One review date per release wave, twice a year in the calendar, with Microsofts announcement list as the agenda.
- A set of test cases: for every automated process three to five typical cases plus the known edge cases, run through after every release, result noted.
- A sampling rate in daily operation: a fixed small share of agent results is checked continuously. If the error rate rises, that is the early warning, long before anyone complains.
For a mid-sized company with a handful of active AI features, the routine amounts to a few person-days a year, less than a single month of unnoticed errors costs in clean-up. If a release degrades a feature, the test case run shows it, and there are three orderly answers: readjust settings, run the feature more tightly for a while, or report the finding to Microsoft. The updates cannot be suspended permanently, and that is exactly where the value comes from. Internationally, the AI review belongs in the same release routine as the global template, otherwise every country tests on its own or none does.
Briefly asked
Who is responsible for the ERP after go-live?
Three roles: a business owner per core process who decides what may change, a named technical support for updates and extensions, and a small body that prioritises change requests every four to six weeks.
How much budget does evolving an ERP need per year?
As orientation, a small single-digit percentage of the implementation cost per year for updates, smaller extensions and adaptation to changed requirements. More important than the exact figure is that the budget exists permanently.
How do you recognise that support after go-live is missing?
By three signs: new spreadsheets beside the system, a growing unsorted list of open change requests, and the frequent sentence that the system cannot do that. Usually it can, but nobody has set it up.
The bigger picture behind this question: Never starting over again: how an ERP grows with the business.
Related
Related questions
In operation
Business Central go-live: how do I know whether we are ready?
Readiness is more than a green test report.
04.08.2026
Read →In operation
Set up intercompany in Business Central correctly
Same-environment or cross-environment: decide early.
04.08.2026
Read →In operation
Where does Business Central reach its limits?
Four limits, honestly named, and what follows for your decision.
21.09.2026
Read →Where does your project really stand?
At DGP you speak with an experienced consultant, not with a sales team.
Stay on top of things without tracking everything yourself.
Once a month, Frank Maier puts into context what is moving in the ERP world. Plus the invitation to the next live webinar.
About one email a month. Unsubscribe at any time with one click. Privacy policy