An ERP integration does not stop needing an owner when implementation ends.
The direct answer is: the company needs a named maintenance owner for every custom connection that sits outside the vendor's standard product. That owner might be the original implementation partner under a support agreement, an internal technical team, a platform provider managing supported connectors, or an independent software partner. The risky state is not choosing the “wrong” one. It is reaching handover with nobody responsible for the next API change, failed job, or exception path.
This is different from asking who supports the ERP itself. The ERP vendor should maintain its standard application, supported modules, product updates, security patches, and standard interfaces. A custom integration between the ERP and a warehouse, supplier portal, CRM, production file, or management report is a separate operating asset.
What usually breaks first after ERP go-live?
The first break is often at the boundary between systems, not inside the ERP.
One field changes upstream. A supplier sends a different file. An approval rule acquires an exception. A customer needs a report in a format the standard module does not produce. The happy path still works, but somebody starts copying, reconciling, or repairing the difficult cases by hand.
Singapore manufacturing workflows make this easy to picture. Production, inventory, finance, procurement, spreadsheets, and reporting tools can form one operating flow even when they are technically separate systems. If the workflow crosses those boundaries, the integration needs an owner after the launch team has left.
Separate four kinds of ownership
1. Standard product ownership
The ERP vendor owns defects and supported behaviour in the standard product. That includes product updates, documented APIs, and vendor-supported modules.
2. Implementation-scope ownership
The implementation partner owns the delivery and defects covered by its contract. If ongoing support is included, it may remain the right maintenance owner. If the engagement ends at handover, that responsibility does not automatically continue forever.
3. Business-rule ownership
The company owns the decisions that make the workflow specific: which event creates a finance record, which exception needs approval, which source is authoritative, and which report people use to run the business.
No technical partner can safely maintain those rules if the business has not named the person who can decide when they change.
4. Integration-maintenance ownership
Someone must own the custom code, connector configuration, monitoring, retry path, credentials, documentation, and change history around the integration.
That owner should be able to answer five questions:
- What starts the integration?
- Which system and field are the source of truth?
- How does the team know a run failed?
- Where can a person resume or repair it safely?
- Who updates it when an API, file, approval rule, or report requirement changes?
If those answers depend on one person's memory, the company has not completed the handover.
Do not replace the ERP before diagnosing the boundary
A broken integration does not prove the ERP choice was wrong.
Some gaps should be fixed through standard configuration. Some are process problems. Some need a vendor-supported connector. Others justify a small custom bridge, validation step, dashboard, or exception workflow around the existing stack.
Start with one flow where the manual repair is visible. Trace the record from the operating event to the finance or management output. Mark where data leaves a system, where a person intervenes, and what changes most often.
The result should be a small decision map, not a new feature backlog:
- configure the existing system;
- clarify the business rule;
- use a supported connector;
- build a small missing layer;
- assign ongoing maintenance.
A practical handover standard
Before the original implementation team leaves, collect the following for every non-standard integration:
- the business owner and technical owner;
- the systems, fields, and credentials involved;
- the trigger, expected output, and known exception paths;
- monitoring and failure alerts;
- retry, rollback, and manual-recovery steps;
- deployment and change history;
- a test case that proves the connection still works;
- the support window and escalation route.
This does not need to become a large governance programme. It needs to be clear enough that the next maintainer can diagnose a failure without reconstructing the project from chat messages.
Where an independent software partner fits
An independent post-go-live partner can make sense when the ERP remains fundamentally sound but a valuable company-specific workflow sits outside the standard product.
The role is not to replace the ERP vendor or reopen the whole implementation. It is to diagnose the boundary, build only the missing layer, and maintain that layer when the surrounding business or systems change.
The full Omni Care guide, including a five-question after-go-live diagnostic for Singapore SMEs, is available in ERP Went Live. Why Finance Still Does Not Tie Out.
