SPAU and SPDD: Modification Adjustment in an Upgrade

Decision context

Modification adjustment is the part of an upgrade that cannot be scheduled accurately, because its size depends on how many SAP objects were modified over the previous decade and how well those modifications were documented.

The two transactions split by object type and by timing. SPDD handles modified dictionary objects and is prompted during the upgrade, in the phase where the dictionary is being replaced. SPAU handles modified repository objects and is done after the upgrade completes. SPAU_ENH covers enhancement implementations.

The timing distinction is the one that costs money when missed. SPDD is prompted during the upgrade for a reason: if the modified dictionary definitions are not adjusted at that point, the SAP versions replace them and the associated data handling follows the standard definition.

SPDD, during the upgrade

SPDD covers modified ABAP Dictionary objects: domains, data elements, tables, structures, and indexes. It is prompted at the point in the upgrade where the dictionary is being brought to the new release.

• Appended fields on standard tables generally do not require adjustment, because an append is an extension rather than a modification. Direct changes to a delivered table's fields do.
• Decide keep or reset per object, and prefer reset unless there is a business reason for the modification that the new release does not already satisfy. A release frequently delivers what a modification was made for years ago.
• The adjustment happens while the upgrade waits. Have the ABAP owner available in that window rather than paged for it, because the upgrade is holding.
• Missing the SPDD prompt means the dictionary takes the SAP definition. Where the modification affected field lengths, types, or keys, the consequences reach the data and are not always visible immediately.
• Record the decision per object with a reason. This list is the input to the same decision in the next system and the next upgrade.

SPAU, after the upgrade

SPAU covers modified repository objects: programs, includes, function modules, classes, interfaces, screens, and message classes. The work list is grouped by how much manual effort each object needs.

• Objects adjusted with the Modification Assistant carry the modification separately from the SAP source, so the adjustment is often semi-automatic and the comparison is meaningful.
• Objects modified without the Modification Assistant have to be compared manually against the new SAP version, which is where the effort concentrates and where the estimate is worst.
• Note corrections that the new release already contains can usually be reset, and this is the largest single source of quick reductions in the SPAU list.
• For every remaining object, the choice is keep the modification, reset to the SAP standard, or reimplement the requirement as an enhancement rather than a modification.
• Resetting is the choice that reduces the next upgrade's work list. Keeping is the choice that has to justify itself each time.
• SPAU_ENH handles enhancement implementations, which are adjusted separately and should not be assumed to be covered by the SPAU list.

Carrying adjustments to later systems

Adjustments are recorded in transports, and later systems in the landscape can reuse them so the same decisions are not made three times.

This only works if the adjustment is done properly in the first system and the transport is included when the next system is upgraded. Verify the mechanism for your upgrade tool and release before relying on it, because the handling differs between upgrade paths.

• Do the adjustment thoroughly in the first system in the route, because the quality of that work sets the quality in every later system.
• Keep the adjustment transports and include them when upgrading the next system, so only genuinely new conflicts require attention.
• Do not treat a later system's shorter work list as evidence that the adjustment was easy. It is evidence that the first system's work was reused.
• Test the adjusted objects like any other change. An adjustment is a code change made under time pressure, which is a description of a defect risk.
• Record the final decision list. It is the most accurate custom code inventory the program will produce, and it is the input to the clean core discussion afterwards.

What the workflow must cover

• Modification inventory. Know which SAP objects are modified, with or without the Modification Assistant, before the upgrade rather than when the work list appears.
• Reset candidacy. Identify modifications the new release already satisfies, so the list shrinks by decision rather than by adjustment effort.
• Impact and test selection. Select the tests that intersect the adjusted objects, since an adjustment is a code change and inherits the same testing obligation.
• Decision record. Keep the per-object keep or reset decision with its reason as the input to the next upgrade and to the clean core plan.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Inventory modified dictionary and repository objects before the upgrade.
2. Identify reset candidates the new release already satisfies.
3. Staff the SPDD window with the owner present, since the upgrade waits.
4. Work the SPAU list by category, resetting wherever there is no live requirement.
5. Record decisions, keep the adjustment transports, and test the adjusted objects.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Modification inventory pre-upgrade
• SPDD decisions with reasons
• SPAU work list by category
• SPAU_ENH adjustments
• Reset candidates identified
• Adjustment transports
• Tests selected for adjusted objects
• Final decision list

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Adjustment effort cannot be estimated accurately from object counts. Objects modified without the Modification Assistant dominate the effort and are not proportional to the count.
• The mechanism for reusing adjustment transports differs by upgrade path and release. Verify it before relying on it.
• A reset removes the modification and whatever it was doing. The business reason has to be checked, not assumed to be obsolete.

Buyer checklist

• Which SAP objects are modified, and how many without the Modification Assistant?
• Which modifications does the target release already satisfy?
• Is the ABAP owner available in the SPDD window?
• Are adjusted objects included in the test scope?
• Are the adjustment transports being reused in later systems?