HomeArticles → SRM & Ivalua
Career & strategy

Your SRM Skills Have an Expiry Date

SAP SRM is on a maintenance clock, and the guidance aimed at the people who run it is either Ariba marketing or a vendor pitch. Here is the neutral version — the dates, the options, and what happens to a decade of expertise.

8 min read By Tim Moore · Independent SAP consultant
SRM skills have an expiry date 2027 mainstream 2030 extended 3 paths out central proc · ariba · ivalua what transfers, what doesn't

If you administer SAP SRM, you already know a change is coming. What has been communicated far less clearly is what that change means for the people who run the system, rather than for the system itself. The available guidance tends to fall into two camps — marketing for SAP Ariba, or sales material from third-party vendors — and neither is written for the specialist trying to understand what happens to a decade of accumulated expertise.

This article sets out the dates that matter, the three genuine successor options, an honest assessment of whether Ivalua can replace SRM in an SAP environment, and, most importantly, which skills transfer and which expire.

The dates, and why they arrive sooner than they appear

SAP SRM is part of Business Suite 7 and follows its maintenance timeline. Mainstream maintenance ends in 2027. Optional extended maintenance runs to 2030, with customer-specific maintenance available beyond that at additional cost. SAP has confirmed no planned innovations for SRM, which means the product is effectively frozen: there is no improved version to wait for.

The cost of the extended-maintenance option is frequently misunderstood as a free way to buy time. It is not.

+2%Extended maintenance is charged on top of the standard maintenance fee \u2014 more each year, for a product receiving no innovation.

An organization taking that route pays more while competitors' procurement functions gain capabilities it cannot access.

The more important point concerns timing. A procurement transformation — properly scoped to include data migration, supplier onboarding, integration and change management — is comfortably a two-year program. Add the time required to secure budget and select an implementation partner, and the effective decision window is not 2030. It is now. For a specialist, raising this internally is worth doing, and being the person who raised it early is worth more still.

Three successor paths, not two

The replacement decision is often framed as a binary choice. In practice there are three distinct paths.

SAP S/4HANA for Central Procurement

This is SAP's own successor, and it is architecturally distinct from the others. Rather than being installed as a separate system, it is integrated directly into the core of S/4HANA as a procurement module, activated through configuration. In the multi-backend scenario, an S/4HANA system acts as a central hub connecting other systems — SAP and non-SAP, cloud and on-premise. For organizations whose procurement is largely internal and who do not have heavy supplier-collaboration requirements, Central Procurement covers a great deal of ground without introducing a new vendor.

SAP Ariba

Ariba is the cloud path, and the one SAP markets most heavily. Its strength is the external side of procurement: the supplier network, collaboration and sourcing. A separate variant exists for public sector organizations.

Leaving the SAP stack

The third path — moving to a third-party platform such as Ivalua or Coupa — is discussed least often within SAP circles, which is precisely why it deserves careful examination. It is a genuine option rather than an outlier, and the remainder of this article examines Ivalua specifically, because it is the one most often raised in SRM replacement conversations.

These paths are not mutually exclusive. Hybrid architectures are common, with one system handling the internal process and another managing supplier-facing work.

Central Procurement SAP's own successor In the S/4HANA core Activated by config Multi-backend hub Best when procurement is mostly internal. SAP Ariba The cloud path Supplier network Collaboration, sourcing Public-sector variant Best when supplier collaboration is the driver. Third party Leave the SAP stack Ivalua, Coupa ERP-independent You own integration Best when ERP independence has value. Not mutually exclusive — hybrid architectures are common.
The three successor paths, and the trade-off each optimizes for.

Can Ivalua actually replace SRM in an SAP environment?

The short answer is yes. This is an established pattern rather than a theoretical possibility, and implementation partners offer SRM-to-Ivalua replacement as a standard service.

80%+of Ivalua's own clients run SAP as their ERP. The product assumes an SAP back end — this is not an occasional pairing.

The figure that surprises people is that over eighty percent of Ivalua's own clients use SAP as their ERP. This is not a vendor that occasionally encounters SAP; it is one whose entire product assumes an SAP back end on the other side of the connection. A plug-and-play connector exists for ECC and S/4HANA on-premise, and for S/4HANA Cloud the integration workplace covers the same adaptors over web services.

