Guía de migración ABAP Cloud: De Classic a Cloud en 5 pasos (2025)

La migración de Classic ABAP a ABAP Cloud es uno de los mayores desafíos para los desarrolladores SAP en 2025. Esta guía te muestra un plan práctico de 5 pasos con el que puedes migrar sistemáticamente tu base de código personalizado a la Cloud.

Lo que te espera

• Roadmap de migración de 5 pasos con flujo claro
• Resumen de herramientas (ATC, Custom Code Migration, ABAP Test Cockpit)
• Checklists para cada fase
• Planificación temporal realista
• Problemas frecuentes y soluciones
• Mejores prácticas de proyectos reales

Tiempo de lectura estimado: 15 minutos | Tiempo de implementación: 3-12 meses (según base de código)

¿Por qué migrar en absoluto?

Estrategia Clean Core

SAP sigue la estrategia Clean Core: Usar solo Released APIs, sin modificaciones al estándar SAP, desarrollar cloud-ready.

Ventajas:

• ✅ Estabilidad ante upgrades: Actualizaciones sin romper código
• ✅ Cloud-Ready: El código funciona en BTP y S/4HANA Cloud
• ✅ Preparado para el futuro: Nuevas funcionalidades solo en ABAP Cloud
• ✅ Rendimiento: Runtime optimizado
• ✅ Mantenibilidad: APIs limpias y estandarizadas

Desventajas de no migrar:

• ❌ La deuda técnica se acumula
• ❌ Los upgrades se vuelven cada vez más difíciles
• ❌ Sin opciones Cloud (BTP ABAP Environment)
• ❌ Reclutamiento difícil (los desarrolladores modernos quieren Cloud)

Las 5 fases de migración en resumen

Duración total: 3-12 meses (dependiendo del tamaño de la base de código)

Fase 1: Análisis de la base de código

Objetivo

Entender cuánto código debe migrarse y qué problemas surgirán.

1.1 Ejecutar Custom Code Migration App

La Custom Code Migration App (Fiori App en S/4HANA) analiza tu código automáticamente.

Acceso:

• Transacción: /n/SDF/CD_CCA (UI clásico)
• Fiori Launchpad: Tile “Custom Code Migration”

Ejecución:

1. Iniciar app
2. Seleccionar scope: Todos los objetos Z*/Y* o selectivos
3. Elegir ATC Check Variant: ABAP_CLOUD_READINESS
4. Iniciar análisis (puede tomar 30 min - 2 hrs)
5. Evaluar resultados

Output:

• Número de objetos afectados
• Severidad (Error, Warning, Info)
• Top problemas por frecuencia
• Esfuerzo estimado

1.2 Usar ABAP Test Cockpit (ATC) manualmente

Para paquetes/objetos individuales:

En SAP GUI:

Transacción: ATC
1. Clic derecho en paquete → Run → ATC Check
2. Check Variant: ABAP_CLOUD_READINESS
3. Analizar resultados

En ABAP Development Tools (Eclipse):

1. Clic derecho en Package/Class → Run As → ABAP Test Cockpit
2. Check Variant: ABAP_CLOUD_READINESS
3. Analizar Findings

1.3 Categorizar resultados del análisis

Findings típicos:

1.4 Priorización

Clasifica objetos según:

1. Criticidad de negocio: ¿Qué tan importante para procesos de negocio?
2. Frecuencia de uso: ¿Con qué frecuencia se ejecuta el código?
3. Esfuerzo de migración: ¿Qué tan costosa es la adaptación?

Priorización recomendada:

Prio alta: Alta criticidad de negocio + Bajo esfuerzo
Prio media: Criticidad media + Esfuerzo medio
Prio baja: Baja criticidad + Alto esfuerzo
→ Eliminar: ¡Borrar objetos que ya no se usan!

✅ Checklist Fase 1

• Custom Code Migration App ejecutada
• ATC Checks ejecutados en paquetes críticos
• Findings categorizados (Sintaxis, APIs, UI, etc.)
• Objetos clasificados por prioridad
• Lista de objetos obsoletos creada (para eliminar)
• Stakeholders informados (Management, PO, etc.)

Resultado: Excel/PDF con todos los findings + estimación de esfuerzo

Fase 2: Planificación de migración

Objetivo

Crear un plan realista con recursos, timeline y riesgos.

2.1 Equipo y recursos

