Guide de migration ABAP Cloud : Du Classic au Cloud en 5 etapes (2025)

La migration de Classic ABAP vers ABAP Cloud est l’un des plus grands defis pour les developpeurs SAP en 2025. Ce guide vous montre un plan pratique en 5 etapes pour migrer systematiquement votre base de code personnalise vers le Cloud.

Ce qui vous attend

• Feuille de route de migration en 5 etapes avec un deroulement clair
• Apercu des outils (ATC, Custom Code Migration, ABAP Test Cockpit)
• Checklists pour chaque phase
• Planification realiste
• Problemes frequents et solutions
• Bonnes pratiques de projets reels

Temps de lecture estime : 15 minutes | Temps de mise en oeuvre : 3-12 mois (selon la base de code)

Pourquoi migrer ?

Strategie Clean Core

SAP poursuit la strategie Clean Core : Utiliser uniquement les Released APIs, pas de modifications du standard SAP, developper Cloud-ready.

Avantages :

• Stabilite des mises a jour : Mises a jour sans ruptures de code
• Cloud-Ready : Le code fonctionne sur BTP et S/4HANA Cloud
• Perennite : Nouvelles fonctionnalites uniquement en ABAP Cloud
• Performance : Runtime optimise
• Maintenabilite : APIs propres et standardisees

Inconvenients en cas de non-migration :

• La dette technique s’accumule
• Les mises a jour deviennent de plus en plus difficiles
• Pas d’options Cloud (BTP ABAP Environment)
• Recrutement difficile (les developpeurs modernes veulent le Cloud)

Les 5 phases de migration en apercu

Duree totale : 3-12 mois (selon la taille de la base de code)

Phase 1 : Analyse de la base de code

Objectif

Comprendre combien de code doit etre migre et quels problemes surviendront.

1.1 Executer l’application Custom Code Migration

L’application Custom Code Migration (App Fiori dans S/4HANA) analyse votre code automatiquement.

Acces :

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

Execution :

1. Lancer l’application
2. Selectionner le scope : Tous les objets Z*/Y* ou selectivement
3. Choisir la variante ATC : ABAP_CLOUD_READINESS
4. Lancer l’analyse (peut durer 30 min - 2 h)
5. Evaluer les resultats

Output :

• Nombre d’objets affectes
• Severite (Error, Warning, Info)
• Top problemes par frequence
• Effort estime

1.2 Utiliser manuellement ABAP Test Cockpit (ATC)

Pour des packages/objets individuels :

Dans SAP GUI :

Transaction: ATC
1. Clic droit sur package → Run → ATC Check
2. Check Variant: ABAP_CLOUD_READINESS
3. Analyser les resultats

Dans ABAP Development Tools (Eclipse) :

1. Clic droit sur Package/Class → Run As → ABAP Test Cockpit
2. Check Variant: ABAP_CLOUD_READINESS
3. Analyser les findings

1.3 Categoriser les resultats d’analyse

Findings typiques :

1.4 Priorisation

Classifiez les objets selon :

1. Criticite metier : Quelle importance pour les processus metier ?
2. Frequence d’utilisation : A quelle frequence le code est-il execute ?
3. Effort de migration : Quel effort pour l’adaptation ?

Priorisation recommandee :

Haute priorite : Haute criticite metier + Faible effort
Priorite moyenne : Criticite moyenne + Effort moyen
Basse priorite : Faible criticite + Effort eleve
→ A supprimer : Objets non utilises !

Checklist Phase 1

• Custom Code Migration App executee
• ATC Checks effectues sur les packages critiques
• Findings categorises (Syntaxe, APIs, UI, etc.)
• Objets classes par priorite
• Liste des objets obsoletes creee (a supprimer)
• Parties prenantes informees (Management, PO, etc.)

Resultat : Excel/PDF avec tous les findings + estimation de l’effort

Phase 2 : Planification de la migration

Objectif

Creer un plan realiste avec ressources, calendrier et risques.

2.1 Equipe & Ressources

Roles necessaires :

• Developpeur ABAP Cloud (2-5 ETP selon la base de code)
• Consultant fonctionnel (pour la comprehension de la logique metier)
• Responsable qualite (pour les tests)
• Chef de projet (pour la coordination)

