ABAP Cloud Migration Guide: Von Classic zu Cloud in 5 Schritten (2025)

kategorie

Migration

Veröffentlicht

Nov 29, 2025

autor

Die Migration von Classic ABAP zu ABAP Cloud ist eine der größten Herausforderungen für SAP-Entwickler in 2025. Dieser Guide zeigt dir einen praktischen 5-Schritte-Plan, mit dem du deine Custom Code Basis systematisch in die Cloud migrierst.

📋 Was dich erwartet

5-Schritte-Migrations-Roadmap mit klarem Ablauf
Tool-Übersicht (ATC, Custom Code Migration, ABAP Test Cockpit)
Checklisten für jede Phase
Realistische Zeitplanung
Häufige Probleme und Lösungen
Best Practices aus echten Projekten

Geschätzte Lesezeit: 15 Minuten | Umsetzungszeit: 3-12 Monate (je nach Codebasis)

🎯 Warum überhaupt migrieren?

Clean Core Strategie

SAP verfolgt die Clean Core Strategie: Nur Released APIs nutzen, keine Modifikationen am SAP-Standard, cloud-ready entwickeln.

Vorteile:

✅ Upgrade-Stabilität: Updates ohne Code-Brüche
✅ Cloud-Ready: Code läuft auf BTP und S/4HANA Cloud
✅ Zukunftssicher: Neue Features nur in ABAP Cloud
✅ Performance: Optimierte Runtime
✅ Wartbarkeit: Saubere, standardisierte APIs

Nachteile bei Nicht-Migration:

❌ Technische Schulden häufen sich
❌ Upgrades werden immer schwieriger
❌ Keine Cloud-Optionen (BTP ABAP Environment)
❌ Rekrutierung schwierig (moderne Entwickler wollen Cloud)

🗺️ Die 5 Migrations-Phasen im Überblick

Phase	Dauer	Aufwand	Kritisch?
1. Analyse	2-4 Wochen	Gering	⭐⭐⭐ Sehr wichtig
2. Planung	1-2 Wochen	Mittel	⭐⭐⭐ Sehr wichtig
3. Adaption	4-20 Wochen	Hoch	⭐⭐ Wichtig
4. Testing	2-6 Wochen	Mittel	⭐⭐⭐ Sehr wichtig
5. Go-Live	1 Woche	Gering	⭐⭐ Wichtig

Gesamtdauer: 3-12 Monate (abhängig von Codebasis-Größe)

Phase 1: Analyse der Code-Basis

Ziel

Verstehen, wie viel Code migriert werden muss und welche Probleme auftreten werden.

1.1 Custom Code Migration App ausführen

Die Custom Code Migration App (Fiori App in S/4HANA) analysiert deinen Code automatisch.

Zugriff:

Transaktion: /n/SDF/CD_CCA (Classic UI)
Fiori Launchpad: Tile “Custom Code Migration”

Durchführung:

App starten
Scope auswählen: Alle Z*/Y* Objekte oder selektiv
ATC Check Variant wählen: ABAP_CLOUD_READINESS
Analyse starten (kann 30 Min - 2 Std dauern)
Ergebnisse auswerten

Output:

Anzahl betroffener Objekte
Severity (Error, Warning, Info)
Top-Probleme nach Häufigkeit
Geschätzter Aufwand

1.2 ABAP Test Cockpit (ATC) manuell nutzen

Für einzelne Pakete/Objekte:

In SAP GUI:

Transaktion: ATC
1. Rechtsklick auf Paket → Run → ATC Check
2. Check Variant: ABAP_CLOUD_READINESS
3. Ergebnisse analysieren

In ABAP Development Tools (Eclipse):

1. Rechtsklick auf Package/Class → Run As → ABAP Test Cockpit
2. Check Variant: ABAP_CLOUD_READINESS
3. Findings analysieren

1.3 Analyse-Ergebnisse kategorisieren

Typische Findings:

Kategorie	Beispiele	Aufwand
Syntax-Änderungen	`FORM`/`PERFORM`, `SELECT *`	⭐ Niedrig
Nicht-Released APIs	Direct DB access zu SAP-Tabellen	⭐⭐⭐ Hoch
Dynpro → Fiori	CALL SCREEN, MODULE	⭐⭐⭐ Sehr hoch
Obsolete Statements	`CONCATENATE`, `MOVE`	⭐ Niedrig
Enhancement Framework	User Exits → BAdIs	⭐⭐ Mittel

