SAP Build Apps se retira: qué cambia y cómo preparar la transición

SAP Build Apps está deprecado como producto independiente desde el 23 de marzo de 2026. El cambio no es un apagón inmediato para los clientes existentes: SAP mantiene acceso, SLA y mantenimiento hasta el final del contrato vigente. Sí cambia la decisión para proyectos nuevos y obliga a preparar una transición por aplicación, no solo por herramienta.

Esta guía resume el anuncio de SAP, separa los hechos confirmados de las decisiones que dependen de contrato y arquitectura, y propone un plan práctico para aplicaciones web, móviles y backend.

Lo esencial

• Qué cambia: SAP Build Apps deja de evolucionar como producto independiente y permanece en modo de mantenimiento.
• Qué ocurre con las apps existentes: pueden seguir utilizándose hasta la fecha de finalización del contrato actual; SAP no ha anunciado un apagón único aplicable a todos los clientes.
• Qué no existe: no hay una migración automática e integral de un proyecto Build Apps a otra tecnología.
• Qué debe validarse: el producto destino, los entitlements, el modelo de suscripción, la región, las integraciones y el esfuerzo de reconstrucción.

Qué ha anunciado SAP

SAP anunció el 23 de marzo de 2026 la deprecación de SAP Build Apps como oferta independiente. El anuncio indica que los clientes con contrato vigente, incluidos los modelos BTPEA, PAYG, CPEA y suscripción, conservan acceso completo, mantenimiento y SLA durante el plazo de su acuerdo. También indica que no habrá funciones nuevas ni soporte para nuevos centros de datos de SAP Build Apps.

La fecha relevante para una organización no es una supuesta fecha universal de apagado: es la fecha contractual aplicable a su cuenta. Antes de priorizar una migración, el propietario de la cuenta debe confirmar ese plazo y los servicios efectivamente contratados con SAP.

La oferta unificada y las suscripciones individuales

SAP describe SAP Build como una oferta que reúne desarrollo de aplicaciones, automatización de procesos y creación de sitios de negocio, con capacidades low-code, code-first y de IA generativa. SAP introdujo esta oferta unificada con un modelo de licencia única.

La documentación de SAP contempla también suscripciones individuales para SAP Build Apps, SAP Build Code, SAP Build Process Automation y SAP Build Work Zone. Las dos opciones coexisten. La comprobación necesaria no es negar la oferta unificada, sino confirmar el entitlement concreto: las capacidades de Joule, el consumo de IA mediante AI Units y la configuración disponible pueden depender del acuerdo y del servicio activado.

Necesidad	Opción que debe evaluarse	Comprobación previa
Aplicación web	SAP Build Code, SAPUI5 o React; CAP para el servicio cuando corresponda	Licencia, entorno de desarrollo, autenticación, destinos y ciclo de entrega
Aplicación móvil nativa	Mobile Development Kit y servicios móviles de SAP	Plataformas objetivo, offline, distribución y soporte del dispositivo
Backend y datos	CAP u otro backend aprobado por la arquitectura	Modelo de datos, APIs, migración de datos, seguridad y operación
Automatización	SAP Build Process Automation	Entitlement, responsables, aprobaciones, excepciones y trazabilidad
Sitio o punto de acceso	SAP Build Work Zone	Edición, identidad, roles, contenido y experiencia de usuario
Asistencia de IA	Capacidades de Joule disponibles para el servicio elegido	Entitlement, región, permisos, protección de datos y controles de salida

No hay migración automática: hay rutas con distinto alcance

Un proyecto Build Apps no se importa directamente como proyecto equivalente en la nueva oferta. SAP publica rutas distintas según el tipo de aplicación. Para proyectos web, existe una transformación asistida: se entrega el archivo MTAR a SAP mediante un ticket y se elige un destino SAPUI5 o React. El resultado es un punto de partida que debe revisarse, ajustarse, probarse y gobernarse como código.

La transformación no convierte por sí sola toda la solución. Las integraciones, destinos, autenticación, reglas de negocio, pruebas y operación deben evaluarse en el proyecto destino. Un equipo no debe tratar el resultado como una certificación funcional, de rendimiento o de seguridad.

