Johannes AuerIT Consulting GmbH

SAP VIM Transformation & Operations · Executive briefing

S/4HANA, RISE, public or private cloud. And yourinvoice intake?

For CFOs, CIOs, heads of accounts payable and transformation leads: this page addresses the VIM decisions that reach the S/4 programme too late — from the operating model through handover to operations.

The clock is running

  • 31 Dec 2025

    Maintenance ended for ECC 6.0 without EhP and for EhP 1 to 5 — already past

  • 31 Dec 2027

    End of mainstream maintenance for EhP 6, 7 and 8

  • 31 Dec 2030

    End of extended maintenance, at a surcharge of two percentage points

  • until 2040

    Maintenance commitment for S/4HANA — so the target is not an interim step

As of August 2026. Dates and terms are set by SAP, not by us.

SAP VIM Transformation & Operations · Executive briefing

What decision-makers need before the project

We make the VIM workstream actionable from current-state assessment through handover to operations. The outcome is not a generic strategy deck, but a target state that business, IT and programme leadership can work from together.

  • 01

    VIM current-state view

    Dependencies, risks and bottlenecks in today’s invoice intake — intelligible for business and IT.

  • 02

    A decision-ready target state

    Operating model, VIM target architecture and the decisions the programme must not leave open.

  • 03

    Delivery & operations plan

    Priorities, testing, responsibilities and handover into stable operations.

Why this is on the table right now

  • 01

    The deadline is closer than it looks

    Anyone still on an older enhancement package has been out of mainstream maintenance since the end of 2025. For everyone else it ends in 2027, the extension in 2030. A transformation takes one to three years depending on the company — count backwards.

  • 02

    The decision is not a technical one

    Public or private, RISE or self-operated, greenfield or conversion: these are decisions about degrees of freedom, running costs and how much of your own process you are allowed to keep. They are made early and are hard to reverse later.

  • 03

    The window is closing

    A transformation is the one occasion to straighten out historically grown processes without political resistance. Run it as a purely technical exercise and every workaround comes along — and gets paid off for another decade.

The three operating models, compared soberly

All three run S/4HANA. They differ in who operates them, how much you may change and who decides on upgrades. That is exactly what later determines what happens to your extensions.

On-premisePrivate edition (RISE)Public edition (GROW)
OperationsYou or your hosting partnerSAP under the contract, on the hyperscaler infrastructure of your choiceSAP, entirely
TenancyYour systemA dedicated instance for you aloneShared environment, everyone on the same level
Custom codeUnrestrictedPossible, including certified add-onsOnly under the clean-core model: key-user tools, extensions on BTP, ABAP Cloud
UpgradesYou decide whenRegular, with agreed windowsTwice a year, mandatory — always the latest release
Route inConversion or new buildConversion or new buildAlways a new build
FitsCompanies with their own operations team and a high degree of customisationGrown landscapes that want to keep their processes and still move to the cloudClose-to-standard processes, a fast start, little custom development

RISE, GROW — and why the products suddenly have different names

  • 01

    RISE with SAP

    Not a product but a contractual bundle: S/4HANA in the private edition, plus infrastructure, tools and services from one source. Aimed at existing customers with grown landscapes who want to hand over operations but keep their processes.

  • 02

    GROW with SAP

    The counterpart for the public edition: close-to-standard adoption based on pre-built processes, short project timelines, and clear limits on customisation. Meant for companies starting without heavy legacy baggage.

  • 03

    The 2025 renaming

    Since 2025 the public edition is simply called SAP Cloud ERP and the private edition SAP Cloud ERP Private, both under the SAP Business Suite umbrella. Technically nothing changed — but put a 2024 and a 2026 proposal side by side and you appear to be comparing different products.

The question that gets asked too late

OpenText VIM is an add-on inside the SAP system, not a neighbouring application. It lives where your SAP lives — and shares its rules. Which is why the operating model helps decide whether your invoice intake survives the transformation.

Caution when choosing the model

