ABAP Cloud Migration Guide: From Classic to Cloud in 5 Steps (2025)

Migrating from Classic ABAP to ABAP Cloud is one of the biggest challenges for SAP developers in 2025. This guide shows you a practical 5-step plan to systematically migrate your custom code base to the cloud.

What to Expect

• 5-step migration roadmap with clear process
• Tool overview (ATC, Custom Code Migration, ABAP Test Cockpit)
• Checklists for each phase
• Realistic timeline
• Common problems and solutions
• Best practices from real projects

Estimated reading time: 15 minutes | Implementation time: 3-12 months (depending on codebase)

Why Migrate at All?

Clean Core Strategy

SAP pursues the Clean Core strategy: Only use Released APIs, no modifications to SAP standard, develop cloud-ready.

Advantages:

• Upgrade stability: Updates without code breaks
• Cloud-ready: Code runs on BTP and S/4HANA Cloud
• Future-proof: New features only in ABAP Cloud
• Performance: Optimized runtime
• Maintainability: Clean, standardized APIs

Disadvantages of not migrating:

• Technical debt accumulates
• Upgrades become increasingly difficult
• No cloud options (BTP ABAP Environment)
• Difficult recruitment (modern developers want cloud)

The 5 Migration Phases Overview

Total duration: 3-12 months (depending on codebase size)

Phase 1: Codebase Analysis

Goal

Understand how much code needs to be migrated and which problems will occur.

1.1 Run Custom Code Migration App

The Custom Code Migration App (Fiori App in S/4HANA) analyzes your code automatically.

Access:

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

Execution:

1. Start app
2. Select scope: All Z*/Y* objects or selective
3. Choose ATC Check Variant: ABAP_CLOUD_READINESS
4. Start analysis (can take 30 min - 2 hrs)
5. Evaluate results

Output:

• Number of affected objects
• Severity (Error, Warning, Info)
• Top problems by frequency
• Estimated effort

1.2 Use ABAP Test Cockpit (ATC) Manually

For individual packages/objects:

In SAP GUI:

Transaction: ATC
1. Right-click on package -> Run -> ATC Check
2. Check Variant: ABAP_CLOUD_READINESS
3. Analyze results

In ABAP Development Tools (Eclipse):

1. Right-click on Package/Class -> Run As -> ABAP Test Cockpit
2. Check Variant: ABAP_CLOUD_READINESS
3. Analyze findings

1.3 Categorize Analysis Results

Typical findings:

1.4 Prioritization

Classify objects by:

1. Business Criticality: How important for business processes?
2. Usage Frequency: How often is code executed?
3. Migration Effort: How complex is the adaptation?

Recommended prioritization:

High priority: High business criticality + Low effort
Medium priority: Medium criticality + Medium effort
Low priority: Low criticality + High effort
-> Retire: Delete unused objects!

Checklist Phase 1

• Custom Code Migration App executed
• ATC Checks run on critical packages
• Findings categorized (Syntax, APIs, UI, etc.)
• Objects classified by priority
• List of obsolete objects created (for deletion)
• Stakeholders informed (Management, PO, etc.)

Result: Excel/PDF with all findings + effort estimate

Phase 2: Migration Planning

Goal

Create a realistic plan with resources, timeline, and risks.

2.1 Team & Resources

Required roles:

• ABAP Cloud Developer (2-5 FTE depending on codebase)
• Functional Consultant (for business logic understanding)
• Quality Manager (for testing)
• Project Manager (for coordination)

Close skills gap:

• ABAP Cloud training for team (see Roadmap)
• RAP & CDS Views workshops
• External consultants for complex cases

2.2 Choose Migration Strategy

Option A: Big Bang (all at once)

• Fast Go-Live
• High risk
• For small codebases (<500 objects)

Option B: Iterative (step by step)

• Low risk
• Learn from early mistakes
• Longer total duration
• For medium/large codebases (>500 objects)

Option C: Hybrid

• Critical objects first (Big Bang)
• Rest iteratively retrofitted
• Recommended for most projects

2.3 Create Timeline

Example for 1,000 objects:

Week 1-4:   Phase 1 - Analysis
Week 5-6:   Phase 2 - Planning
Week 7-14:  Batch 1 - Critical objects (200)
Week 15-22: Batch 2 - Frequently used (300)
Week 23-30: Batch 3 - Remaining (500)
Week 31-36: Testing & Bugfixes
Week 37:    Go-Live

2.4 Risk Management

Typical risks:

Checklist Phase 2

