El motivo por el que te quieres ir decide el camino
No todos los motivos para dejar Base44 llevan a la misma puerta. Busca el tuyo:
| Tu motivo | Camino que lo resuelve |
|---|---|
| IT no aprueba una app con los datos en la nube de un proveedor | Modelo híbrido, o migración única a vuestros servidores |
| Los datos personales tienen que quedarse en vuestra red | Modelo híbrido, o migración única a vuestros servidores |
| Los créditos se acaban según crece el uso | Modelo híbrido o migración única: ninguno gasta créditos en producción |
| La licencia para entrenar IA alcanza los datos de vuestros clientes | Modelo híbrido o migración única: los datos reales salen de Base44 |
| No quieres tu código ni tus prompts en Base44 | Solo la migración única |
| Una pantalla lenta o una integración que falla | Quedarse y arreglarla primero |
Sobre la IA: desde la actualización de condiciones de junio de 2026, todos los planes salvo Enterprise permiten a Base44 usar el contenido para entrenar modelos de IA. Separa qué te preocupa. Si son los datos de vuestros clientes, basta con sacar producción. Si son tu código y tus prompts, solo sirve salir del todo. Si el motivo son datos de salud, la guía de Base44 y RGPD con datos de salud lo cuenta en detalle.
Qué te da de verdad la exportación del código
Una duda que se repite en la comunidad de Base44 es si el código exportado funciona por su cuenta. Por sí solo, no. Así queda cada pieza al salir:
- El frontend. Sí. Con el plan Builder o superior puedes sincronizar el código con GitHub en los dos sentidos o descargar un ZIP.
- Las funciones del backend. Te llevas el código, pero necesitan otro sitio donde ejecutarse.
- Los datos. No van en la exportación. Se descargan tabla a tabla en CSV o por la API, que desde el 27 de noviembre de 2025 devuelve como máximo 5.000 elementos por petición.
- El inicio de sesión. Se queda en Base44. Pasar los usuarios a otro sistema obliga a que todos cambien la contraseña.
- Las llamadas al SDK. Cada lectura, escritura e inicio de sesión del código pasa por el SDK de Base44, y hay que apuntarlas una a una al backend nuevo.
- El comando eject. Pese al nombre, crea un backend nuevo en Base44 con la base de datos vacía. Sigues en la plataforma.
Por eso una exportación publicada en otro sitio “funciona” el primer día: Base44 sigue haciendo por detrás la mitad que no se ve.
En vuestros servidores, esa mitad es una base de datos, un inicio de sesión y unas funciones que vuestro equipo ve y respalda.
Cuánto cuesta una migración única, antes y después
Los precios públicos para salir de Base44 van desde herramientas automáticas gratuitas hasta presupuestos cerrados de 6.000 $ para una app pequeña, 12.000 $ para una mediana y 25.000 $ o más para las grandes (base44devs, según la recopilación de Axonbuild del 15 de agosto de 2026). En Upwork había en octubre de 2026 encargos de migración a precio fijo de unos 4.000 $. En la comunidad las respuestas van de “unos cientos de dólares” a “seis cifras”, y la sincera es que sin mirar la app nadie puede darte una cifra.
El presupuesto cubre la salida. Después, quien creó la app en Base44 ya no puede cambiarla. Un campo nuevo, una pantalla o el arreglo de un formulario pasan a ser un encargo para un desarrollador mientras la app exista.
Criterio de Keep44: si la app está terminada y apenas cambia, la migración única es la salida más sencilla. Si el equipo pide cambios cada semana, esa cola de encargos cuesta en pocos meses más que conservar el editor.
La salida que conserva el editor: el modelo híbrido
Keep44 lleva el backend de la app a un servidor Windows vuestro (IIS, SQL Server y Node.js), con los datos reales. Quien la creó sigue trabajando en Base44 con datos de prueba. Cada cambio pasa por el repositorio de GitHub hasta el servidor, con copia previa y vuelta atrás.
Frente a una migración única, pieza por pieza:
- Quien la creó sigue creando: un campo o una pantalla nueva hecha en Base44 llega al servidor sin pedírselo a un desarrollador.
- Sin créditos en producción: quien usa la app no gasta créditos de Base44. El plan solo sirve para editar.
- Sin cambiar contraseñas: la gente entra con su cuenta de empresa de Entra ID, y los roles salen de ahí. Detalle en la guía del servidor propio para una app de Base44.
- Vuelta atrás: cada sincronización hace una copia antes de tocar nada, y si un cambio rompe algo, el servidor vuelve a la versión anterior.
- Los datos reales no pasan por Base44: el editor solo ve datos de prueba.
Probado en laboratorio del 6 al 8 de octubre de 2026: Windows Server 2025, IIS, SQL Server, Node.js y un directorio gratuito de Entra ID, con una app de demostración hecha en Base44. Los cambios hechos en el editor, campos nuevos incluidos, llegaron al servidor con copia previa, y la vuelta atrás tardó 12 segundos. Si encaja en tu app, se confirma en el Diagnóstico.
Cuándo el modelo híbrido no es la respuesta
Si lo que quieres proteger es tu propio código, tus prompts y tu lógica, el híbrido no te sirve: la app se sigue creando en Base44, así que todo eso se queda allí. Te conviene una migración única. Lo mismo si la app está terminada, apenas cambia y tienes un desarrollador que se haga cargo del código.
Si la app se apoya en la IA integrada de Base44 o en servicios externos conectados a través de la plataforma, esas piezas necesitan un sustituto en el servidor, y el Diagnóstico dice cuáles. Y si tu único problema es una pantalla lenta, arréglala antes de irte a ningún sitio.
Lo que IT necesita saber
- Dónde están los datos: en el modelo híbrido, los datos reales están en SQL Server en vuestro servidor, dentro de vuestro plan de copias.
- Qué se queda en Base44: el diseño de la app y los datos de prueba. Nunca datos reales.
- Red: sin puertos de entrada. El servidor solo necesita salida al repositorio cuando hay cambios.
- Inicio de sesión: cuentas de empresa con Entra ID y MFA; a quien se da de baja allí se le corta el acceso.
- Quién mantiene qué: IT, el servidor y la base de datos; la app y la sincronización, el proveedor o vuestro equipo de desarrollo.
- Control de cambios: cada cambio llega como un commit en vuestro repositorio, con copia previa y vuelta atrás.
Si eres quien creó la app
Salir de Base44 suele significar entregar tu app a otra persona. El modelo híbrido es la única salida en la que te la quedas: la sigues cambiando en Base44 e IT tiene un servidor que puede aprobar. Si en tu empresa te piden sacarla, pásales esta guía. Para la lista completa de lo que suele preguntar IT, mira la checklist de seguridad de Base44 para IT.
Fuentes
- Base44: Pricing (plan Builder, exportación del código, sincronización con GitHub en los dos sentidos). Consultado el 13/10/2026.
- Base44: GitHub Integration (sincronización en los dos sentidos, plan Builder). Consultado el 11/10/2026.
- Base44: Terms of Service update, June 2026 (licencia para entrenar modelos de IA). Consultado el 08/10/2026.
- 13Labs: How to migrate a Base44 app onto infrastructure you actually own (contraseñas, eject, 5.000 elementos por petición). Publicado el 29/07/2026, consultado el 14/10/2026.
- Axonbuild: Migrate off Base44 (precios públicos de migración, mirados el 15/08/2026). Consultado el 14/10/2026.