Qué se transfiere al salir de Bubble y qué se rehace
Cuando migras de Bubble, tus datos van contigo y la lógica de la aplicación no. Bubble documenta ambos lados: los datos de usuario salen en CSV o por la API, y la aplicación en sí no puede exportarse como código. Esa división define el costo real de salir, y no tiene nada que ver con si Bubble es bueno o malo.
¿Qué se transfiere de verdad al salir de Bubble?
Tres cosas se comportan distinto, y saber cuál es cuál convierte un miedo difuso en un proyecto con alcance.
Tus datos se transfieren. La página de propiedad de aplicación y datos describe exportar los datos creados por usuarios en archivos CSV y usar la API de Bubble para automatizar el acceso a esos mismos datos. Para la mayoría de los equipos era la parte que más preocupaba y es la que está genuinamente resuelta.
Tu diseño se transfiere en parte. Bubble dice que puede ayudar a exportar el diseño, lo que en la práctica significa que te quedas con la referencia visual y el inventario de pantallas. No te quedas con los componentes.
Tu lógica no se transfiere. Cada workflow, condición, regla de privacidad y tarea programada se escribió en el editor de Bubble y corre en el runtime de Bubble. Esos se reconstruyen.
¿Por qué la lógica no puede ir contigo?
Porque eres dueño de lo que hiciste, y Bubble es dueño de lo que hizo. La documentación usa una comparación simple: Microsoft es dueña de Word, tú eres dueño de los documentos que escribes en él. Tu aplicación es el documento, el runtime es Word.
Esa frontera es deliberada. Y viene con una salvaguarda que casi nadie lee: Bubble afirma que si la empresa cesara operaciones, su código fuente se liberaría bajo licencia abierta para que las aplicaciones siguieran funcionando.
Así que el encuadre honesto es más simple que la historia del encierro. Bubble es un runtime, y un runtime que no escribiste es uno que no te llevas. Toda plataforma de esta categoría funciona igual.
¿Cuándo quedarse cuesta más que reconstruir?
Cuando la plataforma empieza a tomar decisiones que deberían ser tuyas. Dos de ellas merecen atención, y ambas están documentadas.
La primera es el trabajo medido. Bubble cobra el trabajo de servidor en unidades de workload, y el FAQ de precios fija el excedente base en USD 0,30 por cada 1.000 unidades para quien no tiene suscripción de tier. Aislado, es una línea de costo. El problema es que escala con cómo se construyó la aplicación y no con lo que factura, así que un workflow ineficiente se vuelve una cuenta recurrente en silencio.
La segunda es más dura. La misma página describe qué ocurre con el overage desactivado cuando la aplicación alcanza su límite: queda fuera de línea y vuelve al inicio del siguiente período de facturación. La disponibilidad se vuelve función de una configuración de cobro.
Lo que hace de esto una cuestión de arquitectura y no de precio es de dónde viene el consumo. La guía de workload dice que rastrea doce tipos de actividad, y que el mismo trabajo puede correr del lado del cliente o del servidor según cómo se haya construido la aplicación. Dos aplicaciones con tráfico idéntico pueden facturar muy distinto porque alguien eligió una búsqueda en lugar de una consulta directa.
Ninguno de estos hechos significa que debas irte. Significan que la decisión tiene un plazo, que ese plazo lo fija tu curva de crecimiento, y que parte de esa curva está bajo tu control antes siquiera de considerar migrar.
¿Cómo dimensionar la reconstrucción sin adivinar?
Cuenta la lógica. El conteo de pantallas es el número al que recurren los equipos porque es visible, y es el número que los engaña.
Haz el inventario de cuatro cosas: workflows y sus ramas, conexiones con APIs externas, tipos de dato con sus relaciones, y reglas de permiso por rol. Esa lista es la superficie real de la reconstrucción, y suele ser bastante menor de lo que sugiere el conteo de pantallas, porque buena parte de las pantallas son variaciones de las mismas pocas operaciones.
La diferencia aparece rápido cuando cuentas. Imagina una aplicación de operaciones con sesenta páginas, un número lo bastante grande como para trabar la conversación. Contar la lógica debajo suele revelar una fracción de eso en workflows, un puñado de integraciones y una lista corta de roles. Dimensionas contra los workflows. Las páginas se vuelven una tarea de diseño, y el diseño es barato al lado de lógica que hay que razonar dos veces.
Es también el momento de decidir qué no reconstruir. Un sistema que creció dentro de un editor visual acumula workflows que existen porque alguien los necesitó una vez. Migrar es la licencia rara para borrarlos.
¿Cómo se ve la migración en la práctica?
Corre en secuencia. Acertar ese orden importa más que el stack al que llegues.
Exporta y modela los datos primero. El CSV y la API entregan los registros, pero un registro no es un esquema. Lo que llega es la estructura de datos de Bubble, y reconstruirla igual importa las restricciones de las que querías escapar.
Tres preguntas separan el modelo real de sus accidentes. ¿Qué campos existen porque el negocio los necesita, y cuáles porque algún workflow necesitaba dónde guardar un valor? ¿Qué listas debieron ser relaciones? ¿Qué option sets se convirtieron en lo que en realidad es una tabla? Responderlas antes de escribir cualquier esquema es la decisión de cola más larga, porque todo lo construido después hereda la respuesta.
Después reconstruye la lógica contra el inventario. Opera los dos sistemas en paralelo sobre trabajo real antes del corte, porque las fallas que importan son las que nadie documentó.
El paralelo solo paga su costo cuando comparas salidas. Toma los números en los que el negocio ya confía, los de un reporte que alguien lee cada semana, y concílialos entre los dos sistemas hasta que coincidan. Las discrepancias son la especificación que nadie escribió.
Dos de nuestros casos muestran formas distintas de esto. En la plataforma de Colo Saúde el primer movimiento fue quedarse: la aplicación se estabilizó en Bubble y su consumo se redujo en 60%, y solo entonces empezó la reconstrucción en Next.js y Supabase. En el sistema de UniTrust el trabajo fue hacia un sistema construido para sostener la operación de una correduría de seguros en Estados Unidos. Lo que decidió cada camino fue el margen de tiempo: cuánto aguantaba la operación mientras ocurría la reconstrucción.
El marco completo de la decisión está en migrar de Bubble a código propio.
Preguntas frecuentes
¿Puedo exportar el código fuente de mi aplicación en Bubble?
No. La documentación de Bubble afirma que las aplicaciones corren solo en su plataforma y que no hay forma de exportar la aplicación como código. Puedes exportar tus datos, y Bubble ofrece ayuda para exportar el diseño, pero la lógica se reconstruye.
¿Migrar significa reescribir todo de una vez?
No, y hacerlo así es el error más común. El patrón más seguro es reconstruir la lógica contra un inventario, operar el sistema nuevo en paralelo con el viejo sobre trabajo real, y hacer el corte por workflow en lugar de por aplicación.
¿Mis datos sobreviven a la mudanza?
Sí. Esa es la parte bien documentada: la exportación en CSV y la API de Bubble alcanzan tus registros. El riesgo está en otro lado: llevarte el modelo de datos viejo sin cambios y heredar cada límite que lo moldeó.
El siguiente paso
Si estás pesando esta decisión y quieres una segunda lectura de tu propio inventario antes de cerrar un plan, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para recorrerlo contigo. Agenda una conversación.
Lee también
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin compromiso.
Agendar diagnóstico