1.4 Priorisierung

Klassifiziere Objekte nach:

Business Criticality: Wie wichtig für Geschäftsprozesse?
Usage Frequency: Wie oft wird Code ausgeführt?
Migration Effort: Wie aufwändig ist die Anpassung?

Empfohlene Priorisierung:

Hohe Prio: Hohe Business Criticality + Niedrige Effort
Mittlere Prio: Mittlere Criticality + Mittlere Effort
Niedrige Prio: Niedrige Criticality + Hohe Effort
→ Ausmustern: Nicht mehr genutzte Objekte löschen!

✅ Checkliste Phase 1

Custom Code Migration App ausgeführt
ATC Checks auf kritische Pakete gelaufen
Findings kategorisiert (Syntax, APIs, UI, etc.)
Objekte nach Prio klassifiziert
Liste obsoleter Objekte erstellt (zum Löschen)
Stakeholder informiert (Management, PO, etc.)

Ergebnis: Excel/PDF mit allen Findings + Aufwandsschätzung

Phase 2: Migrations-Planung

Ziel

Einen realistischen Plan erstellen mit Ressourcen, Timeline und Risiken.

2.1 Team & Ressourcen

Benötigte Rollen:

ABAP Cloud Developer (2-5 FTE je nach Codebasis)
Functional Consultant (für Business-Logik-Verständnis)
Quality Manager (für Testing)
Project Manager (für Koordination)

Skills-Gap schließen:

ABAP Cloud Training für Team (siehe Roadmap)
RAP & CDS Views Workshops
Externe Berater für komplexe Fälle

2.2 Migrations-Strategie wählen

Option A: Big Bang (alles auf einmal)

✅ Schneller Go-Live
❌ Hohes Risiko
👉 Für kleine Codebasen (<500 Objekte)

Option B: Iterativ (Schritt für Schritt)

✅ Geringes Risiko
✅ Lernen von frühen Fehlern
❌ Längere Gesamtdauer
👉 Für mittlere/große Codebasen (>500 Objekte)

Option C: Hybrid

Kritische Objekte zuerst (Big Bang)
Rest iterativ nachrüsten
👉 Empfohlen für die meisten Projekte

2.3 Timeline erstellen

Beispiel für 1.000 Objekte:

Woche 1-4:   Phase 1 - Analyse ✓
Woche 5-6:   Phase 2 - Planung ✓
Woche 7-14:  Batch 1 - Kritische Objekte (200)
Woche 15-22: Batch 2 - Häufig genutzt (300)
Woche 23-30: Batch 3 - Restliche (500)
Woche 31-36: Testing & Bugfixes
Woche 37:    Go-Live

2.4 Risiko-Management

Typische Risiken:

Risiko	Wahrscheinlichkeit	Impact	Mitigation
Nicht-Released APIs ohne Alternative	Hoch	Hoch	Frühzeitig SAP-Tickets öffnen für API-Release
Dynpro-to-Fiori sehr aufwändig	Mittel	Hoch	Budget-Puffer einplanen
Skill-Gap im Team	Hoch	Mittel	Training vor Projektstart
Hidden Dependencies	Mittel	Mittel	Code-Analyse mit Tools (ABAP Dependency Analyzer)

✅ Checkliste Phase 2

Team zusammengestellt
Migrations-Strategie gewählt (Big Bang/Iterativ/Hybrid)
Timeline in Projekt-Tool (Jira, Azure DevOps) eingetragen
Budget freigegeben
Risiken dokumentiert mit Mitigation-Plan
Stakeholder-Meeting durchgeführt (Kick-off)

Ergebnis: Projekt-Plan mit Timeline, Budget, Ressourcen

Phase 3: Code-Adaption (Die eigentliche Migration)

Ziel

Code ABAP Cloud-konform umschreiben.

3.1 Entwicklungsrichtlinien definieren

ABAP Cloud Coding Guidelines:

1. Nur Released APIs/CDS Views
2. Keine FORM/PERFORM → Methoden
3. Keine SELECT * → Explizite Felder
4. String Templates statt CONCATENATE
5. Table Expressions statt READ TABLE
6. Strict Mode in allen BDEFs
7. Exception Handling bei Table Expressions
8. EML statt BAPI-Calls (wo möglich)
9. Fiori statt Dynpro
10. Unit Tests für kritische Logik