Para proyectos backend, la guía de SAP propone una ruta manual: exportar los datos de cada entidad a CSV y cargarlos en un backend nuevo después de crear el modelo de destino. La exportación protege los datos, pero no reemplaza el diseño de tablas, validaciones, políticas de retención, roles ni APIs. Para aplicaciones móviles, SAP recomienda evaluar MDK y los SDK de SAP Mobile Services.

Cómo preparar una transición sin detener la operación

1. Confirma el plazo y los derechos de uso. Registra la fecha de finalización del contrato, los servicios activos, la región y el responsable de la cuenta.
2. Inventaría el portfolio. Para cada app identifica tipo, criticidad, usuarios, propietario de negocio, datos tratados, integraciones, credenciales, backend, canal de despliegue y dependencia de Build Apps.
3. Clasifica por decisión. Retirar, mantener hasta fin de contrato, reconstruir o sustituir. No todas las apps justifican una migración uno a uno.
4. Preserva los activos. Exporta MTAR y, cuando proceda, los datos de entidades. Protege esos archivos como información de proyecto y comprueba que la restauración sea posible.
5. Ejecuta un piloto. Elige una aplicación web no crítica para evaluar la transformación asistida o una reconstrucción controlada. Mide cobertura funcional, integraciones, calidad del código, pruebas y esfuerzo real.
6. Diseña el destino. Define autenticación, autorizaciones, secretos, observabilidad, transporte, pruebas y propiedad operativa antes de mover una aplicación crítica.
7. Valida antes del corte. Prueba procesos de extremo a extremo, concurrencia, errores, recuperación, acceso de usuarios y controles de seguridad. Planifica reversión y soporte posterior.

Qué evitar

• Suponer que toda capacidad de Joule o todo consumo de IA queda incluido sin comprobar entitlement, AI Units y configuración del servicio.
• Interpretar la deprecación como un apagado inmediato o como una fecha idéntica para todos los contratos.
• Llamar “migración automática” a una transformación de frontend que requiere revisión y reconstrucción de partes de la solución.
• Copiar datos a un backend nuevo sin definir modelo, autorizaciones, retención, APIs y pruebas.
• Iniciar una aplicación crítica en Build Apps sin contrastar antes el plazo contractual y la ruta destino.

¿Desaparece el low-code?

La deprecación de SAP Build Apps como producto independiente no equivale a una retirada general del low-code. SAP Build mantiene capacidades low-code y code-first, y SAP Build Process Automation sigue siendo una opción para escenarios de automatización. La decisión correcta depende del problema: una aplicación transaccional, un backend, un proceso de aprobación, un sitio de negocio y una experiencia móvil tienen restricciones distintas.

La generación asistida por IA puede acelerar parte del desarrollo, pero no sustituye el diseño funcional, las autorizaciones, las pruebas, el mantenimiento ni la responsabilidad sobre el resultado. Joule debe tratarse como una capacidad habilitada y gobernada en el servicio correspondiente, no como una garantía de que una app se generará, migrará o aprobará sola.

Conclusión

La decisión de SAP tiene un efecto práctico: SAP Build Apps deja de ser una elección adecuada para iniciar una aplicación estratégica sin una evaluación explícita de plazo y salida. Para las apps existentes, el horizonte es contractual y la transición debe ser gradual, inventariada y probada.

El primer paso no es escoger una herramienta por nombre. Es conocer qué aplicación existe, qué proceso sostiene, qué datos usa, qué derechos están contratados y cuál es la ruta de destino verificable. Con esa información, SAP Build Code, CAP, MDK, Process Automation, Work Zone o una combinación de ellos pueden evaluarse con rigor.

Fuentes oficiales verificadas

• SAP Community: SAP Build Apps Deprecation and The Path Forward
• SAP Help: What Is SAP Build Apps?
• SAP Community: pricing y packaging de la oferta unificada SAP Build
• SAP Help: suscripciones individuales de servicios SAP Build
• SAP Community: transformación de proyectos web