The 2027 operational SolMan gap: what will replace monitoring, Focused Run, and LaMa after maintenance ends

1. What the operational side of SAP Solution Manager entails

In the discussion surrounding the end of maintenance for SAP Solution Manager, almost everything revolves around Change Request Management. This is understandable, as ChaRM is the most visible SolMan function for many organizations. However, it obscures a second, at least equally critical area: operations. SolMan was never just a change tool; it was the central operational platform for SAP Basis.

The operational side of Solution Manager includes a range of functions that have nothing to do with changes and transports, but rather secure the ongoing operation of the SAP landscape.

1. Technical Monitoring. Monitoring of system availability, performance, interfaces, and background processing, including alerting for operations teams.

2. EarlyWatch Alert. The regular health report for each system, which makes risks in performance, stability, and security visible early on. For many Basis teams, this is the single most important operational artifact.

3. Business Process Monitoring and end-user perspective. Monitoring of business-critical process chains and the end-user experience, for example via the former End-User Experience Monitoring.

4. Landscape Automation. System copy, system refresh, mass operations, and central start-stop control, traditionally handled via the closely integrated SAP Landscape Manager, or LaMa for short.

5. Landscape directory and master data. The System Landscape Directory as a directory of technical systems and components, serving as the foundation for monitoring and maintenance planning.

6. IT Service Management. Incident, problem, and service requests, often closely linked to change processes.

These functions are not just add-ons. They are the foundation upon which daily SAP operations run. It is precisely this foundation that is affected by the end of maintenance, with its own deadlines and its own succession questions that cannot be resolved by the change management discussion.

2. Why the 2027 end of maintenance primarily affects Basis teams

1. The date is the same, but the impact is different. Mainstream maintenance for SAP Solution Manager 7.2 ends on December 31, 2027. While change teams discuss ChaRM successors, Basis teams are faced with the question of what they will even use to monitor, automate, and operate their systems from 2028 onwards. The operational side has received too little attention in this debate so far.

2. The successor is aimed at a different type of operation. SAP positions Cloud ALM as a strategic platform, but primarily for cloud-centric and mid-sized landscapes. For highly complex, on-premise-dominated environments with high monitoring volumes, SAP points to Focused Run as a complementary tool. Cloud ALM and Focused Run do not replace each other; they complement one another. Anyone who fails to distinguish between them is planning incorrectly.

3. Market reality exacerbates the problem. The DSAG Investment Report 2026 documents that 56 percent of companies operate S/4HANA on-premise, and 54 percent still have ECC or the Business Suite in their landscape. Around 78 percent run hybrid or on-premise-heavy setups. This is precisely the clientele for whom a purely cloud-native operational approach is least suitable and who are most dependent on the operational functions of SolMan.

4. Multiple deadlines are running in parallel. The operational side depends on several products, each with its own end-of-maintenance dates, not just the Solution Manager itself. Anyone looking only at the SolMan date will overlook the fact that landscape management and the System Landscape Directory also have their own end dates. The inventory must capture these deadlines individually.

3. What replaces individual operational functions after 2027

Replacing the operational side is not a single transition, but a series of function-related decisions. For every SolMan operational function, there is a different succession path, and not every path is SAP-native.

1. Technical monitoring. For medium and smaller landscapes, Cloud ALM handles technical monitoring via its Operations area. For large, high-volume, or heavily on-premise-oriented landscapes, Focused Run is the path intended by SAP. Focused Run will remain in mainstream maintenance beyond 2027 and has its own maintenance terms, independent of SolMan. Important: Focused Run is a separate, licensed product, not an add-on.

2. EarlyWatch Alert. The EWA report is not disappearing, but its transport route is changing. Instead of going through SolMan, managed systems can send data directly to the SAP backbone via the SDCCN component—without any SolMan installation—or obtain the EWA function via Cloud ALM. The inventory must clarify which path each system will use to deliver its health data in the future.

3. End-user and process monitoring. Former End-User Experience Monitoring is being replaced in Cloud ALM by Synthetic User Monitoring. Business Process Monitoring is available in Cloud ALM and is considered one of the more mature operations modules. Here, the succession path is relatively clear.

4. Data Volume Management. Data Volume Management, as integrated into SolMan, is not planned for Cloud ALM. Instead, SAP provides this function as a standalone DVM app in SAP for Me. Anyone actively using DVM today must consciously plan for this break in their tool landscape.

5. Landscape automation. This is where the biggest gap lies. Mainstream maintenance for SAP Landscape Management 3.0 also ends on December 31, 2027, as documented in SAP Note 3375877, and SAP is not planning any extended maintenance. The intended successor, SAP Landscape Management Cloud, has been discontinued. Consequently, there is no SAP-native successor for system copy, system refresh, and centralized start-stop automation in on-premise operations. Third-party providers like Avantra are filling this gap.

6. System Landscape Directory. As part of SAP NetWeaver AS Java, the SLD is also approaching its end of maintenance, as documented in the SAP Knowledge Base regarding the end of maintenance after 2027. The directory and master data function must be relocated in the target architecture, for example, via the landscape data in Cloud ALM or Focused Run.

7. IT Service Management. Cloud ALM does not replicate the full-featured Service Desk capabilities of SolMan to the same extent. The established approach is to integrate a dedicated ITSM platform, such as ServiceNow or Jira Service Management, using Cloud ALM or an orchestration layer for change management connectivity.

4. Where replacing operations becomes a trap