• Team assembled
• Migration strategy chosen (Big Bang/Iterative/Hybrid)
• Timeline entered in project tool (Jira, Azure DevOps)
• Budget approved
• Risks documented with mitigation plan
• Stakeholder meeting conducted (Kick-off)

Result: Project plan with timeline, budget, resources

Phase 3: Code Adaptation (The Actual Migration)

Goal

Rewrite code to be ABAP Cloud-compliant.

3.1 Define Development Guidelines

ABAP Cloud Coding Guidelines:

1. Only Released APIs/CDS Views
2. No FORM/PERFORM -> Methods
3. No SELECT * -> Explicit fields
4. String templates instead of CONCATENATE
5. Table expressions instead of READ TABLE
6. Strict Mode in all BDEFs
7. Exception handling for table expressions
8. EML instead of BAPI calls (where possible)
9. Fiori instead of Dynpro
10. Unit tests for critical logic

Distribute and train the team!

3.2 Most Common Migration Patterns

Pattern 1: FORM -> Method

Before (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.

After (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 Table -> Released CDS View

Before (Classic):

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

After (Cloud):

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

Find mapping:

1. Search SAP API Business Hub
2. ADT: Ctrl+Shift+A -> Search for I_Product
3. SAP table in Where-Used List -> Find CDS Views

Pattern 3: BAPI -> RAP/EML

Before (Classic):

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

After (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

Effort: Very high

Strategy:

1. Analysis: What fields/functions does Dynpro have?
2. Create RAP BO: Data model as CDS View
3. Behavior Definition: CRUD + Actions
4. Service Binding: OData V4
5. Fiori Elements: Automatically generated!
6. Annotations: Control UI layout

See: SAP Fiori Elements Guide

3.3 Tools for Code Transformation

Quick Fixes in ADT:

ADT offers Quick Fixes for many findings:

1. Right-click on ATC Finding
2. "Quick Fix" -> ADT suggests solution
3. Accept -> Code automatically adapted

Example: CONCATENATE -> String Template

Mass changes with ABAP Cleaner:

Open-source tool: github.com/SAP/abap-cleaner

• Auto-formatting
• Modernize obsolete syntax
• Available as Eclipse plugin

3.4 Non-Released APIs: What to Do?

Problem: You need an SAP table/FM that is not released.

Solutions:

1. Find released alternative:

   • Search API Business Hub
   • Ask SAP Community
   • Ctrl+Shift+A in ADT: Search for similar CDS Views

2. Open SAP ticket:

   • Via SAP Support Portal
   • Justify why you need the object
   • SAP can release API retrospectively (but takes time!)

3. Create wrapped API:

   • In Classic system: Build API wrapper
   • Mark as Released (only for On-Premise!)
   • Use in Cloud system

4. Find workaround:

   • Often there are detours via Released APIs
   • Community forums help

Important: Option 3 (Wrapped API) only works for S/4HANA On-Premise, NOT in BTP ABAP Environment!

Checklist Phase 3

• Coding guidelines communicated to team
• Developer trainings conducted
• Batch 1 objects migrated
• Code reviews conducted
• ATC Checks green (no more errors)
• Unit tests written for critical logic
• Batch 2, 3, … completed

Result: ABAP Cloud-compliant code, ATC-clean

Phase 4: Testing

Goal

Ensure migrated code is functionally identical.

4.1 Test Strategy

3-level test approach:

1. Unit Tests (automated)
2. Integration Tests (manual/automated)
3. User Acceptance Tests (manual by business department)

4.2 Write Unit Tests

For each critical method:

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
• Goal: >80% code coverage for critical classes

4.3 Regression Tests

Comparison Old vs. New:

1. Test data prepared in DEV system
2. Classic code executed -> Save output
3. Cloud code executed -> Save output
4. Diff comparison: Outputs must be identical

Tools:

• ABAP Unit for automated comparisons
• eCATT (Extended Computer Aided Test Tool)
• Custom test scripts

4.4 Performance Tests

Important: Cloud code can be slower (new APIs, more abstractions)

Measure:

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

" Execute code

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

For performance problems:

• Analyze SQL traces (ST05 in Classic, SQL Trace in ADT)
• Optimize CDS Views (indexes, projections)
• Batch EML operations

4.5 User Acceptance Testing (UAT)

Execution:

1. Test cases defined with business department
2. Test system provided (QAS)
3. Key users test (2-3 weeks)
4. Feedback collected -> Fix bugs
5. Sign-off from business department

Checklist Phase 4

• Unit tests written for critical logic (>80% coverage)
• Regression tests conducted (Old vs. New identical)
• Performance tests run (no degradation >20%)
• UAT completed (Sign-off from business department)
• Bugs documented & fixed
• Test reports created

Result: Tested, approved code

Phase 5: Go-Live & Rollout

Goal

Bring code to production without outages.

5.1 Go-Live Strategy

Option A: Cutover (deadline)

• All changes go live at once
• Clear cut
• High risk

Option B: Parallel Run

• Old + new code in parallel
• Feature toggles for switching
• Low risk
• Double maintenance effort

Option C: Canary Deployment

• New code for 10% of users -> 50% -> 100%
• Gradual validation
• Recommended!

5.2 Transport Strategy

Standard transport:

DEV -> QAS -> PRD

Pre-Go-Live Checks:

• All transports successfully imported in QAS?
• No syntax errors in QAS?
• ATC Checks green?
• UAT Sign-off available?
• Rollback plan ready?

5.3 Go-Live Checklist

1 week before:

• Go-Live communication to all users
• Support team briefed
• Monitoring dashboards set up
• Rollback procedure tested

On Go-Live day:

• Import transports to PRD (in maintenance window)
• Smoke tests in PRD (test critical functions)
• Activate monitoring (ST22, SM21, Application Logs)
• Support hotline ready

After Go-Live:

• 1 week intensive monitoring
• Collect user feedback
• Fix small bugs (hotfixes)
• Post-Go-Live review (Lessons Learned)

5.4 Rollback Plan

If something goes wrong:

1. Identify symptoms: Short dumps, incorrect data, performance problems
2. Decision: Hotfix or rollback?
3. Rollback:
   • Get old code version from Git
   • Create transport with old code
   • Import to PRD
4. Root Cause Analysis: What went wrong?

Checklist Phase 5

• Go-Live strategy determined (Cutover/Parallel/Canary)
• Transports ready
• Go-Live communication sent
• Support team briefed
• Rollback plan documented
• Monitoring setup active
• Go-Live successfully completed
• Post-Go-Live review conducted

Result: Code in production, running stably

Tool Overview

Effort Estimation

Rule of thumb:

• Simple objects (syntax only): 0.5-1 hr/object
• Medium objects (API changes): 2-4 hrs/object
• Complex objects (Dynpro -> Fiori): 10-40 hrs/object

Example: 1,000 objects

• 700 simple × 1 hr = 700 hrs
• 250 medium × 3 hrs = 750 hrs
• 50 complex × 20 hrs = 1,000 hrs
• Total: 2,450 hrs = ~14 months (1 developer) or ~3 months (5 developers)

Plus: Analysis, testing, project management (+30%) -> ~4 months with 5 developers

Common Problems & Solutions

Problem 1: “No Released Alternative Found”

Solution:

1. Search SAP API Business Hub: api.sap.com
2. Ask SAP Community: community.sap.com
3. Open SAP support ticket -> Request API release
4. Workaround via other Released APIs

Problem 2: “Dynpro Migration Too Expensive”

Solution:

• Option A: Increase budget (realistic)
• Option B: Keep Dynpro as “wrapper”, only backend in ABAP Cloud
• Option C: Use low-code tools (SAP Build Apps)

Problem 3: “Performance Degradation After Migration”

Solution:

• Optimize CDS Views (indexes, buffering)
• Batch EML operations (not in loop)
• Analyze SQL Trace -> Identify bottlenecks

Problem 4: “Team Lacks ABAP Cloud Skills”

Solution:

• Training: SAP Learning Hub, openSAP, external courses
• External consultants for critical phase
• Pair programming: Experienced + inexperienced together

Further Resources

On abapcloud.com:

• ABAP Cloud vs Classic ABAP Comparison
• 10 Most Common ABAP Cloud Mistakes
• ABAP Cloud Developer Roadmap
• ABAP Cloud Cheat Sheet

SAP Resources:

• Clean Core & ABAP Cloud FAQ - Doktor ERP
• ABAP Cloud Migration Example - Software Heroes
• Custom Code Migration Workshops - GitHub

Summary

ABAP Cloud Migration is not a sprint, but a marathon. With this 5-step plan you have a clear roadmap:

1. Analysis: Understand codebase (ATC, Custom Code Migration App)
2. Planning: Realistic timeline, team, budget
3. Adaptation: Rewrite code (FORM->Methods, APIs->CDS, Dynpro->Fiori)
4. Testing: Unit tests, regression tests, UAT
5. Go-Live: Transport, monitoring, support

Key success factors:

• Thorough analysis (don’t underestimate!)
• Realistic timeline (+30% buffer)
• Build team skills (training!)
• Iterative approach (not Big Bang)
• Involve stakeholders (communication!)

Good luck with your migration!

Need help? Write us in the comments - we’re happy to help with specific migration questions!