Im Team verteilen & schulen!

3.2 Häufigste Migrations-Patterns

Pattern 1: FORM → Methode

Vorher (Classic):

FORM calculate_total USING pv_amount TYPE p
                     CHANGING pv_total TYPE p.
  pv_total = pv_amount * '1.19'.
ENDFORM.

PERFORM calculate_total USING lv_amount CHANGING lv_total.

Nachher (Cloud):

CLASS lcl_calculator DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS calculate_total
      IMPORTING iv_amount       TYPE p
      RETURNING VALUE(rv_total) TYPE p.
ENDCLASS.

CLASS lcl_calculator IMPLEMENTATION.
  METHOD calculate_total.
    rv_total = iv_amount * '1.19'.
  ENDMETHOD.
ENDCLASS.

DATA(lv_total) = lcl_calculator=>calculate_total( lv_amount ).

Pattern 2: SAP-Tabelle → Released CDS View

Vorher (Classic):

SELECT matnr, maktx FROM mara
  INTO TABLE @DATA(lt_materials)
  WHERE mtart = 'FERT'.

Nachher (Cloud):

SELECT Product, ProductDescription FROM I_Product
  INTO TABLE @DATA(lt_products)
  WHERE ProductType = 'FERT'.

Mapping finden:

SAP API Business Hub durchsuchen
ADT: Ctrl+Shift+A → I_Product suchen
SAP-Tabelle in Where-Used List → CDS Views finden

Pattern 3: BAPI → RAP/EML

Vorher (Classic):

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'
  EXPORTING
    order_header_in = ls_header
  TABLES
    return          = lt_return.

Nachher (Cloud):

MODIFY ENTITIES OF I_SalesOrder
  ENTITY SalesOrder
    CREATE FIELDS ( SoldToParty, SalesOrderType )
    WITH VALUE #( ( %cid = 'ORDER_1'
                    SoldToParty = '0001000000'
                    SalesOrderType = 'OR' ) )
  MAPPED DATA(mapped)
  FAILED DATA(failed)
  REPORTED DATA(reported).

COMMIT ENTITIES.

Pattern 4: Dynpro → Fiori Elements

Aufwand: ⭐⭐⭐ Sehr hoch

Strategie:

Analyse: Welche Felder/Funktionen hat Dynpro?
RAP BO erstellen: Datenmodell als CDS View
Behavior Definition: CRUD + Actions
Service Binding: OData V4
Fiori Elements: Automatisch generiert!
Annotations: UI-Layout steuern

Siehe: SAP Fiori Elements Guide

3.3 Tools für Code-Transformation

Quick Fixes in ADT:

ADT bietet Quick Fixes für viele Findings:

1. Rechtsklick auf ATC Finding
2. "Quick Fix" → ADT schlägt Lösung vor
3. Akzeptieren → Code automatisch angepasst

Beispiel: CONCATENATE → String Template

Massenänderungen mit ABAP Cleaner:

Open-Source Tool: github.com/SAP/abap-cleaner

Auto-Formatting
Obsolete Syntax modernisieren
Als Eclipse-Plugin verfügbar

3.4 Nicht-Released APIs: Was tun?

Problem: Du brauchst eine SAP-Tabelle/FM, die nicht Released ist.

Lösungen:

Released Alternative suchen:
- API Business Hub durchsuchen
- SAP Community fragen
- Ctrl+Shift+A in ADT: Nach ähnlichen CDS Views suchen
SAP-Ticket öffnen:
- Über SAP Support Portal
- Begründen, warum du das Objekt brauchst
- SAP kann API nachträglich releasen (dauert aber!)
Wrapped API erstellen:
- In Classic System: API-Wrapper bauen
- Als Released kennzeichnen (nur bei On-Premise!)
- In Cloud System nutzen
Workaround finden:
- Oft gibt es Umwege über Released APIs
- Community-Foren helfen

Wichtig: Option 3 (Wrapped API) funktioniert NUR bei S/4HANA On-Premise, NICHT in BTP ABAP Environment!

✅ Checkliste Phase 3

Coding Guidelines im Team kommuniziert
Entwickler-Trainings durchgeführt
Batch 1 Objekte migriert
Code Reviews durchgeführt
ATC Checks grün (keine Errors mehr)
Unit Tests geschrieben für kritische Logik
Batch 2, 3, … durchgeführt

