SAP Cloud ALM Migration from Solution Manager — Step-by-Step Transition Guide - Blog about SAP Technical Issues, Solution and Learnings

SAP Solution Manager 7.2 mainstream maintenance ends December 31, 2027. That’s 18 months away. But here’s the thing — migrating from Solution Manager to SAP Cloud ALM isn’t something you want to leave until the last quarter before the deadline. A well-planned transition takes 6–12 months, and the organizations that start early get a smoother experience, better data quality, and a more modern operations platform from day one.

This SAP Cloud ALM migration guide walks you through every step — from running the Readiness Check to performing the Selective Data Transfer and going live. I’ve based this on the official SAP transition methodology, SAP Community experiences, and the SAP Activate roadmap for Cloud ALM transition.

Table of Contents

📅 The Timeline — Why Now?

Milestone	Date	What It Means for Your SolMan
Mainstream maintenance ends	Dec 31, 2027	No more standard patches, legal updates, or support from SAP
Extended maintenance	2028–2030	Available at premium cost, but limited scope
After 2030	Customer-specific maintenance	Support tickets only — no patches or new features

If you start your SAP Cloud ALM migration today, you have 18 months to plan, execute, and stabilize — with no rush, no premium fees, and full SAP support throughout.

🔴 Phase 1: Discover & Assess (Weeks 1–4)

Step 1 — Run the SAP Readiness Check for Cloud ALM

This is your starting point. The Readiness Check analyzes your current Solution Manager 7.2 system and provides a detailed report showing:

Which of your current Solution Manager capabilities have equivalent functionality in Cloud ALM
Which data can be directly migrated via Selective Data Transfer (SDT)
Which features have no direct equivalent (e.g., ChaRM customizations, deep ITSM workflows)
A gap analysis with recommended action plans

Access it via SAP Readiness Check 2.0 (transaction SRC_CHECK in SolMan). Reference SAP Note 3236443 for detailed instructions.

Step 2 — Inventory Your Solution Manager Content

Document what you’re currently using SolMan for:

Solution Documentation (process hierarchies, libraries, diagrams)
Test cases and test plans
Change Request Management (ChaRM) workflows
IT Service Management (ITSM) processes
Technical monitoring configurations (MAI, alerts, dashboards)
Custom code management
Business Process Monitoring

Step 3 — Build the Business Case

Moving to Cloud ALM isn’t just about the deadline. It’s about gaining: cloud-native architecture (no server maintenance), faster onboarding (hours vs. weeks), automatic updates (SAP manages upgrades), simplified operations (telemetry-based monitoring), and integration with SAP Activate methodology. Quantify these benefits for your stakeholders.

🟡 Phase 2: Prepare & Plan (Weeks 4–8)

Step 4 — Request Your SAP Cloud ALM Tenant

Your Cloud ALM tenant is provisioned automatically if you have SAP Enterprise Support, Cloud ALM for Implementation, or SAP Cloud ALM for Operations entitlements. If not, request it via the SAP Cloud ALM page on the SAP Support Portal. Provisioning typically takes 1–2 business days.

Step 5 — Set Up Your Cloud ALM Tenant

Configure user roles and access control (Admin, Power User, User)
Set up system connections (your S/4HANA, BTP, and other managed systems)
Define project structure (if using for implementation)
Integrate with your identity provider (IAS or corporate IdP via SAML 2.0)

Step 6 — Define the Transition Approach

SAP recommends a phased approach, not a big-bang cutover. The typical sequence:

First: Move operations monitoring to Cloud ALM (quick wins — health monitoring, alerting, integration monitoring)
Second: Adopt Cloud ALM for new implementation projects (start fresh in Cloud ALM, finish existing projects in SolMan)
Third: Migrate existing Solution Documentation and test assets via Selective Data Transfer
Fourth: Optionally add SAP Focused Run for advanced operations needs

🟡 Phase 3: Explore & Design (Weeks 8–16)

Step 7 — Fit-to-Standard Workshops

Cloud ALM is less customizable than Solution Manager. That’s by design — it’s a standardized cloud-native platform. Run Fit-to-Standard workshops with your operations and implementation teams to:

Map your current SolMan processes to Cloud ALM capabilities
Identify gaps where Cloud ALM doesn’t meet your requirements
Decide on workarounds (e.g., third-party ITSM tools for service desk, APIs for custom workflows)
Define data mapping and transformation rules for SDT

Step 8 — Plan Your Selective Data Transfer

The Selective Data Transfer (SDT) tool moves specific content from SolMan to Cloud ALM. What can be transferred:

Can Be Migrated (SDT)	Cannot Be Migrated
Process hierarchies & libraries	Operations monitoring data (alerts, metrics, history)
Business processes and diagrams	Change Request Management (ChaRM) workflows
Test cases and test steps	ITSM tickets and service desk configurations
Documents (metadata linked to processes)	Custom code management data
Focused Build process steps	Most operational configuration (MAI, background jobs)

🟢 Phase 4: Realize — Execute Migration (Weeks 16–28)

Step 9 — Data Cleansing & Transformation

Before transferring, clean up your Solution Manager data:

Remove obsolete processes and outdated documentation
Standardize naming conventions
Close completed ChaRM change cycles in SolMan (they won’t come to Cloud ALM)
Archive historical data you no longer need

This is the step most teams underestimate. Allocate 3–4 weeks for data preparation.

Step 10 — Selective Data Transfer (SDT) Execution

The SDT process follows these sub-steps:

Export: In Solution Manager, use the Selective Data Transfer tool to export your scoped content (processes, libraries, test cases, documents)
Transform: The tool restructures the data for Cloud ALM compatibility. You can make adjustments (create tags, define system groups, assign owners) during this step
Simulate: Run a simulation import to catch errors before the real import
Import: Upload the transformed data to your production Cloud ALM tenant
Validate: Verify completeness and correctness — check process hierarchies, test cases, documents, and relationships

SAP has published an End-to-End Guide for Selective Data Transfer with detailed instructions for each step.

Step 11 — Configure Cloud ALM Operations

Set up your new operational monitoring in Cloud ALM:

Health Monitoring: Connect your systems via Data Push Providers. Cloud ALM uses lightweight telemetry agents — no more heavy MAI setup
Integration & Exception Monitoring: Configure for SAP CPI, BTP, and PI/PO landscapes
Job Monitoring: Set up for SAP S/4HANA background jobs
Business Process Monitoring: Define KPIs and thresholds
Alerting: Configure subscriptions and API-based notifications (can integrate with ServiceNow, Teams, email)

🟢 Phase 5: Deploy & Go-Live (Weeks 28–36)

Step 12 — Cutover & Hypercare

Freeze changes in Solution Manager during cutover
Finalize data import and run end-to-end validation
Set Solution Manager to read-only for historical reference
Go live with Cloud ALM for operations and implementation
Hypercare period (2–4 weeks): monitor alerts, fix data quality issues, train remaining users

Step 13 — Decommission Planning

Solution Manager can remain available as a read-only reference for 3–6 months after go-live. Plan its eventual decommissioning based on:

Legal retention requirements for historical data
Audit requirements (export relevant logs before shutdown)
Integration dependencies (RFCs pointing to SolMan)

🔵 What Cloud ALM Does NOT Replace from SolMan

Be transparent with your stakeholders about these gaps. Cloud ALM is not a 1:1 replacement for Solution Manager:

Change Request Management (ChaRM) — Not available in Cloud ALM. Replace with Deployment Management + external workflow tools (ServiceNow, SAP Build Process Automation)
ITSM / Service Desk — Cloud ALM has no built-in ITSM. You’ll need ServiceNow, Jira Service Management, or another integration
Deep Custom Code Management — Not in Cloud ALM. Use SAP Custom Code Migration Analyzer or partner tools
Data Volume Management (DVM) — Not planned for Cloud ALM
Complex ChaRM workflows with quality gates — Basis Technologies, Revelation Software Concepts, or REALTECH can fill this gap

✅ Transition Checklist

[ ] Run SAP Readiness Check for Cloud ALM
[ ] Inventory all Solution Manager content and capabilities
[ ] Request and set up Cloud ALM tenant
[ ] Define phased transition approach
[ ] Conduct Fit-to-Standard workshops
[ ] Clean up Solution Manager data (obsolete processes, closed cycles)
[ ] Execute Selective Data Transfer (export → transform → simulate → import → validate)
[ ] Configure Cloud ALM operations monitoring (health, integration, jobs, BPM)
[ ] Train operations and implementation teams
[ ] Cutover: set SolMan read-only, go live with Cloud ALM
[ ] Hypercare and decommission planning

Conclusion

Transitioning from Solution Manager to SAP Cloud ALM is a strategic program, not a weekend project. The 2027 deadline gives you a clear timeline, but the real motivation should be the operational benefits: zero-maintenance infrastructure, automatic updates, telemetry-based monitoring, and a modern user experience that your team will actually want to use.

Start with the Readiness Check this month. Set up your Cloud ALM tenant. Begin using it for operations monitoring — you’ll see the value immediately, and it builds momentum for the full transition. The teams that take this phased approach report smoother migrations, better user adoption, and significantly less stress than those attempting a big-bang replacement.

Need more detail on any step? Drop a comment below. And if you’re preparing your team for the S/4HANA era, the SAP Cloud ALM overview and Cloud ALM vs Solution Manager comparison are good companion reads.