Welcome back to the architectural drawing board! In the last post, we examined the Zero Downtime Option (ZDO). Today, we look at the architectural puzzle piece that makes extremely short downtimes during S/4HANA upgrades possible in the first place: The Silent Data Migration Infrastructure (SDMI) Framework.
Many Basis administrators are surprised when the SUM process is finished, the system goes back online, but suddenly massive database activities take place in the background. What exactly is SDMI, how does it change system operations after the upgrade, and why is the technical user SDM_USER our new best friend?
The Problem with Classic Data Conversion
In old SAP ERP releases, data conversion traditionally happened during the execution phase of the upgrade – i.e., during the hard system downtime (Transaction SPDD / PARCONV). When billions of data records had to be written into new S/4HANA target tables (e.g., during the CVI conversion or in the Finance area), the downtime sometimes lasted several days.
SAP realized that this design was no longer sustainable for S/4HANA. The solution: We decouple the code upgrade from the data upgrade.
Deep Dive: How SDMI Works
SDMI shifts the physical data conversion from downtime to regular uptime, after the SUM is already finished.
How the architecture works:
-
Downtime Phase: The SUM creates the new target structures (tables/fields) in the DDIC, but it does not populate them. The system goes online.
-
Uptime Masking: The SAP application uses so-called "Compatibility Views". When an end user accesses an old data record that has not yet been migrated, the view calculates the new values on-the-fly.
-
Background Migration (SDMI): In the background, the framework's job daemon starts. The designated technical user
SDM_USERbegins to rewrite the billions of data records in small, controlled batches from the old structures into the new structures.
Resource Management and Basis Monitoring
Such a concept naturally carries risks: What happens if SDMI blocks all dialog work processes and destroys the performance of the productive ERP system?
This is where the SDMI architecture shines: The background jobs are configured to be highly resource-efficient (throttling). They use dedicated batch work processes and automatically throttle themselves when the system is under high CPU or memory load.
As Basis administrators, we must oversee this process via the central dashboard Transaction SDM_MON (Silent Data Migration Monitor). Here we see the migration classes, the progress of cross-client and client-dependent tables, as well as any errors involving inconsistent data records that require manual cleanup.
📢 SAP BASIS NEWS TICKER (As of: November 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 SDMI & ZDO Mandatory: SAP is tightening the rules. A new S/4HANA Feature Pack can only be installed via SUM (especially via ZDO) if all SDMI classes of the previous release have been 100% successfully completed. Transaction
SDM_MONmust be "green," otherwise the SUM stops in the PREP phase!
Conclusion for Basis Architects
Silent Data Migration (SDMI) is an architectural masterpiece for streamlining upgrades. It cleverly shifts the "heavy lifting" of the database layer into uptime, during periods of low system load (e.g., on the weekend following the upgrade). For us Basis administrators, this means: An upgrade is not finished on Monday morning when users log back in. Monitoring the SDM_USER and overseeing batch resources in the post-upgrade phase are becoming the new core competencies in the cloud ERP era.