As things stand today, OpenText VIM does not run in the public edition.

VIM is a classic ABAP add-on inside the SAP system. The public edition — SAP Cloud ERP since 2025 — only admits add-ons built entirely to the ABAP Cloud model, and OpenText does not list it as a supported environment. A move there is therefore not a configuration question but the question of a different solution for invoice intake.

If the public edition is your target, you want to know this before deciding on the operating model — not during the test cycle. Verify the current position for your case with OpenText and SAP: this statement is as of August 2026, and cloud readiness of add-ons is a moving field.

Three routes there

  • New build (greenfield)

    An empty system, set up on the standard, with master data taken over selectively. The cleanest outcome, the biggest change for the business — and the only route into the public edition.

  • Conversion (brownfield)

    The existing system is lifted technically to S/4HANA, with history, customising and custom development. More predictable and faster, but the legacy comes along. For invoice intake often the gentlest route.

  • Selective (bluefield)

    The middle path: a new system, but a deliberate transfer of processes, transactional data and documents. More expensive to prepare, but you get to decide what comes along and what stays behind.

How we get invoice intake through the transformation

  1. 01

    Take stock

    What actually runs today: version, patch level, custom development, interfaces, channels. Usually this alone reveals how much of it was never needed — which is precisely what the health check is built for.

  2. 02

    Agree the target picture

    Operating model, timing, scope. And the uncomfortable question: which special cases come along, which die with the old system? That is a decision for the business, not for IT alone.

  3. 03

    Convert and test

    Adapting to the S/4 data models, rebuilding whatever cannot come along, testing business rules against real documents. It is not the migration that derails projects, it is the testing nobody planned for.

  4. 04

    Hand over stable

    Hypercare, knowledge transfer, a team that understands the new setup. If you want, we stay on afterwards — as 3rd-level support or in ongoing optimisation.

Five assumptions that make transformations expensive

  • 01

    “This is a technical project”

    The conversion is technical. The decision about degrees of freedom, processes and special cases is not — and it comes first. Leave it to the basis team and you will be surprised by outcomes nobody ordered.

  • 02

    “Our add-ons just come along”

    In the private edition, usually yes. In the public edition it means a rebuild under different rules, or a different product. That check belongs before the decision on the operating model, not after it.

  • 03

    “RISE means SAP does it for us”

    RISE takes operations off your hands, not the project. Data quality, process decisions, testing, training, sign-off and everything touching your extensions stay with you.

  • 04

    “Migrate first, optimise later”

    Sounds sensible, but doubles the work: you test every workaround once during migration and then rebuild it afterwards. Whatever is meant to die dies most cheaply before the move.

  • 05

    “2027 is still far away”

    For older enhancement packages mainstream maintenance already expired at the end of 2025. And consulting capacity is a market: the closer the deadline, the scarcer and more expensive it gets.

Eight questions before you decide

If you can answer these, your transformation project is well prepared. Every “not sure” is a risk that surfaces later — usually in the test cycle.

  1. Maintenance: which enhancement package is your system on — and how long is it genuinely still maintained?
  2. Operating model: has the choice between public and private been made — and does everyone involved know what it means for custom development?
  3. Add-ons: which additional solutions run in your system today, and which of them are permitted in the target model?
  4. Invoice intake: what happens to VIM, the intake channels and document capture — do they move, or do they need a new target picture?
  5. Custom development: how much Z code hangs off invoice intake, and how much of it is still used at all?
  6. Interfaces: which upstream systems, archives and networks are attached — and who tests them after the move?
  7. E-invoicing: does your transformation coincide with the German issuing mandate from 2027? Then two projects share one deadline.
  8. Sequence: what do you clean up before the migration, what after — and who decides that?

Next step

Where does your transformation stand?

In 30 minutes we sort out your starting position: operating model, timeline, and what it means for your invoice intake. No slides, no sales pitch, straight with the managing director.

S/4HANA and invoice intake: knowledge, condensed

