‍Why the instinct to customise is the single biggest risk in your SuccessFactors programme, and how leading organisations are finally letting go of it.

When organisations begin an SAP SuccessFactors implementation, the conversation in the project room almost always turns to the same question: how do we make it work the way we work today?

It is an understandable instinct. Legacy processes feel familiar. Teams have built workflows around them for years. The idea of changing how things are done, rather than changing the software to match how things are done, creates friction from day one.

But this instinct, when acted on, is the primary driver of failed, delayed, and over-budget SuccessFactors implementations. The "adopt not adapt" principle exists to counter it directly. It is SAP's own recommended approach, formalised through its Activate Methodology and Clean Core strategy, and it is increasingly the defining factor that separates successful programmes from expensive ones.

This article explains what the principle means, why it matters more than ever in 2025 and 2026, where the real tension lies, and how organisations can apply it without losing the capabilities they genuinely need.

What "Adopt Not Adapt" Actually Means

At its core, adopt not adapt is a design philosophy. It means that when implementing SuccessFactors, the starting position is always the standard product. If the standard process meets the business requirement, it is used as-is. If it does not quite match, the question is whether the business process can be adjusted to fit the standard, before any consideration is given to modifying the software.

The hierarchy runs like this:

Use the standard SuccessFactors process. No change to either the product or the business process.

Configure within the platform. Use SuccessFactors' own configuration tools, business rules, and MDF objects to meet the requirement without custom development.

Extend via SAP Business Technology Platform (BTP). Where a genuine gap exists that configuration cannot close, build a decoupled extension on BTP that sits outside the core product.

Change the business process. Often the right answer is not a technical one at all. The migration is an opportunity to rationalise processes that were bespoke because of the limitations of the legacy system, not because of genuine operational need.

What is explicitly off the table in a clean-core SuccessFactors implementation is modifying the product itself: custom ABAP Z-programs, BADIs, direct schema changes, or bespoke logic embedded inside the core. Every such modification creates what is now called technical debt. It complicates upgrades, blocks innovation features, and ties the organisation to code it will eventually be unable to maintain.

Why This Principle Matters More Now Than It Ever Did

Adopt not adapt is not a new idea. SAP has advocated for standardisation in its implementations for many years. What has changed is the consequence of ignoring it.

The upgrade problem is now structural

Legacy SAP environments operated on annual or biennial Support Pack cycles. Organisations could absorb some custom code into those cycles with managed effort. SuccessFactors releases twice a year, every year. SAP's 1H and 2H release cadence delivers continuous product improvements, new features, and compliance updates automatically.

A heavily customised SuccessFactors environment cannot absorb these releases cleanly. Each update requires regression testing against custom logic. Features that SAP ships in the standard product may conflict with bespoke configurations. The cost of maintaining customisation compounds with every release cycle.

Joule and AI capabilities require a clean core

SAP Joule, the AI copilot now embedded across SuccessFactors, is designed to work with standard data structures and standard process flows. SAP's own documentation and the 2H 2025 release notes make clear that systems need to be "Joule-ready" to absorb the full AI capability set. Organisations with fragmented data models, bespoke process logic, and non-standard configurations will find that Joule either cannot access the relevant data or delivers unreliable outputs.

In practical terms: customisation is now a direct barrier to AI adoption, not just an upgrade complication. Organisations that over-customise their SuccessFactors implementation today are making a deliberate choice to delay or foreclose AI-assisted HR in the future.

The data from the market is unambiguous

Panorama Consulting's 2025 ERP Report is instructive. Only 7% of organisations use their ERP system as-is. The remaining 93% require some form of customisation, and the research consistently links the degree of customisation to implementation cost overruns, delayed timelines, and reduced ROI. 47% of ERP implementations globally exceeded their original budget in 2023. The top causes: underestimated project staffing, scope expansion driven by bespoke requirements, and technical or data issues traced directly to customisation decisions.

These are not theoretical risks. They are the documented pattern of what happens when organisations prioritise replicating existing processes over adopting proven platform standards.

Where the Real Tension Lies

Framing adopt not adapt as "just use the standard product" makes it sound simpler than it is. The genuine tension in any large implementation comes from three directions.

Embedded legacy processes

Large organisations, particularly in the public sector, have HR processes that were built around the constraints of an on-premise system and have never been re-examined. Custom payroll schemas, bespoke time evaluation rules, and organisation-specific approval workflows have been running for so long that they are assumed to be requirements. In reality, many of them are workarounds for limitations that no longer exist in SuccessFactors.

The challenge is distinguishing genuine requirements from legacy habits. This requires facilitated fit-to-standard workshops, process owners who are willing to question how things work, and an implementation partner who understands both the product and the organisation's operational reality.

Accumulated custom code

Legacy SAP HCM environments typically carry years of ABAP custom code: Z-programs, BADIs, LSMWs, custom Fiori tiles. Each one was built for a reason. The adopt-not-adapt principle does not mean those reasons were wrong. It means that the migration is the moment to evaluate whether those reasons still apply, and whether the standard SuccessFactors product now meets the need.

A comprehensive custom code audit before implementation begins is not optional. Organisations that discover mid-implementation that they have more bespoke logic than accounted for face the worst possible position: a sunk cost argument for recreating that logic in the new environment, which is exactly the outcome the principle is designed to prevent.

Political and change management resistance

Adopt not adapt is ultimately a change management challenge, not a technical one. When a business owner says "our process doesn't work like that," the instinct of an implementation team under schedule pressure is to configure around the objection rather than address the underlying question of whether the process should change.