Roles necesarios:

• ABAP Cloud Developer (2-5 FTE según base de código)
• Functional Consultant (para entender lógica de negocio)
• Quality Manager (para Testing)
• Project Manager (para coordinación)

Cerrar brecha de skills:

• Training ABAP Cloud para el equipo (ver Roadmap)
• Workshops de RAP y CDS Views
• Consultores externos para casos complejos

2.2 Elegir estrategia de migración

Opción A: Big Bang (todo a la vez)

• ✅ Go-Live rápido
• ❌ Alto riesgo
• 👉 Para bases de código pequeñas (<500 objetos)

Opción B: Iterativo (paso a paso)

• ✅ Bajo riesgo
• ✅ Aprender de errores tempranos
• ❌ Mayor duración total
• 👉 Para bases de código medianas/grandes (>500 objetos)

Opción C: Híbrido

• Objetos críticos primero (Big Bang)
• Resto iterativamente después
• 👉 Recomendado para la mayoría de proyectos

2.3 Crear timeline

Ejemplo para 1.000 objetos:

Semana 1-4:   Fase 1 - Análisis ✓
Semana 5-6:   Fase 2 - Planificación ✓
Semana 7-14:  Batch 1 - Objetos críticos (200)
Semana 15-22: Batch 2 - Frecuentemente usados (300)
Semana 23-30: Batch 3 - Restantes (500)
Semana 31-36: Testing y corrección de bugs
Semana 37:    Go-Live

2.4 Gestión de riesgos

Riesgos típicos:

✅ Checklist Fase 2

• Equipo formado
• Estrategia de migración elegida (Big Bang/Iterativo/Híbrido)
• Timeline registrado en herramienta de proyecto (Jira, Azure DevOps)
• Presupuesto aprobado
• Riesgos documentados con plan de mitigación
• Reunión de stakeholders realizada (Kick-off)

Resultado: Plan de proyecto con timeline, presupuesto, recursos

Fase 3: Adaptación de código (La migración real)

Objetivo

Reescribir código conforme a ABAP Cloud.

3.1 Definir directrices de desarrollo

Directrices de codificación ABAP Cloud:

1. Solo Released APIs/CDS Views
2. Sin FORM/PERFORM → Métodos
3. Sin SELECT * → Campos explícitos
4. String Templates en lugar de CONCATENATE
5. Table Expressions en lugar de READ TABLE
6. Strict Mode en todos los BDEFs
7. Exception Handling en Table Expressions
8. EML en lugar de BAPI-Calls (donde sea posible)
9. Fiori en lugar de Dynpro
10. Unit Tests para lógica crítica

¡Distribuir y capacitar al equipo!

3.2 Patrones de migración más frecuentes

Patrón 1: FORM → Método

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

Después (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 ).

Patrón 2: Tabla SAP → Released CDS View

Antes (Classic):

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

Después (Cloud):

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

Encontrar mapping:

1. Buscar en SAP API Business Hub
2. ADT: Ctrl+Shift+A → buscar I_Product
3. Lista Where-Used de tabla SAP → encontrar CDS Views

Patrón 3: BAPI → RAP/EML

Antes (Classic):

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

