Pe scurt

The plant has been live for six weeks, and the project team is booked onto the next site. That departure date reflects programme budget, not local capability. Useful ERP hypercare exit criteria ask a narrower question. Can the plant, the group function and the partner each resolve the requests reaching them tomorrow? The group is choosing between a full exit, a staged exit and retained support, and should record the choice.

ERP hypercare exit criteria begin with a documented handover decision

Hypercare is the period of intensified support immediately after launch, when the people who built the system stay close to the people using it. It ends on a date agreed long before anyone saw a live month. A completed launch and a support organisation ready to take over are separate milestones.

Setting that date early is reasonable. Finance approves budgets against a schedule, and the next wave already claims the specialists. The difficulty starts when the date becomes a finding about the plant rather than a decision about resources. The group CIO and the programme sponsor need evidence they could show afterwards.

However, the calendar behind the date is crowded. SAP SE confirmed on 7 October 2026 that mainstream maintenance for SAP Business Suite 7 ends on 31 December 2027. Optional extended maintenance runs to 31 December 2030. The Raportul de investiții DSAG 2026 surveyed 198 member companies of the Deutschsprachige SAP-Anwendergruppe. Of those, 54 per cent still used SAP ECC or an older Business Suite, and 42 per cent planned high or medium SAP S/4HANA on-premises investment in 2026. DSAG notes that its 2026 sample compares better with 2024 than with 2025.

Define the support boundary before the ERP support handover

After the project team leaves, four parties can receive a request: the plant, the group function, the system integrator and the software provider. Each carries a different contract, cost and response speed. Without a written boundary, the request reaches whoever answered last week, who now works elsewhere.

Microsoft's Dynamics 365 implementation guidance defines support scope as what is supported, who supports it, when and how. An ERP support handover naming only functions leaves the same gap in tidier form. Each category needs a named person and a deputy, because ERP hypercare exit criteria stay weak without that boundary.

A worked example of local and group responsibility

The boundary becomes real only when it meets requests the plant will raise. Five representative items, each with an owner, expose the cases nobody considered. The list illustrates the discipline, not a fixed allocation.

• A blocked goods receipt from a master data error: the plant resolves it, because the data owner sits there.
• A pricing condition that departs from the group design: the group process owner decides.
• An overnight interface to the Austrian warehouse: the integrator investigates, the group function owns the consequence.
• A defect reproducible in a clean environment: only the software provider can close it.
• A request matching none of these: it falls to the programme sponsor.

Commercial terms show how narrow definitions can be. SAP’s service description for its Enhanced Operations Service for Hypercare Phase sets a four-week duration and a three-week planning lead time. Its scope covers SAP Basis, database and server management on SAP Cloud ERP Private. It says nothing about how long a plant needs support.

Prove local ERP support readiness with representative issues

A plant demonstrates local ERP support readiness; it does not declare it. In the final weeks of hypercare, the project team should observe while local people resolve issues that occurred earlier. The test is whether the request reaches the right person, and whether that person can act.

Escalation needs exercise instead of documentation. A path that exists only in a slide has never met a severity-one incident at an inconvenient hour. Run two or three deliberate escalations while central resources remain on site, and see whether the permanent support function can carry the load.

Shift coverage and language in a continuously operating plant

In addition, coverage is usually the weakest part of the arrangement. Directive 2003/88/EC defines shift work as workers succeeding each other at the same work stations, continuously or otherwise. Slovakia produced around 1.07 million vehicles in 2025. Zväz automobilového priemyslu SR, the Slovak Automotive Industry Association, reported those preliminary figures on 13 January 2026. A plant feeding that volume does not stop at 17:00, so a night fault waits until morning.

Language also belongs in the same decision. If the plant raises requests in Slovak while the group desk works in German, translation becomes an unrecorded step in every incident. The Austrian Federal Economic Chamber counts about 49,000 employees across 80 shared service centres in Slovakia. A group working between Vienna and Bratislava, Trnava, Žilina or Nitra rarely starts from nothing.

Dispose of open work before the post-go-live support transition

A post-go-live support transition does not require an empty queue, and a zero-ticket rule is not realistic. Every open item should leave hypercare with an owner, a business consequence and a review date. Practical ERP hypercare exit criteria treat open items as assignments rather than blockers.

Forvis Mazars reports that Act No. 385/2025, published on 19 December 2025, amends Act No. 222/2004 Coll. on value added tax. From 1 January 2027, domestic VAT payers must issue and receive invoices in a prescribed electronic format. They must also report domestic supply data to the Financial Administration of the Slovak Republic. The act transposes Council Directive (EU) 2025/516 on VAT rules for the digital age.

A plant going live in late 2026 meets that change weeks after its launch team leaves. It may belong to the group template team, to local finance, or to an unpriced change request. Deciding which, before the team disperses, costs less than deciding it in December.

The support handover record

One record keeps the decision auditable and takes about an hour per process area. Complete it while the project team can still answer questions, because it becomes the group’s durable statement of local ERP support readiness. Finally, the plant leader and the group CIO sign it, and it captures six items per request category:

1. Issue type, in business terms rather than system terms.
2. Owner: local, group or partner, named as a person.
3. Coverage and access: hours, language and permissions to act.
4. Escalation tested: the date, and the result.
5. Open dependency: statutory and interface items, with dates.
6. Exit decision: full, staged or retained support.

Choose the exit: full, staged or retained support

The group can approve a full exit, stage it by process, or retain defined capacity. A full exit returns everything to the permanent support function. A staged exit keeps central support for named processes, so it is a decision about scope rather than time. Each option needs an owner, a reason and a review point.

Naming two or three processes that keep central help is cheaper than extending everything. It is also clearer to the plant. The next site benefits too, because the group releases specialists deliberately.

Retained support without a review date becomes the dependency the group wanted to avoid. Where capacity stays, the record should state what evidence ends it. A CE Interim case study on an interim supply chain mandate shows the same ordering problem, in a warehouse programme running alongside a delayed SAP Extended Warehouse Management rollout.

Questions groups ask before ending hypercare

What is ERP hypercare?

Hypercare is the period of intensified support immediately after a system goes live. The people who built it stay close to the people using it. It exists because live operation produces issues that testing does not.

Must every issue be closed before hypercare ends?

No, and treating an empty queue as the standard delays the handover without improving it. Each open issue needs an owner, a consequence and a review date. A documented list of known issues beats a short queue achieved by reclassifying work.

Who owns issues after the project team leaves?

Ownership follows the boundary agreed before departure. The plant takes local data questions, and the group function takes design and cross-site matters. The integrator takes contracted deliverables, and the software provider takes defects. Anything else defaults to the programme sponsor.

How does a phased support handover differ from extending the whole programme?

A phased ERP support handover returns most request categories to the permanent support function. Central help stays for named exceptions. Extending the programme instead keeps the whole project structure and its claim on specialists.

Decizia care trebuie luată în fața grupului

The choice is between a full exit, a staged exit and retained support with an owner and a review date. The group should not let the agreed departure date stand in for it. The programme set that date before the evidence existed, and a post-go-live support transition is a decision the group should record as one.

Where the permanent support function is ready and resourced, it should lead the handover. Where nobody owns the boundary itself, an ERP Programme Director or Transformation Director can organise a bounded handover and leave once the record is agreed. CE Interim, part of Valtus Alliance, structures that kind of mandate between an Austrian headquarters and a Slovak industrial operation.

The cost of getting this wrong is rarely dramatic, which is part of the problem. It shows up as a slower month-end close, workarounds that harden into labour cost, and a late statutory change. Applied properly, ERP hypercare exit criteria describe a handover the group can defend, not a date already booked.