# Quanto tempo leva sair do Bubble > O prazo vem do tempo rodando os dois sistemas em paralelo, não da velocidade de código. Veja o que decide a duração e por que virar por workflow encurta. - Autor: Marlon Trettin - Publicado: 2026-08-21 · Atualizado: 2026-08-21 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/quanto-tempo-leva-sair-do-bubble --- A duração de uma migração de Bubble é definida por quanto tempo você roda os dois sistemas em paralelo, não por quão rápido alguém escreve código. Construir o substituto é a parte previsível. Conciliar contra o sistema antigo sobre trabalho real, e virar a chave um workflow por vez, é o que preenche o calendário e o que mantém a operação de pé. ## TL;DR - Tempo de código é a parte estimável do cronograma e raramente é a mais longa. - Rodar em paralelo não é margem de segurança para cortar. É onde as regras de negócio não documentadas aparecem. - Virar por workflow em vez de por app encurta o calendário e reduz o estrago de cada erro. - A única coisa que confiavelmente estica o prazo é começar sem inventário. ## Por que "quanto tempo leva" é a pergunta errada para começar? Porque a resposta depende quase inteiramente de um número que ninguém mediu ainda: quanta regra de negócio mora dentro do app. Pergunte a duração antes do inventário e você recebe um chute vestido de plano. O inventário são quatro contagens: workflows e seus desvios, integrações externas, tipos de dado com seus relacionamentos, e regras de permissão por papel. Produzir isso leva dias. Pular custa meses, porque cada workflow não mapeado aparece no meio do projeto como surpresa, e surpresa em migração chega com uma operação pendurada nela. Há um segundo motivo para a pergunta enganar. Migração não é uma duração, são duas: quanto tempo até o primeiro workflow rodar no sistema novo, e quanto tempo até o último sair do antigo. Os times cotam a segunda e planejam a primeira. ## O que define o cronograma de verdade? Quatro coisas, e só uma delas é engenharia. **A decisão de modelo de dados.** O Bubble documenta [exportação em CSV e uma API](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) para os seus registros, então a extração está resolvida. O que não está resolvido é o esquema. O que chega é a estrutura de dados do Bubble, e reconstruí-la igual importa as restrições das quais você queria escapar. Decidir quais campos são reais e quais são resíduo de algum workflow é a decisão de cauda mais longa, porque tudo depois herda a escolha. **Quantidade de integrações.** Cada conexão externa tem a própria autenticação, sandbox, limite de requisição e uma contraparte que não está preocupada com o seu prazo. Integração é a origem mais comum de data estourada, e também é a mais fácil de contar antes. **Rodagem em paralelo.** Os dois sistemas processam trabalho real enquanto você compara saídas. É a parte que os times tentam encurtar e a parte que não deveria ser encurtada, pelos motivos abaixo. **Latência de aprovação dentro da sua própria empresa.** Quem assina que o número novo é o número certo. Isso é invisível em todo plano e presente em todo projeto. ## Quanto tempo o paralelo precisa durar? O suficiente para cobrir um ciclo inteiro do que quer que o seu negócio faça, incluindo o ciclo que só acontece no fechamento do mês ou do trimestre. Essa é a regra prática, e ela vem do que o paralelo serve. Não é teste de carga. É o único mecanismo que faz aparecer regra de negócio que ninguém escreveu, e essas regras costumam morar nas exceções: a rotina de fechamento, a correção que alguém faz à mão todo mês, o cliente com condição especial. O paralelo só paga o próprio custo quando você compara saídas. Pegue os números em que o negócio já confia, os de um relatório que alguém lê toda semana, e concilie entre os dois sistemas até baterem. Cada divergência é uma especificação que você não tinha. Rodar os dois sistemas sem conciliar é pagar em dobro por um sistema. Se o ciclo que importa é mensal, você precisa de pelo menos um mês limpo, e realisticamente dois: o primeiro faz as diferenças aparecerem, o segundo prova que foram corrigidas. ## Dá para encurtar? Dá, de três formas, e nenhuma delas envolve trabalhar mais rápido. **Vire por workflow, não por app.** Mova primeiro os workflows de que o negócio depende e deixe o resto rodando onde está. Isso encurta o tempo até o primeiro resultado, de projeto inteiro para algumas semanas, e limita o estrago de qualquer erro a um workflow em vez da operação. **Apague antes de construir.** Cada workflow aposentado é um que você não escopa, não constrói, não testa, não concilia e não vira. Migração é o raro momento em que apagar é politicamente possível, e é a maior alavanca sobre o calendário que existe. **Compre fôlego primeiro.** A causa mais comum de migração apressada é prazo definido por uma fatura. O [FAQ de preços do Bubble](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) documenta que o app com overage desligado sai do ar ao bater o limite de workload, e esse é o tipo de prazo em torno do qual ninguém planeja bem. Na [plataforma da Colo Saúde](/cases/colo-saude) o primeiro movimento foi ficar: o app foi estabilizado no Bubble e teve o consumo cortado em 60%, e só então a reconstrução em Next.js e Supabase começou. Essa sequência comprou um calendário em vez de uma contagem regressiva. O [sistema da UniTrust](/cases/unitrust) mostra o outro formato, em que o trabalho foi na direção de um sistema construído para sustentar a operação de uma corretora de seguros nos Estados Unidos. O que decidiu cada caminho foi fôlego, que é a mesma variável que decide o cronograma. ## Perguntas frequentes **Dá para migrar num fim de semana?** Só se o app quase não tiver regra de negócio, e nesse caso você não estaria migrando. Virada de fim de semana assume que o sistema novo já está correto, e correção é exatamente o que o paralelo estabelece. Quem pula costuma gastar as semanas economizadas depois, num momento pior. **Qual é a parte mais longa de uma migração?** Normalmente conciliar os dois sistemas, seguida da decisão de modelo de dados. Escrever o código é previsível e raramente domina. Se um plano mostra código como o maior bloco, o plano está sem a conciliação. **Precisamos congelar mudanças no app do Bubble durante a migração?** Não inteiramente, mas toda mudança feita no sistema antigo durante a reconstrução é uma mudança que precisa ser feita duas vezes. Congelar os workflows já em andamento, e deixar o resto andar, é o meio-termo que costuma se sustentar. ## O próximo passo Se você precisa de uma data defensável em vez de uma data otimista, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para dimensionar o inventário e o paralelo por trás dele. [Agende uma conversa](/contato).