SAP RISE: Shared responsibility with proactive maintenance

SAP plans to introduce proactive maintenance running a push update service for selected technology components. The supported components will be announced separately and SAP plans to increase the scope over time.

• Proactive maintenance will touch only the blue colored figures which represents the technology components
• Proactive maintenance will be scheduled during a pre-announced maintenance window (customer-specific CMP - contractual maintenance period, or SAP-defined maintenance window)
• Proactive maintenance will happen only on SAP systems which passed an upfront automated “Maintenance Readiness Check“ (=MRC)
• Customers and IT partners will be notified upfront via automated e-mail notifications
• The overall responsibility for patching remains with the customer, specifically for components where SAP provides no pro-active patching

"We understand performing an upgrade/update on the technology components will first be uncritical to your business application, and second, will not lead to request you as a customer to perform any validation after an SAP initiated change"

- Thorsten Hepting SAP ECS -

 If we take this quote serious SAP says if we change only some technology components it will not harm any business application. My 20+ years of tech experience has shown me more than once that changing the operating system, SAP kernel, database or even SAP host agent can affect system stability and business process performance (shout out to SAP HEX engine). The behavior of QAS to PRD can differ significantly due to different infrastructure (number of application servers, sizing, parameter set etc.), data volumes and workloads. The first customer with a special workload who encounters a known issue in the HANA optimizer will gratefully refer to this quote. May be the quote was only in the context of tasks like SPAM/SAINT or ST-PI / ST-A/PI.

Maintenance process

SAP will send out mails to the planned downtime contacts maintained in the SAP for me portal. the changed will be executed in the SAP defined maintenance windows. Those are dates and times defined already in the SAP Cloud Services and which are region specific, having an individual defined date and time for MENA, APJ, Europe and America. On the long side SAP will perform the changes inside the contractual maintenance period (=CMP).

Customers have also an opt-out option to skip a campaign of proactive maintenance due to business specific reasons.

Additionally the affected systems have to pass an upfront automated Maintenance Readiness Check (=MRC). Only if these checks are all green, the deployment will be started. After the maintenance has been successfully finished another mail will be send out. In the end you will find in the SAP for me portal an overview of all the changes pushed by SAP within a new section and that will come in Q1 2025.

All technology components which may affect customer business processes are out of scope for Proactive Maintenance and will stay in full customer control and responsibility. Specifically, this includes Feature Package Stack (FPS) / Support Package Stack (SPS) Updates and Release Upgrades. SAP will continue to support these with on-demand technical execution and consulting based on Customer Service Requests.

=> May be this list should be more transparent which components are meant. S/4HANA FPS and SPS are crystal clear, but what else? The mentioned help.sap.com scope is not accessible for all customers.

CMP - contractual maintenance period

In future SAP will deploy changes in a customer defined CMP windows per system. This time windows will be used by SAP exclusively. This is a formal agreement between SAP and the customer as stipulated in the contract.

Prior to any maintenance, SAP will inform (usually at least 7 business days - source: RISE with SAP S/4HANA Cloud, private edition Supplement enGLOBAL.v.10-2024 ) the customer regarding the planned activities. The customer can request to reschedule the activities but this must be done within 5 days of the notification and must be rescheduled. The activities cannot be rejected permanently.

SAP-defined maintenance windows

For proactive maintenance events where CMPs cannot be used, as a fallback solution, SAP will define maintenance windows. This is possible mainly because this events will all be done as online changes and happening in system uptime.

MRC - Maintenance Readiness Check

MRC is a framework used by SAP to check if systems are ready to receive pro-active software changes. This framework is a new SAP development based on TCI and contains only ABAP repository objects. It's required to collect system data to better prepare upgrade/update procedures. The MRC will be used by ECS only. The MRC repository objects depend only on the underlying SAP NetWeaver functionality and have no dependencies to other components. MRC collects only relevant system informations (Installed Software Components, Database, Used Kernel, Application Servers, ...). MRC does not change anything in the system and uses only its own database tables to store the result of the MRC run.

The framework includes checks on the overall technical situation of the system and on specific qualities of planned software changes. Depending on the results of the checks, MRC categorizes each system as either Red or Green. Only for Green systems (meaning all checks) SAP will perform pro-active changes.

SAP Notes MRC:

• 3213339 - Maintenance Readiness Checks (MRC) - Central SAP Note
• 3386693 - Maintenance Readiness Checks - Content Delivery: Version 4 (Q1/2024)
• 3319026 - Delivery of Maintenance Readiness Checks (MRC)

My questions to this procedure:

• If a customer always have QCM tables displayed in SE14 no maintenance can be performed means they don't have to opt-out just let one check not pass, right? This sounds like a permanently rejection option. What if customers are not fixing such red system tasks?
• how and who will get an info for red systems?
• For project or business frozen zones - how often such a maintenance can be skipped without getting a risk letter and take the full responsibility?
• Is there a fallback for every maintenance task?
• What happens if the maintenance window is exceeded? Fallback or early notification for increasing the downtime?

You have also questions to this new pro-active maintenance procedure by SAP?

Feel free to comment or contact me.