What is ERP production support? (And how it differs from managed services)

Assess the delivery system behind the service: coordinated expertise, accountable management, usable operating knowledge and flexible consumption. Ask how those elements continue when the workload changes.

Two things get called "ERP production support," and they have nothing to do with each other. One is a module: the manufacturing and shop-floor functionality inside an ERP — work orders, routings, production scheduling. The other is a service: operating the live ERP system itself, every day, after go-live. This article is about the service. If you searched for the module, you want your ERP vendor's product documentation, not a support partner.

With that settled, the real question buyers are asking is commercial: what is this service, and what are the ways to buy it?

What ERP production support covers

Production support is the operating layer of an ERP estate — the work that keeps a live JD Edwards, SAP, Oracle Fusion, or NetSuite system running and trusted:

  • Incidents and requests. The daily queue: broken transactions, stuck documents, user errors, access changes.
  • Batch and job scheduling. Overnight runs, failed jobs, reruns before the business opens.
  • Integrations. The EDI, banking, warehouse, and middleware connections that fail quietly and surface as business problems.
  • Period-end close support. Elevated coverage when finance is closing the books and every failed job has a deadline attached.
  • Patching and system administration. Applying updates, managing environments, CNC or Basis work, keeping the platform current and secure.

None of this is a project. It has no end date. It is a run-rate — which is exactly why the pricing model matters more here than anywhere else in the IT budget.

Three ways to buy the same work

The work above is roughly identical across providers. What differs is the contract wrapped around it. There are three basic structures.

Traditional managed services

A provider takes responsibility for a defined scope — often ticket categories, environments, or service levels written into a statement of work — for a fixed monthly fee. The fee is negotiated once, typically for a one- to three-year term, and stays flat regardless of how much work actually flows through the contract in a given month.

The appeal is budget certainty: one number, twelve times a year. The structural weakness is that the price is attached to the scope, not the work. If demand falls — because the estate stabilizes, because automation retires repeat tickets — the fee does not follow it down. The savings from a quieter queue accrue inside the contract, not to the buyer.

Staff augmentation

You rent capacity: a named CNC administrator, a Basis resource, an application analyst, priced hourly or as a monthly full-time-equivalent. The person joins your queue and works your priorities.

The appeal is control and fit — you direct the work, and deep individual knowledge accumulates. The weaknesses are granularity and continuity. You buy people in units of half-bodies and whole-bodies even when the workload is 1.3 of one skill and 0.4 of another, you carry bench risk when demand dips, and when the individual leaves, the knowledge leaves with them.

The comparison, honestly

The table is deliberately fair. A flat fee is not a trick — it is insurance, and insurance has a legitimate price. Hourly staff is not a trap — sometimes you genuinely need a specific person embedded in your team. The question is which risk you are paying to transfer, and whether the price of that transfer still makes sense once you can see the work.

When each model fits

Managed services fits when demand is genuinely stable and unknowable in detail, when the organization values a fixed number above all else, or when the buyer has no capacity to inspect the work and wants to hold a provider to outcomes instead. Budget certainty is a real good; some CFOs rationally pay for it.

Staff augmentation fits when the need is a whole person: a full-time skill gap, a project surge with a defined end, or expertise you want sitting inside your own management structure and meetings.

Consumption-based production support fits when the workload is variable, when the buyer wants the run-rate to fall rather than hold flat, and when visibility matters — a CIO who wants to know where the money goes task by task, or a CFO applying TBM-style cost transparency to the ERP line. It is the model to test if the last renewal conversation was "same scope, same fee" for the third year running.

What production support is not

One adjacent category causes real confusion: third-party software support — firms like Rimini Street and Spinnaker Support — replaces the software vendor's maintenance contract, the annual fee paid to Oracle or SAP for patches and vendor support. That is a different invoice entirely. Production support operates the system; it does not replace the vendor maintenance line, and third-party support does not run your batch jobs. Many companies rationally buy both. The distinction gets its own treatment in JD Edwards third-party support vs. production support.

Discuss your operating priorities →