En enero de 2024 escribí en este blog un artículo sobre SAP Build. Lo cerré con una reflexión sobre la madurez del low-code/no-code en el ecosistema SAP. Poco más de dos años después, SAP ha tomado una decisión que cambia el escenario.
El 23 de marzo de 2026, SAP anunció oficialmente la deprecación de SAP Build Apps como producto standalone. SAP Build Apps era la herramienta de desarrollo visual low-code/no-code de la suite SAP Build: el canvas drag-and-drop que permitía construir aplicaciones web y móviles sin escribir código. La promesa del citizen developer dentro del ecosistema SAP.
Qué era SAP Build Apps
SAP Build Apps nació de la adquisición de AppGyver en 2021 y se integró como uno de los tres pilares de SAP Build, junto a SAP Build Process Automation y SAP Build Work Zone. Su propuesta era democratizar el desarrollo de aplicaciones: cualquier perfil, técnico o funcional, podía construir una app empresarial arrastrando componentes, definiendo lógica visual y conectando con sistemas SAP o externos vía API, sin necesidad de código.
Era la apuesta de SAP por el low-code/no-code como palanca de extensibilidad para casos de uso concretos: extensiones ligeras, aplicaciones de campo, formularios complejos o procesos específicos que no justificaban un desarrollo a medida completo.
Qué cambia exactamente
SAP Build Apps queda retirado como SKU independiente. Los clientes con contrato vigente mantienen acceso hasta que este expire, pero no habrá nuevas funcionalidades ni soporte a nuevos centros de datos. Para proyectos nuevos, SAP redirige al SAP Build unificado.
El FAQ oficial confirma además que no existe ruta de migración directa: los proyectos frontend en SAP Build Apps no se pueden importar al nuevo entorno. Para proyectos en curso, SAP recomienda rehacerlos sobre CAP, el Cloud Application Programming Model.
Puedes leer el anuncio completo en el blog oficial de SAP Community.
Por qué desaparece: la IA como nuevo modelo de desarrollo
El low-code/no-code nació para resolver un problema concreto: el código es una barrera de entrada para perfiles no técnicos. La solución fue abstraer esa barrera detrás de un canvas visual.
SAP considera que ese problema tiene ahora una solución distinta. Joule, la IA de SAP integrada en SAP Build, permite describir en lenguaje natural lo que se necesita y obtener código real basado en CAP, más mantenible y alineado con el clean core. Es lo que se conoce como vibe coding: desarrollo conversacional asistido por inteligencia artificial.
La lógica es que si la IA elimina la fricción de escribir código, la capa de abstracción visual deja de ser necesaria. El resultado no es una representación visual del código, sino el código mismo, revisable y mantenible por un desarrollador.
Qué hay que hacer ahora
Para proyectos nuevos, SAP apunta a SAP Build unificado con CAP y Joule for Developers como herramientas centrales. Para proyectos móviles, el Mobile Development Kit dentro de SAP Mobile Services. El documento oficial SAP Build Apps – The Path Forward detalla las opciones de transición disponibles.
Por dónde va esto
La deprecación de SAP Build Apps refleja un cambio más amplio en la industria. Herramientas como GitHub Copilot o Cursor están mostrando que la IA puede reducir la fricción del desarrollo pro-code de forma significativa. SAP apuesta por ese camino con Joule y SAP Build Code como eje del desarrollo de extensiones y aplicaciones sobre BTP.
El canvas drag-and-drop cierra su ciclo. El desarrollo asistido por IA abre el siguiente.
Jorge Ocampos 