SPDD, SPAU and the 35-minute transport

Every S/4HANA upgrade re-opens your modifications for manual review. SPDD handles ABAP Dictionary changes during the import; SPAU handles the rest of the repository afterwards; and a human signs off object by object. Separately, moving a change through the landscape is slow — community-reported production transports run around 35 minutes to Quality. Any commerce or route-to-market feature that touches ERP objects inherits both taxes, on every release.

What are SPDD and SPAU actually doing?

They are the two halves of modification adjustment. When you upgrade, the new SAP version ships its own versions of dictionary and repository objects. Wherever those collide with something you changed — or something you depend on that SAP changed — the system stops and asks a person to decide: keep the modification, take the SAP version, or merge the two. SPDD runs during the import for ABAP Dictionary objects (tables, domains, data elements) so that structures and data are not silently dropped. SPAU runs afterwards for the rest: programs, function modules, screens, message classes. Neither step is optional if you carry modifications, and the number of prompts scales with how much standard SAP you have touched.

The trap is treating the adjustment as a one-off. A migration skills brief on GitHub lists the failure mode in a single line:

Not creating adjustment transports -> adjustments are lost on the next system refresh.

Read that carefully. The adjustments themselves have to be captured into their own transports; if they are not, the next refresh from production — or the next upgrade — re-imposes exactly the same manual work, and whatever a tired engineer clicked at 2am is simply gone. So the cost is not the upgrade weekend alone. It is a recurring, judgement-heavy chore that has to be done correctly and then preserved, every single time the landscape moves.

Why does a 35-minute transport change how you plan releases?

Because latency in the delivery pipeline stops being an engineering detail and becomes a scheduling constraint. Community reports put production transports at roughly 35 minutes to reach Quality environments, against 2 to 5 minutes in pre-production. That is seven to seventeen times slower for the environments that matter most, and the gap is structural: import buffer synchronisation, activation, and dependency checks all grow with the size of the landscape and the number of objects sitting in the queue.

The raw number is survivable once. What it changes is behaviour. When each import window costs the better part of an hour, teams batch. They serialise transports to avoid collisions, they book import slots, and they hold changes back so they can move them together. A pipeline you cannot run cheaply on demand is a pipeline you run on a calendar — and that calendar now owns your release cadence rather than your product plan.

What does the ERP transport calendar cost a commerce team?

Everything that touches an ERP object rides the same path. Pricing conditions, output determination, the custom tables behind a returnables or loyalty flow, IDoc and interface changes for order capture — all of it moves through the same transport queue, and all of it faces the same SPDD or SPAU adjustment on the next upgrade. A web team used to shipping several times a day suddenly finds its feature gated by an import window and a freeze period wrapped around an S/4 upgrade it did not schedule and cannot move.

This is the same class of problem we keep running into elsewhere: capabilities that quietly carry their own operational weight. An orchestration layer that needs its own ops team just to keep running couples your release plan to its upgrade cycle; promotion logic buried in a rule builder nobody can read six months later ages exactly the same way; and field features inherit the same latency reality that turns a promised offline sync into a thirty-minute wait. In each case the feature is fine in isolation. The problem is where it is anchored.

The compounding effect is what leadership tends to miss. Modification adjustment is charged per upgrade, transport latency is charged per release, and freeze windows are charged per upgrade project — so the more customer-facing capability you build inside the ERP, the more of your roadmap ends up denominated in SAP's clock instead of your own. It is not one big bill. It is a small tax collected on every change, forever.

So where does route-to-market actually belong?

None of this means SPDD, SPAU, or slow transports are defects — they exist because the financial core deserves that level of control, and it should keep it. The fix direction is narrower than ripping anything out: order capture, loyalty, returnables and delivery do not need to live inside that discipline. Run them on an event bus that reads from and writes to SAP through stable interfaces, and their deploy cadence stops depending on the upgrade calendar entirely — the ERP stays rigorous while the commerce surface ships on its own schedule, which is the whole intent behind our route-to-market architecture.

The next S/4 upgrade wave will arrive on its own timeline regardless of what your commerce roadmap wants from it. The only variable you genuinely control is how many of your customer-facing features are strapped to that timeline. The teams drawing the line now — deciding deliberately which objects belong in the transport queue and which belong on the bus — are the ones who will not spend their next upgrade weekend re-adjusting modifications they were sure they had already fixed.