What is the difference between a configuration, an extension, and custom development?

Configuration means turning on and setting up capability that standard SAP already ships, with no code. An extension adds behaviour SAP does not provide out of the box using SAP's released extensibility, either in-app for smaller changes or side-by-side on SAP BTP for larger ones. Custom development is a bespoke build for a requirement that neither standard configuration nor a released extension can meet.

Why should Fit-to-Standard be based on system evidence rather than workshops?

Workshops capture what people remember and believe, which misses code that is no longer used and processes that quietly drifted from the design. Grounding the analysis in the live estate shows what is actually running, how often, and against which objects. That turns a Fit-to-Standard split from an opinion into a number you can defend.

How does the Fit-to-Standard result drive migration scope?

The three buckets convert directly into work. What fits standard becomes configuration effort, what needs an extension becomes a controlled build on SAP's extensibility, and the custom slice becomes the estimate that carries the real risk. A percentage split that sums to 100 gives leadership a scope, a cost shape, and a Clean Core target in one view.

Blog · S/4HANA Readiness

Fit-to-Standard analysis the evidence-based way

Q: What is Fit-to-Standard analysis?

Fit-to-Standard analysis, also called fit-gap analysis, is the exercise of comparing how a business runs today against what standard SAP and its best-practice processes already support. It sorts each requirement into what fits standard SAP with configuration, what needs a compliant extension, and what needs genuine custom development. The result defines the scope of an S/4HANA project.

Sort what fits standard SAP from what needs a compliant extension and what needs custom code, using the system as it actually runs.

By C16.ai · AI for SAP operational efficiency

Every S/4HANA move eventually turns on one question: how much of the way you work today already fits standard SAP, and how much does not. Answer it well and the project has a scope, a cost shape and a target to build toward. Answer it from opinion in a workshop and the gaps show up later, in the estimate that keeps growing. Fit-to-Standard analysis is where that answer gets made, and it is worth making from evidence.

What is Fit-to-Standard analysis?

Fit-to-Standard analysis, also called fit-gap analysis, compares how your business runs today against what standard SAP and its best-practice processes already support. Each requirement lands in one of three buckets: it fits standard SAP with configuration, it needs a compliant extension, or it needs genuine custom development. That sorted picture is what the rest of a project is built on.

The name points at the intent. The goal is to fit the standard wherever the standard is good enough, because standard is what upgrades cleanly, stays supported, and keeps you close to SAP best practice. Fit-to-Standard is not a way to justify keeping everything you already have. It is a way to find out honestly how much of it standard SAP has since made unnecessary.

What is the difference between configuration, an extension, and custom development?

These three categories carry very different cost and risk, so getting each requirement into the right one is the whole point. Configuration sets up capability standard SAP already ships, with no code. An extension adds behaviour SAP does not provide out of the box, using SAP's released extensibility. Custom development is a bespoke build for something neither can meet.

Standard SAP plus configuration. The process is supported already; you switch it on and set it up. Cheapest to run, cleanest to upgrade, and the target for as much of the estate as honestly fits.
Compliant extension. A real gap that SAP's extensibility can close without touching the core. In-app extensibility handles smaller, in-system changes; side-by-side extensions on SAP BTP handle larger logic and integrations. This is the Clean Core way to keep custom behaviour without carrying upgrade risk.
Custom development. A requirement no standard setting or released extension can meet. Sometimes it is a genuine differentiator worth building; often it is a habit inherited from an old system. This slice deserves the hardest scrutiny because it carries the most cost and the most future maintenance.

A workshop tells you what people remember. The live system tells you what is actually running, how often, and against which objects. Only one of those survives a budget review.

Why should Fit-to-Standard be based on system evidence, not workshops?

Workshops capture belief, not behaviour. People describe the process as it was designed, forget the workaround added three years ago, and defend custom code no one has run since. Grounding the analysis in the live estate replaces that with what is measurably true, so the split becomes something you can defend rather than negotiate.

The gap between memory and reality is usually large. A meaningful share of custom objects in a long-running ECC system turn out to be unused, duplicated, or reproducing something standard SAP now does natively. You cannot see that from a room full of people talking about the process. You can see it from usage, from where the code actually reaches into the system, and from which standard capabilities have quietly caught up. Evidence shrinks the custom slice honestly instead of letting it grow by default. This is the same discipline that a serious SAP custom code assessment for S/4HANA applies to the ABAP estate.

What does a realistic Fit-to-Standard split look like?

A useful Fit-to-Standard result is a percentage breakdown that sums to 100, because leadership needs a whole picture, not a list of concerns. The exact numbers vary by industry and by how much an estate has drifted, but the shape is consistent: most requirements fit standard SAP, a meaningful portion needs a compliant extension, and a small slice genuinely needs custom development.

A realistic split might land near most of the estate fitting standard with configuration, a smaller share needing extensions, and only a thin slice needing true custom build. When the custom slice comes back large, that is itself the finding: it usually means old habits are being carried forward rather than genuine differentiation being protected. Forcing the buckets to add to 100 is what keeps the exercise honest, because every requirement has to be placed somewhere and nothing hides in the margins.

Illustrative shape, not fixed numbers. Grounding it in real usage is what makes the proportions trustworthy.

How the result drives migration scope

The value of a Fit-to-Standard split is that it converts straight into work. Each bucket becomes a workstream with its own effort profile, so the analysis stops being a document and starts being a plan. Nothing in the scope is left to discover mid-project.

What fits standard becomes configuration effort, which is the cheapest and most predictable part of the move. What needs an extension becomes a controlled build on SAP's released extensibility, sized against whether it is in-app or a side-by-side service on SAP BTP. The custom slice becomes the estimate that carries the real risk, and because it is small and evidence-backed, it is defensible rather than a source of surprise. That is also how the exercise sets a Clean Core target: the more that sits in the first two buckets, the closer the future system stays to standard and the cheaper every later upgrade becomes. When an extension has to reach data or trigger actions in the core, the choice between released SAP APIs and direct table access is what keeps it compliant. Fit-to-Standard is one input into the wider S/4HANA readiness assessment that frames the whole programme.

How C16 helps

C16 scores Fit-to-Standard from the live estate rather than from a workshop transcript. It reads the system to see what is actually in use and how each process really runs, then places requirements into fits-standard, needs-extension, and needs-custom, with the numbers adding to a whole.

Because the analysis is grounded in the system, every gap is tied to the objects behind it, so a finding is never just an assertion; you can trace it to the code, configuration, or process it came from and confirm it. C16 is read-only by default across the estate, so scoring your Fit-to-Standard changes nothing while it runs. Where a gap needs an extension, C16 drafts the compliant option, in-app or side-by-side, for an expert to review and approve. A person stays in the loop, and any change is made in a development system through your own change process, never on its own. The output is a Fit-to-Standard picture you can hand to leadership and to your implementation partner and know it will hold up.

See your Fit-to-Standard split from real evidence. C16 scores it from your live SAP and ties every gap to the objects behind it, on ECC or S/4HANA. Book a walkthrough.

C16 is read-only by default; any change it drafts ships only through your own change process. It queries the system on demand and does not retain your business data or use it to train models. Any change is made in a development system, reviewed and approved by an expert, and promoted through your own change process. C16.ai is a product of PEOL Technologies, an SAP Partner, and is ISO 27001 certified and SOC 2 Type II compliant.

← All posts