Ergebnis: ABAP Cloud-konformer Code, ATC-sauber

Phase 4: Testing

Ziel

Sicherstellen, dass migrierter Code funktional identisch ist.

4.1 Test-Strategie

3-stufiger Test-Ansatz:

Unit Tests (automatisiert)
Integration Tests (manuell/automatisiert)
User Acceptance Tests (manuell durch Fachbereich)

4.2 Unit Tests schreiben

Für jede kritische Methode:

CLASS ltc_calculator_test DEFINITION FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    METHODS test_calculate_total FOR TESTING.
ENDCLASS.

CLASS ltc_calculator_test IMPLEMENTATION.
  METHOD test_calculate_total.
    " Given
    DATA(lv_amount) = 100.

    " When
    DATA(lv_result) = lcl_calculator=>calculate_total( lv_amount ).

    " Then
    cl_abap_unit_assert=>assert_equals(
      act = lv_result
      exp = 119
      msg = 'Total should be 119 (100 * 1.19)'
    ).
  ENDMETHOD.
ENDCLASS.

Run Tests:

ADT: Ctrl+Shift+F10
Ziel: >80% Code Coverage für kritische Klassen

4.3 Regressions-Tests

Vergleich Alt vs. Neu:

Test-Daten in DEV-System vorbereiten
Classic Code ausführen → Output speichern
Cloud Code ausführen → Output speichern
Diff-Vergleich: Outputs müssen identisch sein

Tools:

ABAP Unit für automatisierte Vergleiche
eCATT (Extended Computer Aided Test Tool)
Custom Test-Skripte

4.4 Performance-Tests

Wichtig: Cloud-Code kann langsamer sein (neue APIs, mehr Abstraktionen)

Messen:

DATA(lv_start) = cl_abap_context_info=>get_system_time( ).

" Code ausführen

DATA(lv_end) = cl_abap_context_info=>get_system_time( ).
DATA(lv_duration) = lv_end - lv_start.

Bei Performance-Problemen:

SQL-Traces analysieren (ST05 in Classic, SQL Trace in ADT)
CDS Views optimieren (Indizes, Projektionen)
EML-Operationen batchen

4.5 User Acceptance Testing (UAT)

Durchführung:

Test-Cases mit Fachbereich definieren
Test-System bereitstellen (QAS)
Key Users testen lassen (2-3 Wochen)
Feedback sammeln → Bugs fixen
Sign-Off durch Fachbereich

✅ Checkliste Phase 4

Unit Tests für kritische Logik geschrieben (>80% Coverage)
Regressions-Tests durchgeführt (Alt vs. Neu identisch)
Performance-Tests gelaufen (keine Verschlechterung >20%)
UAT abgeschlossen (Sign-Off von Fachbereich)
Bugs dokumentiert & gefixt
Test-Reports erstellt

Ergebnis: Getesteter, abgenommener Code

Phase 5: Go-Live & Rollout

Ziel

Code in Produktion bringen ohne Ausfälle.

5.1 Go-Live Strategie

Option A: Cutover (Stichtag)

Alle Änderungen auf einmal produktiv
✅ Klarer Schnitt
❌ Hohes Risiko

Option B: Parallel Run

Alter + neuer Code parallel
Feature Toggles für Umschaltung
✅ Geringes Risiko
❌ Doppelter Maintenance-Aufwand

Option C: Canary Deployment

Neuer Code für 10% der User → 50% → 100%
✅ Schrittweise Validierung
👉 Empfohlen!

5.2 Transport-Strategie

Standard-Transport:

DEV → QAS → PRD

Pre-Go-Live Checks:

5.3 Go-Live Checklist

1 Woche vorher:

Go-Live Kommunikation an alle User
Support-Team briefen
Monitoring-Dashboards aufsetzen
Rollback-Prozedur testen

Am Go-Live Tag:

Transports nach PRD importieren (in Wartungsfenster)
Smoke Tests im PRD (kritische Funktionen testen)
Monitoring aktivieren (ST22, SM21, Application Logs)
Support-Hotline bereit

Nach Go-Live:

1 Woche intensive Überwachung
User-Feedback sammeln
Kleine Bugs fixen (Hotfixes)
Post-Go-Live Review (Lessons Learned)

5.4 Rollback-Plan