OpenText VIM in an S/4HANA transformation

VIM survives a conversion, but not unchanged. The data models beneath the document change, custom development has to be checked against the new structures, and whatever grew as a workaround over the years surfaces in the test cycle at the latest. The cheapest moment for that inventory is before the project, not halfway through — which is what the SAP VIM Executive Diagnostic is for. If you want to keep the effort permanently low, SAP VIM Continuous Optimization is the format for afterwards.

Public or private edition: what hangs on it for invoice intake

The private edition allows certified add-ons and custom code — your VIM moves along, with business rules, role determination and workflow intact. The public edition works to the clean-core model: extensions run through key-user tools, the Business Technology Platform or ABAP Cloud, and add-ons must comply with that model entirely. For a grown invoice intake that means a different target picture rather than a move. This check belongs at the start — we do it together with you in SAP VIM Consulting.

Two projects, one deadline: transformation and the e-invoicing mandate

From 2027 the German issuing mandate takes effect in stages, and companies have had to be able to receive since 2025. If that coincides with your transformation, two initiatives compete for the same people and the same test cycle. That is manageable when you know early — and expensive when it surfaces mid-project. What is coming is laid out on the page about e-invoicing, SAP DRC and VIM; where paper stays in the mix, AI extraction helps contain the effort.

Key terms explained

The vocabulary of the transformation, alphabetically — for looking up when the steering committee drops three acronyms per sentence again.

ABAP Cloud
The development model for extensible cloud systems: only released interfaces are allowed instead of arbitrary access to the internals. That keeps extensions upgrade-safe — and it is exactly what the public edition requires.
Add-on
Additional software installed inside the SAP system rather than sitting next to it. OpenText VIM is such an add-on — the reason it shares the rules of whichever operating model you pick.
Bluefield
The selective route: a new system, but a deliberate transfer of processes and data from the old one. Not an SAP term but an established label for the middle path.
Brownfield
The technical conversion of the existing system to S/4HANA — with history, customising and custom development. Faster and more predictable than a new build, but the legacy comes along.
BTP (Business Technology Platform)
SAP’s platform for everything running alongside the ERP: extensions, integration, data, AI. In the public edition it is the designated place for functions that may no longer be built into the core.
Clean core
The guiding principle behind it: leave the ERP core untouched and extend only through released routes. The reward is smooth upgrades; the price is less freedom.
EhP (enhancement package)
The function packages SAP used to extend the old ERP over the years. Your level determines your maintenance deadline: EhP 0 to 5 have been out since the end of 2025, EhP 6 to 8 run until the end of 2027.
Fiori
The S/4HANA user interface: role-based apps in the browser instead of transaction codes. For invoice intake, the point at which it is decided what approvals will look like in future.
Greenfield
The new build on a blank slate: a new system on the standard, master data taken over selectively. The cleanest outcome, the biggest imposition on the business — and in the public edition the only route.
GROW with SAP
The adoption offering around the public edition: pre-built processes, short project timelines, clear limits on customisation. Meant for companies without heavy legacy baggage.
Hyperscaler
The large infrastructure providers — AWS, Microsoft Azure, Google Cloud. Under RISE your system runs on one of them; which one is part of the contract.
RISE with SAP
Not a product but a bundle: S/4HANA in the private edition together with infrastructure, tools and services in a single contract with SAP. The usual route for existing customers with grown landscapes.
SAP Business Suite
Since 2025 once again the umbrella over SAP’s application portfolio — and therefore a term that means something different today than it did in the 2010s. A common source of confusion when comparing old and new proposals.
SAP Cloud ERP
The name of the public edition since the 2025 renaming: a shared environment, operated by SAP, updated twice a year on a mandatory basis. Previously called SAP S/4HANA Cloud, public edition.
SAP Cloud ERP Private
The name of the private edition since 2025: a dedicated instance, operated by SAP, with room for custom code and certified add-ons. Previously SAP S/4HANA Cloud, private edition — the product behind RISE.
S/4HANA
SAP’s current ERP on the HANA database, with a simplified data model and the Fiori interface. The maintenance commitment runs to at least 2040 — so the target is not an interim step.
End of maintenance
The date from which SAP delivers no more corrections and no more legal updates. The system keeps running — just without cover, and with tax topics that is a problem.

