What is the difference between fit-to-standard and fit-gap analysis in SAP?

The methods differ in one thing: who has to justify the deviation

Both approaches put the same people in the same room and walk the same processes. What changes is the default answer when the business describes how it works today and the standard system works differently.

In a fit-gap, that difference is logged as a gap — a defect in the software relative to the requirement — and the natural next step is to size the development that closes it. In fit-to-standard, the same difference is logged as a proposed exception, and it does not proceed until someone names the business value that justifies carrying it for the next decade. Neither method is dishonest. But the first one has a gravitational pull toward custom code and the second one has a gravitational pull toward standard, and over a few hundred decisions that pull is the whole result.

A useful analogy: fit-gap is a home renovation where every existing wall stays unless you prove it should come down. Fit-to-standard is a new floor plan where every wall you want to keep has to be argued for. Same house, same budget, radically different building.

Why fit-gap quietly re-approves your workarounds

The requirements a fit-gap collects are gathered from the people who run the current process, and those people describe the process as it exists — including the parts that exist only because ECC in 2009 could not do something ECC in 2019, or S/4HANA today, can. Nobody is being obstructive. They are describing reality, and the reality includes twenty years of accumulated compensation.

The classic example is a credit-check enhancement sitting in MV45AFZZ. It encodes a real business rule, so in a fit-gap it is a valid requirement and it gets re-implemented. Read the rule out of the code and compare it with what SAP Credit Management in FSCM now does natively, and a large share of those enhancements turn out to be reproducible as configuration. The requirement was always legitimate; the custom object was not.

This is why fit-to-standard has to be evidence-led rather than memory-led. If the input is only what people can recall about why an object exists, you will re-approve the estate you already have.

What evidence replaces the workshop opinion

A fit-to-standard analysis is only as good as the reads behind it. The system already holds most of the evidence, and every one of these is a read-only query — no extract, no row-level customer data.

• Custom object inventory with authorship and last-change dates — what exists, and how much of it anyone has touched this decade.
• The source itself, summarized into the business rule it encodes, so the discussion is about the rule rather than about the ABAP.
• Where-used and execution evidence — an object nobody calls is not a gap, it is dead weight, and it should be retired rather than converted.
• Static analysis (ATC with the S/4HANA readiness checks) for the objects that must survive, which separates "works after conversion" from "needs remediation."
• Document flow and configuration reads that show how the process actually runs today, so the standard comparison is against behavior rather than against a process diagram nobody has updated.

Fit-to-standard does not mean "no extensions"

The most common objection is that fit-to-standard is a euphemism for telling the business to change how it works to suit the software. Sometimes it is exactly that, and sometimes that is correct — a process differentiating nothing should not be carrying custom code. But the discipline is not a ban on extension, it is a rule about where extension lives.

Real differentiation earns an exception, and a clean-core exception is built on released APIs and side-by-side extensibility rather than a modification to core. The object survives the upgrade instead of being rediscovered during the next one. What fit-to-standard removes is the third category — the deviation that is neither differentiating nor cheap, kept because retiring it requires a decision nobody wants to own.

The decision log matters as much as the outcome. Six months into the project someone will ask why an enhancement was retired, and the answer needs to be a recorded decision with the evidence attached, not a recollection from a workshop.

How the choice changes the migration plan

Fit-gap tends to produce a technical conversion with a development backlog attached, which is the safest-looking plan and the one that carries the old estate forward intact. Fit-to-standard produces a smaller conversion scope, a retirement list, and a shorter tail of remediation — but only if the analysis happens before the conversion approach is chosen, not after.

It also feeds the business case with numbers finance can audit. Retirement counts, avoided rebuild effort, and measured cycle times are arithmetic over specific reads; a gap list is a cost estimate with no offsetting benefit. Do the analysis first and the conversion decision follows from evidence. Do it after and you have already committed to carrying whatever the workshop approved.