Wenn etwas schiefgeht:

Symptome erkennen: Shortdumps, falsche Daten, Performance-Probleme
Entscheidung: Hotfix oder Rollback?
Rollback:
- Alte Code-Version aus Git holen
- Transport mit altem Code erstellen
- Nach PRD importieren
Root Cause Analysis: Was ist schiefgelaufen?

✅ Checkliste Phase 5

Go-Live Strategie festgelegt (Cutover/Parallel/Canary)
Transports bereit
Go-Live Kommunikation versendet
Support-Team gebrieft
Rollback-Plan dokumentiert
Monitoring-Setup aktiv
Go-Live erfolgreich durchgeführt
Post-Go-Live Review durchgeführt

Ergebnis: Code produktiv, stabil laufend

🛠️ Tool-Übersicht

Tool	Zweck	Verfügbar in
Custom Code Migration App	Analyse Custom Code	S/4HANA (Fiori)
ABAP Test Cockpit (ATC)	Code-Checks, Findings	SAP GUI, ADT
ABAP Development Tools (ADT)	Entwicklung, Quick Fixes	Eclipse
ABAP Cleaner	Auto-Modernisierung	Eclipse Plugin
SQL Trace	Performance-Analyse	ADT
ST22	Shortdump-Analyse	SAP GUI
ABAP Unit	Unit Testing	ADT, SAP GUI
Git	Versionierung	ADT (abapGit)

📊 Aufwandsschätzung

Faustregel:

Einfache Objekte (nur Syntax): 0.5-1 Std/Objekt
Mittlere Objekte (API-Änderungen): 2-4 Std/Objekt
Komplexe Objekte (Dynpro → Fiori): 10-40 Std/Objekt

Beispiel: 1.000 Objekte

700 einfach × 1 Std = 700 Std
250 mittel × 3 Std = 750 Std
50 komplex × 20 Std = 1.000 Std
Gesamt: 2.450 Std = ~14 Monate (1 Entwickler) oder ~3 Monate (5 Entwickler)

Plus: Analyse, Testing, Projektmanagement (+30%) → ~4 Monate mit 5 Entwicklern

⚠️ Häufige Probleme & Lösungen

Problem 1: “Keine Released Alternative gefunden”

Lösung:

SAP API Business Hub durchsuchen: api.sap.com
SAP Community fragen: community.sap.com
SAP Support-Ticket öffnen → API-Release anfragen
Workaround über andere Released APIs

Problem 2: “Dynpro-Migration zu aufwändig”

Lösung:

Option A: Budget erhöhen (realistisch)
Option B: Dynpro als “Wrapper” behalten, nur Backend in ABAP Cloud
Option C: Low-Code-Tools nutzen (SAP Build Apps)

Problem 3: “Performance-Verschlechterung nach Migration”

Lösung:

CDS Views optimieren (Indizes, Buffering)
EML-Operationen batchen (nicht in Loop)
SQL Trace analysieren → Bottlenecks identifizieren

Problem 4: “Team hat keine ABAP Cloud Skills”

Lösung:

Training: SAP Learning Hub, openSAP, externe Schulungen
Externe Berater für kritische Phase
Pair Programming: Erfahrene + Unerfahrene zusammen

📚 Weiterführende Ressourcen

Auf abapcloud.com:

SAP Ressourcen:

🎯 Zusammenfassung

Die ABAP Cloud Migration ist kein Sprint, sondern ein Marathon. Mit diesem 5-Schritte-Plan hast du eine klare Roadmap:

Analyse: Code-Basis verstehen (ATC, Custom Code Migration App)
Planung: Realistische Timeline, Team, Budget
Adaption: Code umschreiben (FORM→Methoden, APIs→CDS, Dynpro→Fiori)
Testing: Unit Tests, Regressions-Tests, UAT
Go-Live: Transport, Monitoring, Support

Wichtigste Erfolgsfaktoren:

✅ Gründliche Analyse (nicht unterschätzen!)
✅ Realistische Zeitplanung (+30% Puffer)
✅ Team-Skills aufbauen (Training!)
✅ Iterativer Ansatz (nicht Big Bang)
✅ Stakeholder mitnehmen (Kommunikation!)

Viel Erfolg bei deiner Migration! 🚀

Brauchst du Hilfe? Schreib uns in den Kommentaren - wir helfen gerne bei konkreten Migrations-Fragen!