Frequently asked questions

  • Does OpenText VIM run on SAP S/4HANA?

    Yes. OpenText lists the releases from ECC 6 up to S/4HANA as supported environments, both in your own data centre and in the private edition under RISE. The move is still work: the data models beneath the document change, custom development has to be checked against the new structures, and business rules belong tested against real documents. It is a move, not a rebuild — but it is not automatic either. Two points from the installation guide belong in every plan: a conversion from SAP ERP to S/4HANA as a rule includes the VIM upgrade, and if your VIM licence was bought through SAP, S/4HANA requires the licence “SAP Invoice Management for SAP S/4HANA by OpenText” — the conversion goes through your SAP sales representative.

  • Does VIM also run in S/4HANA Cloud public edition?

    The public edition is not on OpenText’s list of supported environments. The reason is structural: since the end of 2024 it does allow certified add-ons, but only ones built entirely to the ABAP Cloud model — registered namespace, uninstallable, upgrade-safe. A classically grown add-on does not meet that. If the public edition is your target, you need a different plan for invoice intake, and that check belongs before the decision on the operating model.

  • What is the difference between RISE with SAP and GROW with SAP?

    RISE bundles the private edition with infrastructure and services in one contract — meant for existing customers who want to hand over operations but keep their grown processes. GROW is the counterpart for the public edition: close-to-standard adoption, short project timelines, tighter limits on customisation. The essential difference is not the contract but how much of your own process is permitted.

  • Why do the SAP products suddenly have different names?

    SAP simplified the names in 2025: SAP S/4HANA Cloud, public edition became SAP Cloud ERP, the private edition became SAP Cloud ERP Private, both under the SAP Business Suite umbrella. Technically nothing changed. In practice it did: put proposals and concepts from different years side by side and you appear to be comparing different products.

  • How long is SAP ECC still maintained?

    That depends on the enhancement package. For ECC 6.0 without EhP and for EhP 1 to 5, mainstream maintenance already ended at the end of 2025. For EhP 6, 7 and 8 it runs until the end of 2027, followed by extended maintenance until the end of 2030 at a surcharge of two percentage points. What is binding is always SAP’s statement about your specific level.

  • Greenfield or brownfield — which is better for invoice intake?

    For invoice intake alone, conversion is usually the gentler route: business rules, role determination and workflow stay intact, the work lies in adaptation and testing. A new build is the opportunity to shed years of accumulated special cases — at the cost of design and change effort. The decision is rarely made on invoice intake anyway; what matters is that it features in the decision at all.

  • What happens to document capture in the cloud?

    Here the question is defused. OpenText offers recognition both as a cloud service and as a server you run yourself — locally or on a machine at a hyperscaler. Per the product documentation both are functionally equivalent and indistinguishable for the user; what differs is the business model and who is responsible for running it.

  • Should we clean up before or after the migration?

    Before, as far as you can. Everything you take along gets migrated once, tested once and quite possibly switched off afterwards anyway — so you pay for it twice. Conversely: whatever you retire before the move makes the migration smaller, the test shorter and the target system cleaner.

  • How long does an S/4HANA transformation take?

    Honestly, only after taking stock. As an order of magnitude: a conversion with manageable custom development tends towards a year, a new build in a group with several company codes towards two or three. What decides it is not system size but the amount of custom development, data quality and how fast your business units decide.

  • How does Johannes Auer IT Consulting help?

    We are not generalists for S/4HANA programmes — there are larger firms for that. We take on the part those firms rarely cover in depth: invoice intake. Taking stock of today’s VIM, the target picture for the chosen operating model, implementation and testing, then 3rd-level support if you want it. Including when the programme itself sits with someone else.