Combler le deficit de competences :

• Formation ABAP Cloud pour l’equipe (voir Roadmap)
• Ateliers RAP & CDS Views
• Consultants externes pour les cas complexes

2.2 Choisir la strategie de migration

Option A : Big Bang (tout d’un coup)

• Avantage : Go-Live rapide
• Inconvenient : Risque eleve
• Pour : Petites bases de code (<500 objets)

Option B : Iteratif (etape par etape)

• Avantage : Faible risque
• Avantage : Apprendre des erreurs precoces
• Inconvenient : Duree totale plus longue
• Pour : Bases de code moyennes/grandes (>500 objets)

Option C : Hybride

• Objets critiques d’abord (Big Bang)
• Reste en rattrapage iteratif
• Recommande pour la plupart des projets

2.3 Creer le calendrier

Exemple pour 1 000 objets :

Semaine 1-4:   Phase 1 - Analyse ✓
Semaine 5-6:   Phase 2 - Planification ✓
Semaine 7-14:  Lot 1 - Objets critiques (200)
Semaine 15-22: Lot 2 - Frequemment utilises (300)
Semaine 23-30: Lot 3 - Restants (500)
Semaine 31-36: Tests & Corrections
Semaine 37:    Go-Live

2.4 Gestion des risques

Risques typiques :

Checklist Phase 2

• Equipe constituee
• Strategie de migration choisie (Big Bang/Iteratif/Hybride)
• Calendrier enregistre dans l’outil projet (Jira, Azure DevOps)
• Budget approuve
• Risques documentes avec plan de mitigation
• Reunion des parties prenantes effectuee (Kick-off)

Resultat : Plan de projet avec calendrier, budget, ressources

Phase 3 : Adaptation du code (La migration proprement dite)

Objectif

Reecrire le code pour le rendre conforme ABAP Cloud.

3.1 Definir les directives de developpement

Directives de codage ABAP Cloud :

1. Uniquement des Released APIs/CDS Views
2. Pas de FORM/PERFORM → Methodes
3. Pas de SELECT * → Champs explicites
4. String Templates au lieu de CONCATENATE
5. Table Expressions au lieu de READ TABLE
6. Strict Mode dans tous les BDEFs
7. Gestion d'exception pour les Table Expressions
8. EML au lieu des appels BAPI (si possible)
9. Fiori au lieu de Dynpro
10. Tests unitaires pour la logique critique

Distribuer et former l’equipe !

3.2 Patterns de migration les plus frequents

Pattern 1 : FORM → Methode

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

