Basisintermediate
SAP Support Packages, Kernel Upgrades & SPAU/SPDD
Applying software maintenance (support packages, kernel patches) and resolving modification conflicts during upgrades.
Software maintenance is unglamorous but constantly tested in Basis interviews because it's where theory meets the messy reality of a live system that has years of custom modifications layered on top of SAP standard code, and a candidate's answer here reveals whether they've actually lived through an upgrade cycle.
Applying a support package is like your phone getting an OS update - if you never modified the phone's system files it installs cleanly, but if you rooted it and hand-edited system files yourself, the update installer stops and asks you, file by file, whether to keep your hack or take Apple's new version.
Key Concepts
1
Support packages (SPs, delivered per software component - e.g., SAP_BASIS, SAP_APPL - and applied via the transaction SPAM, Support Package Manager) bundle corrections and legal/regulatory changes released periodically by SAP; the kernel (the C/C++ executable layer beneath ABAP, patched independently of support packages via a kernel patch/upgrade) handles lower-level runtime, database connectivity, and OS interaction and is generally more frequent and lower-risk to apply than a full support package stack. SNOTE applies individual SAP Notes - point corrections for specific bugs - often as an interim fix before the relevant support package is applied, and is one of the most common first-response tools when a known SAP bug is hit.
SAP_BASISSAP_APPLSPAMSNOTE
2
The genuinely tricky part, and the classic interview discriminator, is modification adjustment: if a customer has directly modified an SAP standard object (discouraged, but it happens, especially in older ECC systems), applying a support package or upgrade that also changes that same object creates a conflict that must be resolved manually. SPDD handles DDIC object modification conflicts (must be processed before the technical downtime phase of an upgrade, since ABAP Dictionary structures need to be consistent before the database can even be adjusted) and SPAU handles all other repository object conflicts (programs, function modules, screens), typically processed after the technical upgrade completes. Both essentially ask the developer, per conflicting object, whether to keep the customer's modification, reset to SAP standard, or manually merge the change (SAP's newer default is usually preferred when it doesn't affect the specific behavior the modification exists for).
SPDDSPAU
3
A senior answer stresses that the real preventive fix is minimizing core modifications in the first place (using proper enhancement techniques like BAdIs instead) precisely because SPAU/SPDD effort scales directly with how much SAP standard code has been touched, and that these transactions are also central to a large release upgrade project's technical cutover timeline, often on the critical path for total downtime.