Antes de decir que sí: qué pedirle al cliente
Un MSP lo resumía en Reddit: intentan decir que sí a estas apps, mientras haya límites. En la práctica, eso es código respaldado y datos que no queden expuestos. Con una app de Base44, el punto de partida son ocho respuestas:
- Espacio de trabajo. En qué espacio de Base44 está la app: el personal del empleado o uno de la empresa.
- Plan y pago. Qué plan, con qué tarjeta y cuántos créditos gasta al mes la app publicada.
- Copia del código. Si la sincronización con GitHub está activa (plan Builder o superior) y si el repositorio es de la organización de la empresa o de una persona.
- Quién edita. Quién puede cambiar la app hoy y si alguien de esa lista ya no está en la empresa.
- Claves e integraciones. Qué claves de API y servicios conectados usa la app, y a nombre de quién están.
- Datos. Qué guarda la app (clientes, personal, facturación) y si hay datos personales delicados.
- Quién entra. Si la app publicada es pública o privada, y cómo se inicia sesión.
- Entrenamiento de IA. En todos los planes salvo Enterprise, la licencia de Base44 permite usar el contenido para entrenar modelos de IA. Que el cliente lo sepa.
Si la app está en el espacio personal de alguien, con su tarjeta y sin GitHub, la empresa en realidad no la tiene. Es lo primero que hay que arreglar, se elija el camino que se elija.
En los servidores del cliente, el código está en su repositorio y los datos en su base de datos, así que casi todas estas preguntas se responden solas.
Lo que no controlas mientras la app siga en Base44
La documentación de seguridad de Base44 dice que la seguridad de cada app es responsabilidad de quien la crea. Para un MSP, eso te cae a ti en cuanto dices que sí. Estas son las piezas a las que no llegas:
- El inicio de sesión. El inicio de sesión de empresa para la app solo está en los planes Enterprise (Business o Enterprise), que se contratan por ventas. En los planes públicos no puedes atar el acceso al directorio del cliente.
- La seguridad de cada app. Los tokens de sesión se guardan en el almacenamiento local del navegador y no se pueden poner cabeceras de seguridad propias (CSP, HSTS) a una app.
- Las copias de los datos reales. Los datos están en la base de datos de Base44. Puedes descargar las tablas en CSV a mano, pero las funciones del servidor, los usuarios y los archivos subidos se quedan en Base44.
- Los cambios de la plataforma. Planes, créditos y funciones cambian al ritmo de Base44, y la app del cliente tiene que seguirlo.
De la plataforma se ocupa Base44. Lo que se queda fuera de tus herramientas es justo la capa que vigilas en cualquier otro cliente.
En los servidores del cliente, el inicio de sesión, las copias y la base de datos están en herramientas que ya gestionas y vigilas.
De quién es la app de verdad: espacio de trabajo, dueño y plan
El error más habitual cuando una empresa «se queda» una app de Base44: nombrar dueño de la app a alguien de la empresa y dar el tema por cerrado. La documentación de Base44 dice que las apps pertenecen al espacio de trabajo donde se crearon y usan su plan y sus créditos, trabaje quien trabaje en ellas.
El orden que funciona:
- Crear un espacio de trabajo de la empresa, con la empresa como dueña y tú como administrador si tu contrato lo cubre.
- Mover la app a ese espacio. Solo puede hacerlo su dueño; los datos van con ella, los créditos no, y pasar de un espacio personal a uno compartido no tiene vuelta atrás.
- Cambiar el dueño si hace falta. El nuevo dueño tiene que aceptar. Para cada servicio conectado se elige mantenerlo o desconectarlo, y así el cliente conecta sus propias cuentas.
- Activar la sincronización con GitHub hacia un repositorio de la organización de la empresa.
Pasar una app directamente a alguien de fuera del espacio de trabajo solo se puede en los planes Enterprise y para los Partners aprobados de Base44. Esta sección sale de su documentación a 13 de octubre de 2026: vuelve a comprobarla antes de hacerlo, porque estas páginas cambian a menudo.
Enterprise, migración única o modelo híbrido: qué camino encaja
Base44 Enterprise resuelve el inicio de sesión y añade un registro de auditoría. La app y sus datos siguen en la nube de Base44, la producción sigue gastando créditos y el precio lo da ventas. Encaja si el inicio de sesión es la única pega y el cliente está a gusto en la nube.
Una migración única saca la app de Base44 para siempre. Te quedas el código y los datos, y se pierde el editor: desde ese día, cada cambio es trabajo de un programador. Encaja si el cliente tiene a alguien que se vaya a ocupar de ese código.
El modelo híbrido es el único en el que se cumplen las dos cosas: la app corre en los servidores del cliente, dentro de tus límites, y quien la creó sigue creándola en Base44. Es para el cliente que no quiere renunciar a la herramienta con la que hizo su app.
El modelo híbrido: el cliente sigue creando y la app queda dentro de tus límites
Keep44 lleva el servidor de la app a un servidor Windows (IIS, SQL Server y Node.js), en las oficinas del cliente o en uno que le gestiones tú. El cliente sigue editando en Base44 con datos de prueba. Cada cambio pasa por GitHub hasta el servidor, con copia previa y vuelta atrás.
Lo que le da a un MSP, pieza a pieza:
- Copias que controlas tú: los datos reales están en SQL Server, dentro del plan de copias que ya tienes. Cada sincronización hace una copia antes de tocar nada.
- Vuelta atrás: si un cambio que llega de Base44 rompe algo, el servidor vuelve a la versión anterior.
- Inicio de sesión de empresa: se entra con la cuenta de Entra ID y su MFA. Los roles salen de Entra, y a quien se deshabilita allí se le cierra la sesión en minutos. Detalle en la guía de SSO con Entra ID (en inglés).
- Sin créditos en producción: los empleados que usan la app no gastan créditos de Base44. El cliente solo necesita un plan para seguir editando.
- El cliente sigue creando: un campo o una pantalla nueva hecha en Base44 llega al servidor sin abrir un ticket a ningún programador.
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 la app de tu cliente, se confirma en el Diagnóstico.
Dónde entra Keep44: la parte de Base44, y el cliente sigue siendo tuyo
Mantener una app no debería convertir a un MSP en una empresa de desarrollo. En el modelo híbrido el trabajo se reparte así:
| Quién | Hace |
|---|---|
| Keep44 | El Diagnóstico, llevar el servidor de la app, montar la sincronización y el inicio de sesión, y el documento de traspaso |
| Tú, el MSP | El servidor, las copias, la monitorización, los usuarios en Entra y la relación con el cliente |
| El cliente | Sigue creando la app en Base44 |
El informe del Diagnóstico está pensado para que puedas presupuestar a partir de él. Keep44 no le vende al cliente servidores ni contratos de soporte. Si te sirve la lista completa de preguntas de IT, está en la checklist de seguridad de Base44 para IT, y el traslado paso a paso, en la guía de Base44 en servidor propio.
Cuándo Keep44 no es la respuesta: si el cliente ya tiene un plan Enterprise de Base44 y acepta la app en la nube, pon los límites dentro de Base44 con la lista de arriba. Si quiere salir de Base44 para siempre y tiene a alguien que se ocupe del código, una migración única es más sencilla.
Qué dejar por escrito con el cliente
Para pegar en el ticket de alta o en el contrato. Cada punto necesita respuesta antes de hacerte cargo de la app.
- Espacio de trabajo: la app está en un espacio de la empresa, no en uno personal.
- Plan: quién paga Base44 y a quién se avisa si cambian el plan o los créditos.
- Código: sincronización con GitHub activa, hacia un repositorio de la organización de la empresa.
- Quién edita: la lista de personas que pueden cambiar la app, revisada cuando alguien se va.
- Claves: cada clave de API y servicio conectado, y a nombre de quién está.
- Datos: qué guarda la app y cómo y cada cuánto se hace copia.
- Acceso: quién puede entrar y cómo se da de baja a quien se va.
- Alcance: qué cubres tú (accesos, copias, disponibilidad) y qué no (los cambios en la propia app).
Si eres quien creó la app
Tu MSP no quiere quitarte la app. Estas preguntas son las que le permiten decir que sí. En el modelo híbrido no rehaces nada: sigues cambiando la app en Base44 y los cambios llegan al servidor de la empresa. Pásale esta guía a tu MSP con las respuestas que ya sepas.
Fuentes
- Base44: Managing your workspace apps (las apps son de su espacio de trabajo, mover entre espacios, cambiar el dueño, traspasos fuera del espacio). Consultado el 13/10/2026.
- Base44: Transfer ownership to a workspace member (API en beta; excluye apps con claves o integraciones propias). Consultado el 13/10/2026.
- Base44: Security overview (la seguridad de cada app es de quien la crea, tokens de sesión, cabeceras). Consultado el 08/10/2026.
- Base44: Setting up SSO (inicio de sesión de empresa en los planes Enterprise). Consultado el 09/10/2026.
- Base44: Pricing (planes públicos, Enterprise por ventas, sincronización con GitHub). Consultado el 13/10/2026.
- Base44: for agencies (programa de partners). Consultado el 13/10/2026.
- Base44: Terms of Service update, June 2026 (licencia para entrenar modelos de IA). Consultado el 08/10/2026.