MIS CURSOS
BTP, CAP, Desarrollo Visual
SAP Build Apps se retira: qué cambia y cómo preparar la transición
Qué significa la deprecación del no-code de SAP y cómo preparar la transición
Resumen del anuncio oficial de SAP del 23 de marzo de 2026 sobre la deprecación de SAP Build Apps y la transición a la oferta unificada SAP Build.
El 23 de marzo de 2026, SAP anunció en su comunidad oficial que SAP Build Apps deja de venderse como producto independiente. En el lenguaje de SAP, queda «deprecado»: sigue funcionando, pero entra en fin de vida y no recibirá nuevas funciones.
Es el cierre de una etapa que empezó en 2021, cuando SAP compró AppGyver, su herramienta para crear aplicaciones sin programar. No es un apagón inmediato: quien ya tiene apps en marcha puede seguir usándolas. Pero sí marca un cambio de rumbo con fechas concretas. Vamos a verlo paso a paso.
Contenido
Lo esencial, en 4 puntos:
Qué pasa: SAP Build Apps se retira como producto independiente desde el 23 de marzo de 2026.
A quién afecta y cuándo: si ya lo usas, lo mantienes hasta que acabe tu contrato. Después, no podrás crear nuevas instancias.
Qué se usa ahora: la oferta unificada SAP Build (SAP Build Code, CAP, Joule y más), todo en una sola licencia.
El punto delicado: no hay migración automática. Las apps actuales hay que rehacerlas, con algo de ayuda por parte de SAP.
Un poco de historia: de AppGyver a la oferta unificada
Para entender la decisión, ayuda mirar el camino recorrido:
Fecha
Hito
Febrero 2021
SAP compra AppGyver, una herramienta finlandesa para crear apps sin código, y la incorpora a su plataforma (SAP BTP)
Noviembre 2022
Nace la marca SAP Build: AppGyver pasa a llamarse SAP Build Apps
Abril 2025
SAP lanza la oferta unificada SAP Build: una sola licencia que junta desarrollo de apps, automatización de procesos y creación de sitios web
23 marzo 2026
SAP Build Apps se retira como producto independiente. Sin nuevas funciones ni hoja de ruta
El hilo es claro. En 2021, SAP apostó por el citizen developer (el «desarrollador ciudadano»): la idea de que cualquier persona de negocio pudiera montar sus propias aplicaciones de forma visual, arrastrando elementos, sin escribir código.
La oferta unificada de 2025 fue el primer aviso del cambio: SAP dejó de vender SAP Build Apps por separado y lo metió dentro de un paquete más grande. El anuncio de 2026 cierra ese movimiento.
Fuente: https://www.sap.com/products/technology-platform/low-code-app-builder.html
Qué dice exactamente el anuncio
Estos son los puntos clave, en lenguaje llano:
Fecha de retirada: 23 de marzo de 2026. Desde ese día deja de venderse por separado.
Si ya eres cliente, tranquilidad: mantienes acceso, soporte y mantenimiento hasta que termine tu contrato actual. Da igual el tipo de licencia que tengas (BTPEA, PAYG, CPEA o suscripción).
Cuando acabe el contrato: ya no podrás crear instancias nuevas.
No habrá novedades: SAP no añadirá funciones ni dará soporte a nuevos centros de datos para este producto.
El precio puede cambiar según el caso de uso. Conviene revisar las condiciones en la próxima renovación.
¿Por qué lo retira SAP?
La razón oficial es «simplificar el portfolio» y enfocar la inversión donde más valor aporta. Pero detrás hay dos motivos de fondo fáciles de entender:
Su arquitectura tenía techo. En SAP Build Apps, el diseño visual y la lógica iban muy unidos. Eso es ágil para prototipos, pero se queda corto en proyectos grandes que necesitan flujos de aprobación, auditoría y crecer sin problemas.
La IA generativa cambió las reglas. Hoy puedes describir lo que quieres en lenguaje natural y obtener código estándar (en CAP, SAPUI5 o React) que luego se puede mantener y versionar. Esto le quita buena parte del sentido al desarrollo visual cerrado. Dicho de forma simple: quien antes iba a usar AppGyver, hoy le pide la app a un asistente como Joule.
Qué se usa ahora: la oferta unificada SAP Build
El reemplazo es la oferta unificada SAP Build (de abril de 2025): una sola plataforma y una sola licencia que cubre todo lo que antes hacía Build Apps, y más. Según lo que necesites:
Si quieres…
Ahora usas…
Aplicaciones web
SAP Build Code (programación asistida por IA) con CAP y SAPUI5/Fiori
Apps móviles nativas
Mobile Development Kit (MDK) y los SDK de SAP Mobile Services
Backend y datos
CAP (el modelo de SAP para construir servicios y datos)
Automatizar procesos
SAP Build Process Automation (flujos, aprobaciones, reglas)
Webs y portales internos
SAP Build Work Zone
Ayuda con IA
Joule y la generación de código con IA
La idea es dejar de separar «herramienta para negocio» y «herramienta para programadores», y reunirlo todo en un mismo sitio. El low-code no desaparece: sigue fuerte para automatizar procesos. Lo que cambia es que el desarrollo de aplicaciones se apoya cada vez más en código generado con ayuda de IA. Es la misma dirección que SAP mostró en Sapphire 2026 con Joule Studio.
El punto delicado: no hay migración automática
Esto es lo que más conviene planificar. Las apps de SAP Build Apps no se pasan solas a la nueva plataforma. El propio FAQ oficial lo dice claro: no se pueden importar.
Lo que SAP sí ofrece, según el tipo de proyecto:
1. Apps web → transformación con ayuda de SAP.
Exportas tu app (un archivo .mtar, que es el «paquete» de la aplicación), abres un ticket a SAP (componente CA-LCA-ACP) y eliges si la quieres en SAPUI5 o React. SAP te devuelve el código ya transformado, usando sus propias herramientas de IA. Eso sí: es una ayuda de partida, no un resultado final. Tendrás que revisarlo, ajustarlo y probarlo, y solo cubre la parte visual (las conexiones al backend se rehacen aparte).
2. Backend (datos) → exportar e importar a mano.
Sacas los datos de cada tabla en formato .csv y los subes a un proyecto CAP nuevo. Hay que crear antes la tabla destino.
3. Apps móviles → rehacerlas con MDK.
Para proyectos móviles, la recomendación es reconstruirlos con el Mobile Development Kit.
4. ¿Proyecto a punto de salir a producción?
Si usas el backend de Build Apps y estás cerca de lanzar, SAP recomienda pasarte a CAP cuanto antes.
A tener en cuenta: este tipo de transición es habitual en SAP (te garantizan el servicio hasta fin de contrato, pero «migrar» significa en la práctica reconstruir). La novedad positiva es que, por primera vez, SAP usa su propia IA para ayudarte a recuperar parte del trabajo. Tómalo como un punto de partida, no como una migración completa.
¿Significa esto el fin del low-code?
Es la pregunta que más se ha repetido. La respuesta corta: no, pero cambia de forma.
Por un lado, la IA generativa cubre buena parte de lo que prometía el «sin código». Si en una tarde generas una app funcional con Joule o Build Code, una herramienta visual cerrada pierde atractivo. Además, el código que genera la IA es estándar: se puede versionar, probar y ampliar. Lo que hacía Build Apps, en cambio, solo vivía dentro de Build Apps.
Por otro lado, el low-code sigue muy vivo para automatizar procesos (aprobaciones, formularios, flujos) dentro de SAP Build Process Automation. Lo que se retira no es el low-code en general, sino esta herramienta visual concreta como producto suelto.
En resumen: SAP no entierra el low-code, lo reordena. Concentra su inversión en una sola plataforma en lugar de mantener dos caminos en paralelo.
Cómo prepararte si tienes Build Apps en producción
Un plan sencillo en seis pasos:
Haz inventario de tus apps: web, móvil, backend y conexiones.
Mira tu contrato. Su fecha de fin es tu plazo real; después no habrá instancias nuevas.
Exporta ya los archivos .mtar (apps web) y .csv (datos), aunque no migres todavía. Es tu copia de seguridad.
Prueba el servicio de transformación (ticket CA-LCA-ACP) con una app no crítica y mira qué tal queda.
Elige destino por tipo: CAP para backend, Build Code/SAPUI5 para web, MDK para móvil.
No empieces nada nuevo en Build Apps, ni siquiera pruebas.
Formación guiada con casos reales SAP
Si quieres ponerte al día con el nuevo enfoque —Build Code, CAP, Joule y desarrollo asistido por IA— con casos reales y no solo demos:
Taller Joule for Developers — activación, ABAP MCP, copilotos e integraciones reales.
Master SAP ABAP Cloud Avanzado a Experto — RAP, CDS, Clean Core.
Toda la información en logaligroup.com/formacion.
Conclusión
SAP no retira SAP Build Apps por ser un mal producto, sino por estrategia. Quiere reunir todo el desarrollo en una sola plataforma —SAP Build, dentro de su gran apuesta por la IA empresarial— donde la inteligencia artificial hace gran parte del trabajo que antes se intentaba simplificar con herramientas visuales.
Para los clientes, el cambio tiene un coste real: rehacer apps, revisar licencias y formar a los equipos. Pero la dirección es clara: del desarrollo visual «arrastrando cajas» al desarrollo asistido por IA que genera código estándar.
Si tienes Build Apps en producción, ya sabes tu plazo: el fin de tu contrato. Y si hoy decides con qué construir tu próxima app en SAP, la respuesta de SAP es Build Code, CAP, MDK y Joule.
El low-code no muere: se integra en algo más grande y más conectado con la IA.
Fuentes oficiales (verificadas junio 2026)
SAP Community (blog oficial de SAP, Patrick Schad, 23 marzo 2026) — SAP Build Apps Deprecation and The Path Forward: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-build-apps-deprecation-and-the-path-forward/ba-p/14351750
SAP Help Portal — SAP Build Apps – The Path Forward (guía de servicio ya marcada como «Deprecated»): https://help.sap.com/docs/build-apps/service-guide/sap-build-apps-path-forward
SAP Help Portal — What’s New for SAP Build Apps: https://help.sap.com/docs/build-apps/service-guide/what-s-new-for-sap-build-apps
SAP Community — From SAP Build Apps to Pro-Code SAPUI5 Vibe Coded with UI5 MCP Server: https://community.sap.com/t5/tooling-sap-build-blog-posts/from-sap-build-apps-to-pro-code-sapui5-vibe-coded-with-ui5-mcp-server/ba-p/14370733
Artículo elaborado por el equipo de formación de Logali Group con base en datos oficiales SAP de 2026.
