Who Maintains ERP Customisations After Go-Live?

An ERP can be live and still leave important work outside the system.

The finance team may still reconcile production data by hand. A warehouse may keep a side spreadsheet because a customer needs a non-standard format. A report may still take half a day because the ERP data does not match the way management reviews the business.

This does not automatically mean the ERP project failed. It means the company has moved from an implementation problem to a maintenance and integration problem.

The direct answer to “who maintains ERP customisations after implementation?” is: the owner depends on the layer.

The ERP vendor maintains the standard product.
The implementation partner covers the agreed deployment scope.
The internal team owns the business rules.
Custom workflows, integrations, and reports built around the ERP need a maintenance owner too. That can be an independent post-go-live software partner working separately from the original ERP licence.

Why the ownership gap appears after go-live

Implementation work is designed to get the standard system configured, migrated, tested, and live. The business then keeps changing.

A new supplier portal appears. A customer requests a different reporting format. A machine data source needs to feed quality reporting. A new warehouse process creates an edge case. An API changes. A spreadsheet that was supposed to disappear still contains the rule the business actually follows.

Someone has to own those changes. If nobody does, the work returns to email, spreadsheets, manual checks, and one person who knows how the process really works.

This is also why integration work is not finished when the first connector works. Workato’s 2026 Singapore ERP integration guide distinguishes the one-time integration build from the maintenance that returns as ERP APIs, connected-system schemas, and compliance requirements change.

The three ownership layers

1. The ERP vendor: the standard product

The ERP vendor should own the core application: supported modules, product updates, standard APIs, security patches, and defects in the standard product.

That responsibility should not be confused with ownership of every company-specific workflow around the ERP.

2. The internal team: the business rule

The company must own the decision about how the business works.

For example, an internal finance or operations owner should be able to explain what counts as a valid reconciliation, which exceptions require approval, which customer format is correct, and what happens when source data is incomplete.

An external developer can encode those rules, but should not invent them.

3. A post-go-live software partner: the missing bridge

The missing layer is often the software around the live ERP:

a workflow that connects a non-standard operational process to the system of record;
an integration between the ERP and a supplier, customer, warehouse, or machine-data source;
a report that turns ERP data into the exact operating view management needs;
a maintained automation that replaces repeated copying, checking, reconciliation, or reformatting.

These problems may be too specific for the standard ERP roadmap and too small for another major implementation project. They are also too important to leave as unmaintained one-off scripts.

The useful shape is smaller and more accountable: diagnose the gap, decide what is worth fixing, build only the narrow useful part, and name the maintenance owner before release.

What to diagnose before approving a custom build

Start by mapping the live ERP, spreadsheets, portals, machine data, reporting packs, and manual handoffs. Find the exact point where work leaves the system and returns to a person.

Then answer five questions:

Which workflow is still manual?
Who uses it, and how often?
What goes wrong when it fails?
Does the gap affect inventory trust, costing, delivery, cash collection, customer commitments, compliance, or recurring management time?
Who will maintain the workflow after the first release?

The first fix might be an integration, a report, an approval workflow, an automation, or simply a clearer operating rule. Not every workaround needs software.

Avoid replacing a spreadsheet until the business rule inside it is understood. Prefer one narrow workflow the team will use over a broad system nobody owns.

Why this matters for Singapore SMEs

Singapore companies face a capacity problem as well as a software problem. ManpowerGroup’s 2026 Singapore Talent Shortage Survey reported that 71% of employers had difficulty hiring skilled talent. Its Singapore coverage also identified AI model and application development, and AI literacy, as the hardest skills to find locally in 2026.

For an SME, the question is therefore not only whether a missing integration can be imagined. It is who will build and maintain it without turning every post-go-live gap into a permanent hiring problem.

An independent post-go-live partner can make sense when the ERP is fundamentally sound, but a valuable company-specific workflow sits outside the standard product and needs a durable engineering owner. The partner should complement the ERP vendor, not replace it.

A better buyer question

The weak question is: “Did we implement ERP?”

The better question is: “After go-live, which important part of the business still depends on a person copying, checking, reconciling, or reformatting data by hand?”

If the answer is “nothing important,” the company may not need another build.

If production and finance still do not match, customer-specific reporting is still manual, the warehouse still uses side spreadsheets, an integration breaks whenever something changes, or only one person understands the workflow, then go-live was not the end of the software problem. It was the moment the next problem became visible.

Omni Care works on this post-go-live layer for Singapore SMEs: diagnosing, building, and maintaining custom workflows, integrations, and reports around a live ERP. The full article and diagnostic path are available in The Gap After Go-Live.