How do you run a fit-to-standard workshop for an S/4HANA migration?

Why most fit-to-standard workshops turn into fit-gap by accident

SAP Activate places fit-to-standard workshops at the start of the Explore phase, and the intent is clear: show the standard process, confirm the business can run on it, capture the genuine deltas. In practice the sessions drift. A consultant demonstrates a process in a vanilla sandbox, a process owner recognizes a step that ECC handles differently, someone writes it down as a gap, and by the end of the day the gap list is the deliverable. Nobody asked whether the ECC behavior exists because the business needs it or because a developer added it in 2009 and no one has looked since.

The drift happens because the workshop is anchored on the wrong artifact. If the input is the standard process and the business's memory, the output will be a list of ways the business differs. If the input is the evidenced inventory of what the current system does, including how often each customization actually executes, the conversation changes: the question becomes 'this exit fires on 3% of orders and enforces a rule that S/4HANA delivers in configuration; do we keep it?' That is a decision a process owner can make in two minutes. A gap statement written from memory takes weeks to resolve and usually survives into the build.

What has to be on the table before the workshop starts

The preparation is where the workshop is won, and most of it is system work rather than meeting work. Each item below should exist as a document the attendees have seen before they walk in.

• A custom-object inventory for the process in scope, drawn from the live system: user exits, enhancements, custom reports, Z-tables, and modifications, each with a one-line statement of the business rule it implements and evidence of whether it still executes. On a reference estate, a live ECC system used to validate this method rather than a specific customer's result, this was 356 objects across the whole estate; a customer's count comes from their own system.
• The current configuration for the process, read from the customizing tables rather than from a ten-year-old blueprint: sales areas, document types, pricing procedures, credit settings, output determination. Stale blueprints are the second most common cause of wrong workshop decisions after stale memory.
• The standard S/4HANA process, demonstrable end to end in a sandbox that already carries the customer's enterprise structure, so the process owner sees their company codes and plants rather than a demo company. Abstract demos invite abstract gaps.
• A short list of known simplification items for the process (classic credit management, output management, business partner, pricing table changes) so that mandatory changes are separated from optional ones up front.
• A decision rule, agreed with the steering group beforehand: the default is standard; a customization is retained only with a named business owner, a stated reason the standard cannot deliver the outcome, and an estimate of what keeping it costs at every future upgrade.

How to run the session itself

Scope one workshop to one end-to-end process and one process owner who can decide. Order-to-cash gets a session; sales-order entry, delivery, and billing do not get three. Attendance is the process owner, one or two power users who run the process daily, the functional consultant for the area, and someone who can read the custom code and answer 'what does this exit actually do' without going away to check. Steering-level attendees make the room polite and slow; keep them for the readout.

Walk the standard process step by step in the sandbox, and at each step surface the inventory: which customizations, exits, or configuration touch this step in ECC today. For each one, take the decision then and there and record it in one of four dispositions: adopt standard (retire the customization), keep as configuration (the rule exists in S/4HANA as standard configuration, so it is not a gap at all), re-implement as a clean-core extension (the rule is real and standard does not cover it), or defer with an owner and a date. 'Discuss later' is not a disposition. The functional-testing question, how we will prove the standard step handles the volume and edge cases the exit used to, is captured alongside each adopt-standard decision so the test scope grows from the workshop rather than being invented afterwards.

Time-box hard. A mature order-to-cash process with fifty to eighty touched objects is a two-day workshop if the inventory is prepared and a two-week argument if it is not. Finish each day with the disposition list on screen and the process owner confirming it, so the record is theirs rather than the consultant's.

What comes out, and what it feeds

The deliverable is a disposition register: every customization in scope, its business rule, evidence of use, the decision, the owner, and for re-implementations a pointer to the extension pattern that will replace it. That register is the source for three downstream artifacts. The custom-code retirement plan comes straight from the adopt-standard rows; on the reference estate, roughly 44% of inventoried objects were assessed as retirable through exactly this chain, with credit-management and output logic the richest sources. The configuration cookbook comes from the keep-as-configuration rows, which is where the SPRO work for the target system is defined. And the business case is refined, because the effort estimate is now built from counted objects with decisions attached rather than from an assumption about how customized the estate is.

This is also where an agent earns its place. Reading the live system through governed, read-only tools to build the inventory, profile how often each exit fires, and trace where-used across the process is work that used to consume the first month of Explore and can now be prepared before the first workshop is booked. Where a workshop decision produces target configuration, the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never touching production on its own. Our functional-testing agent, which would take each adopt-standard decision through the process to prove the standard step holds, is in build and design preview, not shipped. SAP's own direction is agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026); the fit-to-standard workshop is the phase where that claim is most testable, because its cost is almost entirely preparation and decision latency.

The failure modes to design against

Three patterns account for most wasted workshops. The first is the demo workshop: the consultant shows the standard, the business nods, and no decisions are recorded because no inventory was presented; the gaps surface in realization when the code is inspected. The second is the wish-list workshop: the business treats the session as a chance to ask for what ECC never gave them, and the register fills with new requirements rather than dispositions on existing ones. New requirements are legitimate, but they belong in a separate backlog with their own business case, not in the fit-to-standard record. The third is the proxy workshop: the process owner sends a delegate who cannot decide, every disposition becomes 'to be confirmed', and the register is fiction.

Each has the same cure: the right evidence in the room, the right person in the chair, and a decision rule that was agreed before the meeting so the workshop is not the place to relitigate whether standard is the default. Fit-to-standard is a governance stance as much as a method. The workshop is where the stance gets applied, one customization at a time.