This is where implementations silently accumulate the customisation burden that surfaces as a problem eighteen months after go-live. The principle requires senior sponsorship. Without executive-level commitment to standardisation, individual teams will reliably argue their way to bespoke configurations, each justifiable in isolation, collectively fatal to the programme's long-term value.

A Practical Decision Framework

The table below shows how adopt not adapt applies to real implementation scenarios, using the classification framework SAP's own Clean Core methodology recommends:

The principle is not a prohibition on extension or configuration. It is a sequencing rule. The question is always: have we exhausted the standard product and its configuration options before considering anything beyond them?

Clean Core and BTP: Where Genuine Exceptions Go

SAP does not expect every requirement to be met by the standard product. That is why the Clean Core strategy includes BTP extensibility as a legitimate and supported path for genuine exceptions. The difference from legacy customisation is architectural: BTP extensions are decoupled from the SuccessFactors core. They do not interfere with platform upgrades. They can be maintained independently. They do not block Joule or future AI capabilities.

SAP's BTP extensibility wizard, now available within SuccessFactors, makes it easier to identify the right extensibility approach for a given requirement. Extensions built via BTP are version-safe. They are the right answer when configuration genuinely cannot close the gap.

What they are not is a licence to replicate legacy complexity in a new environment. The test remains: is this a genuine requirement that the standard product and its configuration tools cannot meet, or is it a preference for doing things the way they were done before?

What Adopt Not Adapt Looks Like in Practice

In a well-run SuccessFactors implementation, the adopt-not-adapt principle shapes the programme from the earliest design phase. Here is what that looks like at each stage:

Phase 0 and fit-to-standard workshops

Fit-to-standard workshops are the mechanism through which the principle is operationalised. The implementation partner demonstrates how the standard SuccessFactors product handles each key business process. Business owners assess the fit. Where gaps are identified, the first question is always: can the process change? The second is: can configuration close the gap? Custom extension is the last resort, not the default.

The quality of these workshops is critical. A superficial run-through of product functionality does not surface the difficult process questions. Effective fit-to-standard workshops require deep product knowledge from the implementation team, genuine process authority from the business side, and a programme governance structure that can make decisions when gaps are found.

Custom code remediation

For organisations migrating from legacy SAP HCM, the custom code audit is where adopt not adapt is tested most severely. Every piece of custom logic must be evaluated: does SuccessFactors standard functionality now cover this? Can configuration handle it? If the answer to both is no, then BTP extension is assessed. If the requirement no longer exists or was always a workaround, it is retired.

This process is uncomfortable. It surfaces decisions that were made years ago, often without documentation, and asks whether they are still valid. It requires the organisation to accept that some of what it built was a response to platform limitations that no longer apply.

Exception governance

Every programme will generate exception requests. The adopt-not-adapt principle does not mean none are granted. It means they are governed. A documented exception log, maintained throughout the implementation, captures every approved deviation from standard, the business justification, and the maintenance commitment. This log becomes the foundation for the post-go-live review and for future upgrade planning.

Without this governance, exception decisions accumulate silently and the programme ends up with a customised system that nobody has a complete view of. With it, the organisation retains visibility and control over its technical debt from day one.

The Common Objections, Addressed

Certain objections to adopt not adapt recur in almost every implementation. They deserve direct responses.

Our payroll is too complex for standard SuccessFactors

Employee Central Payroll retains the SAP payroll engine. The calculation complexity is supported. What is not supported is every bespoke PCR and Z wage type from an on-premise environment built up over fifteen years. The question is whether each of those bespoke elements still reflects a genuine payroll requirement or an inherited workaround.

Our organisation structure is unique

‍SuccessFactors Employee Central is a position-based, highly configurable HR data model. Most "unique" structures, when mapped properly, are addressable through standard configuration. The cases where they are not should be evidenced through a structured fit-to-standard process, not assumed from the outset.

We've always done it this way

‍This is the most honest objection and the least valid one. The migration is precisely the moment to ask whether legacy processes reflect operational necessity or institutional inertia. SAP SuccessFactors embeds best practice from thousands of implementations globally. The standard process is usually not worse than what the organisation built in 2009. It is often significantly better.

"The standard product doesn't support our compliance requirements."

‍SAP invests heavily in localisation and compliance content across SuccessFactors, including regular updates to reflect legislative changes. Before concluding that a compliance requirement demands custom development, it is worth verifying whether SAP already delivers it in a standard or near-standard way. It frequently does.

The Bottom Line

Adopt not adapt is the principle that separates organisations that get long-term value from SuccessFactors from those that spend the first three years fighting the platform they built.

It does not mean ignoring genuine requirements. It does not mean every organisation must work identically. It means treating the standard product as the first answer, not the last resort, and building a programme governance structure that enforces that choice even when it is uncomfortable.

The market evidence is clear. The cost of heavy customisation is not just a one-time implementation expense. It is a recurring cost across every upgrade cycle, every new feature release, and every AI capability that SAP ships. Organisations that adopt the standard product cleanly are able to absorb that innovation continuously. Those that do not will find themselves running an expensive, ageing system that requires constant maintenance to stand still.

SuccessFactors is a platform that gets better twice a year, automatically, by design. Adopt not adapt is how organisations actually receive that value.

Navigating a SuccessFactors implementation?

VE3 Global helps large and complex organisations design and deliver SAP SuccessFactors programmes built around the adopt-not-adapt principle. From fit-to-standard workshops and custom code audits to implementation delivery and post-go-live optimisation, we bring the expertise to make it work.

‍