1. Landscape automation has no SAP-native successor. Unlike monitoring, where Focused Run serves as a fallback solution, there is no extended maintenance planned for landscape automation, and the cloud successor has been discontinued. Organizations currently using LaMa for system copies and mass operations will lose this functionality entirely unless they actively establish a third-party alternative. This hits large, hybrid landscapes—which rely most heavily on automation—the hardest.

2. Cloud ALM does not provide a full-stack view of hybrid landscapes. Cloud ALM is SAP-centric. End-to-end observability across SAP, infrastructure, middleware, and non-SAP components is not within its scope. Organizations with heterogeneous landscapes require an additional observability layer to avoid blind spots in their operations.

3. Focused Run is powerful, but not without prerequisites. Focused Run covers high-volume monitoring, but it is a separate product with its own licensing, operational requirements, and significant setup effort. It is not a feature you simply switch on. For smaller organizations, the effort may outweigh the benefits, making the choice between Cloud ALM and Focused Run a strategic planning decision in itself.

4. Parallel deadlines create hidden time pressure. Because Solution Manager, Landscape Management, and the System Landscape Directory have different but closely aligned end-of-life dates, a cluster of simultaneous migrations is created. Those who only plan for the prominent SolMan date risk overlooking the quieter deadlines, ultimately forcing them to replace multiple operational functions under pressure at the same time.

5. Operations falls between the cracks of responsibilities. The change management discussion has a clear owner, but the operational side often does not. Monitoring, automation, and landscape data are spread across Basis, infrastructure, and operations teams. Without a designated lead for the operational SolMan replacement, this task remains neglected until it becomes critical.

6. Compliance also depends on operations. Regulations such as NIS2 and DORA require verifiable, auditable operational processes, not just change documentation. A gap in monitoring or landscape automation is therefore not just a technical issue, but a regulatory risk, as it prevents the provision of seamless operational proof.

5. A procedural model for operational replacement

The operational replacement of SolMan can be structured as a separate sub-project alongside the change migration. The following steps keep the operational side manageable.

1. Create an inventory of operational functions. Document which operational functions are actually in use: monitoring scenarios, EWA, business process monitoring, DVM, landscape automation, SLD, and ITSM. Determine the usage level and criticality for each function. This inventory is the foundation for every subsequent decision.

2. Use the official readiness check. SAP provides a process via the Readiness Check and data collection in Solution Manager that generates a usage overview, showing what can be migrated, what requires manual adjustment, and what falls outside the scope of migration. Operations data generally falls outside the scope of automation, making the inventory process all the more important.

3. Define the target path for each function. Determine the successor for each operational function: Cloud ALM for medium-scale monitoring and business process monitoring, Focused Run for high-volume and heavily on-premise-focused monitoring, third-party providers for landscape automation and full-stack observability, and a dedicated ITSM platform for the service desk.

4. Make a conscious decision between Cloud ALM and Focused Run. The choice depends on size, volume, and landscape type, not on a cloud preference. Small to medium-sized landscapes often get by with Cloud ALM, while large hybrid landscapes require Focused Run. A two-tool strategy is legitimate and often the most realistic answer.

5. Schedule the silent deadlines separately. Landscape Management and the System Landscape Directory should be given their own milestone, independent of the change migration, so they do not get lost in the shadow of ChaRM.

6. Designate operational responsibility. Establish clear accountability for the operational transition that brings together basis, infrastructure, and operations. Without a named owner, the operational side remains uncoordinated.

6. Tool Landscape

The following table classifies which tool category covers which operational SolMan function after 2027. It shows that there is no single one-to-one successor, but rather a distribution across Cloud ALM, Focused Run, dedicated operational tools, and ITSM platforms. The change and transport row is included for contrast, as it shows where an orchestration layer has its place and where it does not.

¹ Solutive AG is the initiator of the Change Orchestration Institute. The assessment in the table is a self-disclosure by the provider and is not part of an editorially independent validation. The orchestration layer addresses change, release, and transport, not technical operations such as monitoring or landscape automation. These areas are deliberately outside its functional scope and are covered by Focused Run and dedicated operational tools.

The table makes the division of labor visible. The orchestration layer is strong in change, release, and transport, but deliberately not in technical operations. Monitoring, EarlyWatch Alert, landscape automation, and the System Landscape Directory fall outside its functional scope and are covered by Focused Run and dedicated operational tools. A complete replacement of the operational SolMan side therefore combines several tool classes rather than expecting a single product to serve as a total replacement.

7. Operational consequences for SAP organizations

From an operational perspective, there are concrete steps that apply independently of the change migration.

The first consequence concerns visibility. The operational SolMan replacement belongs as a separate strand in the 2027 planning, not as an appendix to the ChaRM discussion. Those who do not plan operations separately will only discover the gaps once they impact ongoing operations.

The second consequence concerns landscape automation. Because there is no SAP-native successor here, this is the most urgent individual point. Organizations that use LaMa productively for system copies and mass operations should evaluate the third-party path early, as building an alternative requires lead time.

The third consequence concerns the tool strategy. Cloud ALM and Focused Run are not an either-or decision, but a question of landscape type. A conscious two-tool strategy is often the realistic answer, and it must be budgeted for, as Focused Run requires a license.

The fourth consequence concerns compliance. Proof of operations is part of the regulatory requirements from NIS2 and DORA. Seamless operational governance across all systems is therefore not just a technical task, but also a documentation requirement that belongs in the target architecture.