The honest case for Ivalua over the SAP options rests on independence and configurability. An organization running more than one ERP — a common situation after acquisitions — gains real value from a procurement layer that is indifferent to what sits beneath it. Ivalua is also highly configurable in a way that SAP procurement historically has not been.

Where the third-party path hurts

The case against Ivalua is the part that does not come up in a sales meeting, and it is essential to understand before committing.

You own the integration permanently. With Central Procurement, the seam between procurement and the ERP is largely SAP's responsibility, because both belong to the same product family. Choosing a third-party platform makes that seam something your organization maintains, tests and troubleshoots through every release on both sides, indefinitely.

The standard interfaces are IDoc-based. Implementation partners are candid that IDoc-based integration proves too rigid and costly to adapt in practice. This is why a market of certified third-party connectors exists at all — and the existence of that market is itself informative. When a product's standard interfaces are surrounded by an ecosystem of connectors built to replace them, it indicates the standard interfaces are not sufficient. The connector should therefore be budgeted as a first-class workstream, not treated as a line item in the technical design.

Two data models create two sources of truth. The failure mode is specific enough that partners describe it directly: suppliers blocked in one system while orders continue to be placed in the other. Consistency between the two systems has to be engineered deliberately; it cannot be assumed. None of this rules Ivalua out. It does mean the person scoping the project must understand that data consistency across two systems is the project itself, not a phase within it.

What actually happens to your skills

This is the question the available content consistently avoids, and it deserves a direct answer in both directions.

What expires

SRM-specific technical knowledge does not transfer. This includes the SRM organizational structure, the SRM workflow engine, the design distinctions between classic, extended-classic and standalone scenarios, SRM-side enhancements, catalog integration as implemented in SRM, and the middleware connecting SRM to the back end. For many specialists this represents a decade or more of hard-won expertise, and it carries an expiry date. Stating that plainly is more useful than softening it.

What transfers, and gains value

Everything relating to the ERP back end transfers directly. Purchase orders, goods receipt, invoice verification, account assignment, material master and supplier master are unaffected by the change of procurement platform. Ivalua does not replace any of this; it sits on top of it and must communicate with it correctly. In an SRM-to-Ivalua project, the hardest question is what a requisition in Ivalua becomes in the back end, and whether that is correct. The person best placed to answer it is the one who spent years watching SRM documents flow into the ERP.

Procurement process knowledge transfers in the same way. Sourcing, contracting, approval logic, supplier qualification and the three-way match are properties of the process, not the system. Systems knowledge expires; process knowledge compounds.

The position worth aiming for

Pure Ivalua consultants do not know SAP. Pure SAP consultants do not know Ivalua. The scarce and valuable person is the one who can sit between the two and own both the process and the integration. This is not a lesser role than SRM configurator — it is a larger one, and it is the role that survives whichever path the organization ultimately chooses. The same seat exists under Ariba and under Central Procurement. The bet is not on a particular vendor; it is on the integration seam, and there is always a seam.

What to learn

Four areas of focus, none of which depend on the path the organization selects.

Deepen the back end rather than the front end. If procurement knowledge currently stops at the SRM boundary, extend it properly into Materials Management — how purchase orders behave, how account assignment works, what happens at goods receipt and invoice verification. This knowledge is required in every scenario.

Move from IDoc thinking to API thinking. The new landscape runs on web services and APIs. Becoming a developer is not necessary; being able to read an interface specification and identify that a field mapping is wrong, and what it will break, is.

Learn the Business Partner model if coming from ECC vendor master. It is mandatory in S/4HANA and consistently underestimated in scope.

Get into the selection conversation. Whatever the organization chooses, the person who understood the options early tends to lead the resulting workstream. This is the highest-leverage action on the list, and it costs nothing but attention.

The bottom line

SRM's mainstream maintenance ends in 2027, extended maintenance runs to 2030 at additional cost, and no new features are coming. There are three real successor paths, and Ivalua is a genuine option rather than an outsider — with the significant caveat that the integration becomes a permanent responsibility. For the specialist, the SRM-specific skills expire, but the back-end and process knowledge do not. They become more valuable, because they are what make the integration correct. Systems expire; the domain does not.

Sources & further reading

Maintenance dates and successor guidance have been revised before. Verify against SAP's published maintenance strategy for your own situation before making commitments. This article is independent commentary and is not affiliated with SAP, Ivalua, Ariba or any implementation partner.