# Migrar de Bubble a código propio: cómo decidir > Salir de Bubble es un problema de alcance, no una prueba de lealtad. Qué documenta la plataforma sobre propiedad, qué encarece la reconstrucción y cómo moverse. - Autor: Marlon Trettin - Publicado: 2026-08-21 · Actualizado: 2026-08-21 - Idioma: es - Canonical: https://yowpi.com/es/blog/migrar-de-bubble-a-codigo-propio --- Migra de Bubble a código propio cuando la plataforma empieza a decidir lo que debería ser tuyo: cuánto cuesta operar la aplicación, cuándo se cae y con qué velocidad puedes cambiarla. El detonante no es la decepción con Bubble. Es el punto en que tu lógica de negocio superó a un runtime que no controlas. ## TL;DR - Tus datos salen contigo. Bubble documenta [exportación en CSV y una API](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) para eso. La lógica de la aplicación no sale, porque no puede exportarse como código. - La reconstrucción se cotiza por la lógica acumulada, no por la cantidad de pantallas. - Dos límites documentados fijan el plazo: consumo medido a [USD 0,30 por cada 1.000 unidades](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) sin suscripción de tier, y la aplicación fuera de línea al alcanzar el límite con el overage desactivado. - Opera los dos sistemas en paralelo sobre trabajo real antes del corte. Las fallas que importan son las que nadie documentó. ## ¿Cuándo llega el momento de salir de Bubble? Cuando la plataforma empieza a tomar decisiones que te corresponden. Bubble es bueno en lo suyo, y la mayoría de las aplicaciones que se van no debieron irse antes. La pregunta no es si la herramienta es buena. Es si todavía controlas las variables de las que depende el negocio. Importan tres señales, y solo una es sobre dinero. La primera es el trabajo medido. Bubble cobra la actividad de servidor en unidades de workload, y su [FAQ de precios](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) fija la tarifa base de excedente en USD 0,30 por cada 1.000 unidades para quien no tiene suscripción de tier. Aislado, es una línea de costo. Se vuelve problema porque el consumo sigue cómo se construyó la aplicación y no cuánto factura: un workflow ineficiente se convierte en una cuenta recurrente sin que nadie lo note. La segunda es más dura y está en la misma página. Con el overage desactivado, al alcanzar el límite Bubble indica que la aplicación queda fuera de línea y vuelve al inicio del siguiente período de facturación. La disponibilidad pasa a ser función de una configuración de cobro. La tercera no tiene número. Es el momento en que el equipo deja de proponer cambios porque cambiar cualquier cosa se volvió caro o riesgoso. Ese suele llegar antes que los otros dos y notarse después. ## ¿Qué te deja llevar Bubble? Datos, sí. Diseño, en parte. Lógica, no. Bubble es poco común en su claridad sobre esto, y leer la documentación vale más que el folclore sobre el encierro de plataforma. Sobre propiedad, Bubble afirma que eres dueño de tus datos, incluido el diseño de la aplicación y lo que subieron tus usuarios, mientras que [Bubble conserva la propiedad del código](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) que hace funcionar la aplicación. Sobre exportación, la misma página es directa: las aplicaciones de Bubble corren solo en la plataforma de Bubble, y no hay forma de exportar la aplicación como código. Para los datos documenta exportación automática en CSV y la API de Bubble para acceso por script. Y dice que la empresa ayuda a exportar el diseño y hará lo posible por ayudar a quien quiera irse. Existe incluso una salvaguarda que casi nadie lee: si Bubble cesara operaciones, su código fuente se liberaría bajo licencia abierta, para que las aplicaciones siguieran funcionando en un servidor Bubble autoalojado. Así que el encuadre honesto es más simple que la historia de terror. Un runtime que no escribiste es un runtime que no te llevas. Toda plataforma de esta categoría funciona igual. Lo que separa una migración fácil de una difícil es cuánta lógica de negocio pusiste ahí dentro. ## ¿Qué encarece de verdad la reconstrucción? La lógica, no las pantallas. El conteo de pantallas es el número al que recurren los equipos porque es visible, y es el número que 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 del trabajo, 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. 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 borrar, y borrar es el trabajo más barato de todo el proyecto. Una advertencia sobre el consumo: Bubble rastrea [doce tipos de actividad](https://manual.bubble.io/help-guides/workload/understanding-workload) que alimentan el total del mes, y la misma funcionalidad consume de formas muy distintas según cómo se construyó. Parte de tu cuenta es arquitectura y no destino, lo que significa que parte de la presión por migrar puede aliviarse antes de migrar. ## ¿Cómo moverse sin detener la operación? En secuencia, y acertar el 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 la práctica, en una tabla? Después reconstruye la lógica contra el inventario y opera los dos sistemas en paralelo sobre trabajo real antes del corte. 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](/es/cases/colo-saude) 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](/es/cases/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. ## ¿Qué pierdes al salir? Velocidad de cambio, al menos al principio. En Bubble una edición pequeña toma minutos. En un sistema propio pasa por una persona desarrolladora y por un release. Quien diga lo contrario está vendiendo algo. También renuncias a un alojamiento que mantiene otro y asumes decisiones de infraestructura que antes no tenías que tomar. Ese es un costo real y entra en la comparación con honestidad. Lo que recuperas es el control de las tres variables de arriba: cuánto cuesta operar, si se mantiene en línea y hasta dónde puede crecer. Para una aplicación que todavía busca su forma, ese intercambio suele ser malo. Para una operación de la que un negocio ya depende, suele no serlo. ## 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. Reconstruye la lógica contra un inventario, opera el sistema nuevo en paralelo con el viejo sobre trabajo real, y haz el corte por workflow y no por aplicación completa. **¿Conviene arreglar la aplicación en Bubble antes o salir directamente?** Muchas veces conviene arreglar antes. Si la presión es el costo de workload y la aplicación se construyó de forma ineficiente, parte de esa cuenta es arquitectura y no plataforma. Estabilizar compra margen de tiempo, y ese margen decide si la reconstrucción será tranquila o apurada. ## 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](/es/contacto).