Blog
bubble → código propio

Cuánto tiempo lleva salir de Bubble

Marlon TrettinPublicado el 6 min de lectura
Sala nocturna larga donde dos líneas de producción paralelas corren lado a lado, una en azul frío y otra en ámbar, con una figura sola entre ellas en el punto del fondo donde convergen

La duración de una migración de Bubble la fija cuánto tiempo corres los dos sistemas en paralelo, no qué tan rápido alguien escribe código. Construir el reemplazo es la parte predecible. Conciliarlo contra el sistema viejo sobre trabajo real, y cortar un workflow a la vez, es lo que llena el calendario y lo que mantiene la operación en pie.

¿Por qué "cuánto tiempo lleva" es la pregunta equivocada para empezar?

Porque la respuesta depende casi por completo de un número que nadie ha medido todavía: cuánta lógica de negocio vive dentro de la aplicación. Pregunta la duración antes del inventario y recibes una adivinanza vestida de plan.

El inventario son cuatro conteos: workflows y sus ramas, integraciones externas, tipos de dato con sus relaciones, y reglas de permiso por rol. Producirlo lleva días. Saltárselo cuesta meses, porque cada workflow sin mapear aparece a mitad del proyecto como sorpresa, y una sorpresa en una migración llega con una operación colgada de ella.

Hay una segunda razón por la que la pregunta engaña. Una migración no es una duración, son dos: cuánto falta para que el primer workflow corra en el sistema nuevo, y cuánto para que el último salga del viejo. Los equipos cotizan la segunda y planifican la primera.

¿Qué fija el cronograma de verdad?

Cuatro cosas, y solo una es ingeniería.

La decisión del modelo de datos. Bubble documenta exportación en CSV y una API para tus registros, así que la extracción está resuelta. Lo que no está resuelto es el esquema. Lo que llega es la estructura de datos de Bubble, y reconstruirla igual importa las restricciones de las que querías escapar. Decidir qué campos son reales y cuáles son residuo de algún workflow es la decisión de cola más larga, porque todo lo que viene después hereda la elección.

Cantidad de integraciones. Cada conexión externa tiene su propia autenticación, sandbox, límites de petición y una contraparte a la que tu plazo no le importa. La integración es el origen más común de una fecha vencida, y también la más fácil de contar de antemano.

La corrida en paralelo. Los dos sistemas procesan trabajo real mientras comparas salidas. Es la parte que los equipos intentan acortar y la parte que no debería acortarse, por las razones de abajo.

La latencia de aprobación dentro de tu propia empresa. Quién firma que el número nuevo es el número correcto. Eso es invisible en todo plan y está presente en todo proyecto.

¿Cuánto tiene que durar el paralelo?

Lo suficiente para cubrir un ciclo completo de lo que sea que haga tu negocio, incluido el ciclo que solo ocurre al cierre del mes o del trimestre.

Esa es la regla práctica, y viene de para qué sirve el paralelo. No es una prueba de carga. Es el único mecanismo que hace aparecer reglas de negocio que nadie escribió, y esas reglas suelen vivir en las excepciones: la rutina de cierre, la corrección que alguien hace a mano cada mes, el cliente con condiciones especiales.

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. Cada discrepancia es una especificación que no tenías. Correr los dos sistemas sin conciliarlos es pagar el doble por un sistema.

Si el ciclo que importa es mensual, necesitas al menos un mes limpio, y realistamente dos: el primero hace aparecer las diferencias, el segundo prueba que se corrigieron.

¿Se puede acortar?

Sí, de tres formas, y ninguna implica trabajar más rápido.

Corta por workflow, no por aplicación. Mueve primero los workflows de los que depende el negocio y deja el resto corriendo donde está. Eso acorta el tiempo hasta el primer resultado, de proyecto entero a unas semanas, y limita el daño de cualquier error a un workflow en lugar de la operación.

Borra antes de construir. Cada workflow retirado es uno que no vas a estimar, construir, probar, conciliar ni cortar. La migración es el raro momento en que borrar es políticamente posible, y es la mayor palanca sobre el calendario que existe.

Compra margen de tiempo primero. La causa más común de una migración apurada es un plazo fijado por una factura. El FAQ de precios de Bubble documenta que la aplicación con overage desactivado queda fuera de línea al alcanzar su límite de workload, y ese es el tipo de plazo alrededor del cual nadie planifica bien. 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. Esa secuencia compró un calendario en vez de una cuenta regresiva.

El sistema de UniTrust muestra la otra forma, donde 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, que es la misma variable que decide el cronograma.

Preguntas frecuentes

¿Podemos migrar en un fin de semana?

Solo si la aplicación casi no tiene lógica de negocio, y en ese caso no estarías migrando. Un corte de fin de semana asume que el sistema nuevo ya es correcto, y la corrección es exactamente lo que establece el paralelo. Quien lo salta suele gastar las semanas ahorradas después, en un momento peor.

¿Cuál es la parte más larga de una migración?

Normalmente conciliar los dos sistemas, seguida de la decisión del modelo de datos. Escribir el código es predecible y rara vez domina. Si un plan muestra el código como el bloque más grande, al plan le falta la conciliación.

¿Hay que congelar cambios en la aplicación de Bubble durante la migración?

No del todo, pero cada cambio hecho en el sistema viejo durante la reconstrucción es un cambio que hay que hacer dos veces. Congelar los workflows ya en marcha, y dejar que el resto avance, es el punto medio que suele sostenerse.

El siguiente paso

Si necesitas una fecha defendible en vez de una fecha optimista, el Diagnóstico de Arquitectura Operacional es una conversación de 30 minutos para dimensionar el inventario y el paralelo que hay detrás. Agenda una conversación.

Lee también

Cases relacionados

Marlon Trettin

Marlon Trettin

Fundador de Yowpi · 25+ años de ingeniería de software

LinkedIn
Próximo paso

¿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