Después (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.

Patrón 4: Dynpro → Fiori Elements

Esfuerzo: ⭐⭐⭐ Muy alto

Estrategia:

1. Análisis: ¿Qué campos/funciones tiene el Dynpro?
2. Crear RAP BO: Modelo de datos como CDS View
3. Behavior Definition: CRUD + Actions
4. Service Binding: OData V4
5. Fiori Elements: ¡Generado automáticamente!
6. Annotations: Controlar layout UI

Ver: Guía SAP Fiori Elements

3.3 Herramientas para transformación de código

Quick Fixes en ADT:

ADT ofrece Quick Fixes para muchos findings:

1. Clic derecho en ATC Finding
2. "Quick Fix" → ADT sugiere solución
3. Aceptar → Código adaptado automáticamente

Ejemplo: CONCATENATE → String Template

Cambios masivos con ABAP Cleaner:

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

• Auto-Formatting
• Modernizar sintaxis obsoleta
• Disponible como plugin de Eclipse

3.4 APIs no liberadas: ¿Qué hacer?

Problema: Necesitas una tabla/FM SAP que no está liberada.

Soluciones:

1. Buscar alternativa liberada:

   • Buscar en API Business Hub
   • Preguntar en SAP Community
   • Ctrl+Shift+A en ADT: Buscar CDS Views similares

2. Abrir ticket SAP:

   • A través de SAP Support Portal
   • Justificar por qué necesitas el objeto
   • SAP puede liberar API posteriormente (¡pero toma tiempo!)

3. Crear API wrapped:

   • En sistema Classic: Construir API-Wrapper
   • Marcar como Released (¡solo en On-Premise!)
   • Usar en sistema Cloud

4. Encontrar workaround:

   • A menudo hay caminos alternativos vía Released APIs
   • Los foros de la comunidad ayudan

Importante: ¡La opción 3 (Wrapped API) funciona SOLO en S/4HANA On-Premise, NO en BTP ABAP Environment!

✅ Checklist Fase 3

• Directrices de codificación comunicadas al equipo
• Trainings de desarrolladores realizados
• Objetos Batch 1 migrados
• Code Reviews realizados
• ATC Checks verdes (sin más Errors)
• Unit Tests escritos para lógica crítica
• Batch 2, 3, … realizados

Resultado: Código conforme a ABAP Cloud, limpio en ATC

Fase 4: Testing

Objetivo

Asegurar que el código migrado sea funcionalmente idéntico.

4.1 Estrategia de testing

Enfoque de testing de 3 niveles:

1. Unit Tests (automatizados)
2. Integration Tests (manual/automatizados)
3. User Acceptance Tests (manual por área funcional)

4.2 Escribir Unit Tests

Para cada método crítico:

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.

Ejecutar Tests:

• ADT: Ctrl+Shift+F10
• Objetivo: >80% Code Coverage para clases críticas

4.3 Tests de regresión

Comparación Viejo vs. Nuevo:

1. Datos de prueba preparar en sistema DEV
2. Código Classic ejecutar → guardar output
3. Código Cloud ejecutar → guardar output
4. Comparación Diff: Outputs deben ser idénticos

Herramientas:

• ABAP Unit para comparaciones automatizadas
• eCATT (Extended Computer Aided Test Tool)
• Scripts de prueba personalizados

4.4 Tests de rendimiento

Importante: El código Cloud puede ser más lento (nuevas APIs, más abstracciones)

Medir:

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

" Ejecutar código

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

En problemas de rendimiento:

• Optimizar CDS Views (índices, Buffering)
• Agrupar operaciones EML (no en Loop)
• Analizar SQL Trace → Identificar cuellos de botella

4.5 User Acceptance Testing (UAT)

Ejecución:

1. Test-Cases definir con área funcional
2. Sistema de prueba proporcionar (QAS)
3. Key Users prueban (2-3 semanas)
4. Feedback recopilar → corregir bugs
5. Sign-Off por área funcional

✅ Checklist Fase 4

• Unit Tests escritos para lógica crítica (>80% Coverage)
• Tests de regresión ejecutados (Viejo vs. Nuevo idéntico)
• Tests de rendimiento ejecutados (sin degradación >20%)
• UAT completado (Sign-Off de área funcional)
• Bugs documentados y corregidos
• Informes de prueba creados

Resultado: Código probado y aceptado

Fase 5: Go-Live y Rollout

Objetivo

Llevar código a producción sin interrupciones.

5.1 Estrategia de Go-Live

Opción A: Cutover (fecha de corte)

• Todos los cambios productivos a la vez
• ✅ Corte claro
• ❌ Alto riesgo

Opción B: Parallel Run

• Código viejo + nuevo en paralelo
• Feature Toggles para conmutación
• ✅ Bajo riesgo
• ❌ Doble esfuerzo de mantenimiento

Opción C: Canary Deployment

• Nuevo código para 10% de usuarios → 50% → 100%
• ✅ Validación gradual
• 👉 ¡Recomendado!

5.2 Estrategia de transporte

Transporte estándar:

DEV → QAS → PRD

Checks Pre-Go-Live:

• ¿Todos los transportes importados exitosamente en QAS?
• ¿Sin errores de sintaxis en QAS?
• ¿ATC Checks verdes?
• ¿Sign-Off de UAT disponible?
• ¿Plan de rollback listo?

5.3 Checklist de Go-Live

1 semana antes:

• Comunicación de Go-Live a todos los usuarios
• Equipo de soporte informado
• Dashboards de monitoreo configurados
• Procedimiento de rollback probado

En el día del Go-Live:

• Importar transportes a PRD (en ventana de mantenimiento)
• Smoke Tests en PRD (probar funciones críticas)
• Activar monitoreo (ST22, SM21, Application Logs)
• Hotline de soporte lista

Después del Go-Live:

• 1 semana de monitoreo intensivo
• Recopilar feedback de usuarios
• Corregir bugs menores (Hotfixes)
• Review Post-Go-Live (Lessons Learned)

5.4 Plan de Rollback

Cuando algo sale mal:

1. Reconocer síntomas: Shortdumps, datos incorrectos, problemas de rendimiento
2. Decisión: ¿Hotfix o Rollback?
3. Rollback:
   • Obtener versión de código antigua de Git
   • Crear transporte con código antiguo
   • Importar a PRD
4. Root Cause Analysis: ¿Qué salió mal?

✅ Checklist Fase 5

• Estrategia de Go-Live definida (Cutover/Parallel/Canary)
• Transportes listos
• Comunicación de Go-Live enviada
• Equipo de soporte informado
• Plan de rollback documentado
• Setup de monitoreo activo
• Go-Live ejecutado exitosamente
• Review Post-Go-Live realizado

Resultado: Código productivo, funcionando establemente

Resumen de herramientas

Estimación de esfuerzo

Regla general:

• Objetos simples (solo sintaxis): 0.5-1 hr/objeto
• Objetos medios (cambios de API): 2-4 hr/objeto
• Objetos complejos (Dynpro → Fiori): 10-40 hr/objeto

Ejemplo: 1.000 objetos

• 700 simples × 1 hr = 700 hr
• 250 medios × 3 hr = 750 hr
• 50 complejos × 20 hr = 1.000 hr
• Total: 2.450 hr = ~14 meses (1 desarrollador) o ~3 meses (5 desarrolladores)

Plus: Análisis, Testing, Gestión de proyecto (+30%) → ~4 meses con 5 desarrolladores

Problemas frecuentes y soluciones

Problema 1: “No se encontró alternativa liberada”

Solución:

1. Buscar en SAP API Business Hub: api.sap.com
2. Preguntar en SAP Community: community.sap.com
3. Abrir ticket de soporte SAP → Solicitar liberación de API
4. Workaround vía otras Released APIs

Problema 2: “Migración Dynpro muy costosa”

Solución:

• Opción A: Aumentar presupuesto (realista)
• Opción B: Mantener Dynpro como “Wrapper”, solo Backend en ABAP Cloud
• Opción C: Usar herramientas Low-Code (SAP Build Apps)

Problema 3: “Degradación de rendimiento después de migración”

Solución:

• Optimizar CDS Views (índices, Buffering)
• Agrupar operaciones EML (no en Loop)
• Analizar SQL Trace → Identificar cuellos de botella

Problema 4: “El equipo no tiene skills ABAP Cloud”

Solución:

• Training: SAP Learning Hub, openSAP, capacitaciones externas
• Consultores externos para fase crítica
• Pair Programming: Experimentados + No experimentados juntos

Recursos adicionales

En abapcloud.com:

• Comparación ABAP Cloud vs Classic ABAP
• 10 errores ABAP Cloud más frecuentes
• Roadmap ABAP Cloud Developer
• ABAP Cloud Cheat Sheet

Recursos SAP:

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

Resumen

La migración ABAP Cloud no es un sprint, sino un maratón. Con este plan de 5 pasos tienes un roadmap claro:

1. Análisis: Entender base de código (ATC, Custom Code Migration App)
2. Planificación: Timeline realista, equipo, presupuesto
3. Adaptación: Reescribir código (FORM→Métodos, APIs→CDS, Dynpro→Fiori)
4. Testing: Unit Tests, Tests de regresión, UAT
5. Go-Live: Transporte, Monitoreo, Soporte

Factores de éxito más importantes:

• ✅ Análisis exhaustivo (¡no subestimar!)
• ✅ Planificación temporal realista (+30% buffer)
• ✅ Desarrollar skills del equipo (¡Training!)
• ✅ Enfoque iterativo (no Big Bang)
• ✅ Involucrar stakeholders (¡Comunicación!)

¡Mucho éxito en tu migración!

¿Necesitas ayuda? Escríbenos en los comentarios - ¡estamos encantados de ayudar con preguntas concretas de migración!