Apres (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 : Table SAP → CDS View Released

Avant (Classic) :

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

Apres (Cloud) :

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

Trouver le mapping :

1. Rechercher dans SAP API Business Hub
2. ADT : Ctrl+Shift+A → Rechercher I_Product
3. Table SAP dans Where-Used List → Trouver les CDS Views

Pattern 3 : BAPI → RAP/EML

Avant (Classic) :

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

Apres (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 : Tres eleve

Strategie :

1. Analyse : Quels champs/fonctions a le Dynpro ?
2. Creer RAP BO : Modele de donnees comme CDS View
3. Behavior Definition : CRUD + Actions
4. Service Binding : OData V4
5. Fiori Elements : Genere automatiquement !
6. Annotations : Piloter la mise en page UI

Voir : Guide SAP Fiori Elements

3.3 Outils pour la transformation de code

Quick Fixes dans ADT :

ADT offre des Quick Fixes pour de nombreux findings :

1. Clic droit sur le finding ATC
2. "Quick Fix" → ADT propose une solution
3. Accepter → Code automatiquement adapte

Exemple : CONCATENATE → String Template

Modifications en masse avec ABAP Cleaner :

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

• Auto-Formatting
• Moderniser la syntaxe obsolete
• Disponible comme plugin Eclipse

3.4 APIs non-Released : Que faire ?

Probleme : Vous avez besoin d’une table SAP/FM qui n’est pas Released.

Solutions :

1. Rechercher une alternative Released :

   • Rechercher dans API Business Hub
   • Demander a la communaute SAP
   • Ctrl+Shift+A dans ADT : Rechercher des CDS Views similaires

2. Ouvrir un ticket SAP :

   • Via le portail support SAP
   • Justifier pourquoi vous avez besoin de l’objet
   • SAP peut releaser l’API ulterieurement (mais ca prend du temps !)

3. Creer une API wrappee :

   • Dans le systeme Classic : Construire un API-Wrapper
   • Marquer comme Released (uniquement On-Premise !)
   • Utiliser dans le systeme Cloud

4. Trouver un contournement :

   • Souvent il y a des detours via les Released APIs
   • Les forums communautaires aident

Important : L’option 3 (Wrapped API) fonctionne UNIQUEMENT avec S/4HANA On-Premise, PAS dans BTP ABAP Environment !

Checklist Phase 3

• Directives de codage communiquees a l’equipe
• Formations developpeurs effectuees
• Objets lot 1 migres
• Revues de code effectuees
• ATC Checks verts (plus d’erreurs)
• Tests unitaires ecrits pour la logique critique
• Lots 2, 3, … effectues

Resultat : Code conforme ABAP Cloud, propre ATC

Phase 4 : Tests

Objectif

S’assurer que le code migre est fonctionnellement identique.

4.1 Strategie de test

Approche de test a 3 niveaux :

1. Tests unitaires (automatises)
2. Tests d’integration (manuels/automatises)
3. Tests d’acceptation utilisateur (manuels par le metier)

4.2 Ecrire des tests unitaires

Pour chaque methode critique :

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.

Executer les tests :

• ADT : Ctrl+Shift+F10
• Objectif : >80% de couverture de code pour les classes critiques

4.3 Tests de regression

Comparaison ancien vs nouveau :

1. Donnees de test preparees dans le systeme DEV
2. Code Classic execute → Sauvegarder l’output
3. Code Cloud execute → Sauvegarder l’output
4. Comparaison diff : Les outputs doivent etre identiques

Outils :

• ABAP Unit pour les comparaisons automatisees
• eCATT (Extended Computer Aided Test Tool)
• Scripts de test personnalises

4.4 Tests de performance

Important : Le code Cloud peut etre plus lent (nouvelles APIs, plus d’abstractions)

Mesurer :

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

" Executer le code

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

En cas de problemes de performance :

• Analyser les SQL-Traces (ST05 en Classic, SQL Trace dans ADT)
• Optimiser les CDS Views (index, projections)
• Batching des operations EML

4.5 Tests d’acceptation utilisateur (UAT)

Execution :

1. Cas de test definis avec le metier
2. Systeme de test fourni (QAS)
3. Key Users testent (2-3 semaines)
4. Feedback collecte → Corriger les bugs
5. Sign-Off par le metier

Checklist Phase 4

• Tests unitaires ecrits pour la logique critique (>80% couverture)
• Tests de regression effectues (ancien vs nouveau identique)
• Tests de performance effectues (pas de degradation >20%)
• UAT termine (Sign-Off du metier)
• Bugs documentes & corriges
• Rapports de test crees

Resultat : Code teste et valide

Phase 5 : Go-Live & Deploiement

Objectif

Mettre le code en production sans pannes.

5.1 Strategie de Go-Live

Option A : Cutover (Date cible)

• Tous les changements productifs d’un coup
• Avantage : Coupure nette
• Inconvenient : Risque eleve

Option B : Execution parallele

• Ancien + nouveau code en parallele
• Feature Toggles pour la bascule
• Avantage : Faible risque
• Inconvenient : Double effort de maintenance

Option C : Canary Deployment

• Nouveau code pour 10% des utilisateurs → 50% → 100%
• Avantage : Validation progressive
• Recommande !

5.2 Strategie de transport

Transport standard :

DEV → QAS → PRD

Verifications pre-Go-Live :

• Tous les transports importes avec succes en QAS ?
• Pas d’erreurs de syntaxe en QAS ?
• ATC Checks verts ?
• Sign-Off UAT present ?
• Plan de rollback pret ?

5.3 Checklist Go-Live

1 semaine avant :

• Communication Go-Live a tous les utilisateurs
• Equipe support briefee
• Tableaux de bord de monitoring configures
• Procedure de rollback testee

Le jour du Go-Live :

• Transports importes en PRD (dans la fenetre de maintenance)
• Smoke Tests en PRD (tester les fonctions critiques)
• Monitoring active (ST22, SM21, Application Logs)
• Hotline support prete

Apres le Go-Live :

• 1 semaine de surveillance intensive
• Feedback utilisateurs collecte
• Petits bugs corriges (Hotfixes)
• Revue post-Go-Live (Lessons Learned)

5.4 Plan de rollback

Si quelque chose tourne mal :

1. Reconnaitre les symptomes : Shortdumps, donnees incorrectes, problemes de performance
2. Decision : Hotfix ou Rollback ?
3. Rollback :
   • Recuperer l’ancienne version du code depuis Git
   • Creer un transport avec l’ancien code
   • Importer en PRD
4. Analyse de cause racine : Qu’est-ce qui a mal tourne ?

Checklist Phase 5

• Strategie Go-Live definie (Cutover/Parallele/Canary)
• Transports prets
• Communication Go-Live envoyee
• Equipe support briefee
• Plan de rollback documente
• Setup monitoring actif
• Go-Live effectue avec succes
• Revue post-Go-Live effectuee

Resultat : Code productif, fonctionnement stable

Apercu des outils

Estimation de l’effort

Regle empirique :

• Objets simples (syntaxe uniquement) : 0,5-1 h/objet
• Objets moyens (changements API) : 2-4 h/objet
• Objets complexes (Dynpro → Fiori) : 10-40 h/objet

Exemple : 1 000 objets

• 700 simples x 1 h = 700 h
• 250 moyens x 3 h = 750 h
• 50 complexes x 20 h = 1 000 h
• Total : 2 450 h = ~14 mois (1 developpeur) ou ~3 mois (5 developpeurs)

Plus : Analyse, Tests, Gestion de projet (+30%) → ~4 mois avec 5 developpeurs

Problemes frequents & Solutions

Probleme 1 : “Pas d’alternative Released trouvee”

Solution :

1. Rechercher dans SAP API Business Hub : api.sap.com
2. Demander a la communaute SAP : community.sap.com
3. Ouvrir un ticket support SAP → Demander le release de l’API
4. Contournement via d’autres Released APIs

Probleme 2 : “Migration Dynpro trop couteuse”

Solution :

• Option A : Augmenter le budget (realiste)
• Option B : Garder Dynpro comme “Wrapper”, uniquement backend en ABAP Cloud
• Option C : Utiliser des outils Low-Code (SAP Build Apps)

Probleme 3 : “Degradation de performance apres migration”

Solution :

• Optimiser les CDS Views (index, buffering)
• Batching des operations EML (pas en boucle)
• Analyser le SQL Trace → Identifier les goulots d’etranglement

Probleme 4 : “L’equipe n’a pas de competences ABAP Cloud”

Solution :

• Formation : SAP Learning Hub, openSAP, formations externes
• Consultants externes pour la phase critique
• Pair Programming : Experimentes + inexperimentes ensemble

Ressources supplementaires

Sur abapcloud.com :

• Comparaison ABAP Cloud vs Classic ABAP
• 10 erreurs ABAP Cloud les plus courantes
• Feuille de route developpeur ABAP Cloud
• Aide-memoire ABAP Cloud

Ressources SAP :

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

Resume

La migration ABAP Cloud n’est pas un sprint, mais un marathon. Avec ce plan en 5 etapes, vous avez une feuille de route claire :

1. Analyse : Comprendre la base de code (ATC, Custom Code Migration App)
2. Planification : Calendrier realiste, equipe, budget
3. Adaptation : Reecrire le code (FORM→Methodes, APIs→CDS, Dynpro→Fiori)
4. Tests : Tests unitaires, tests de regression, UAT
5. Go-Live : Transport, monitoring, support

Facteurs cles de succes :

• Analyse approfondie (ne pas sous-estimer !)
• Planification realiste (+30% de buffer)
• Developper les competences de l’equipe (formation !)
• Approche iterative (pas de Big Bang)
• Embarquer les parties prenantes (communication !)

Bonne chance pour votre migration !

Besoin d’aide ? Ecrivez-nous dans les commentaires - nous sommes la pour vous aider avec vos questions de migration !