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é.
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 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 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 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 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.
Leia também
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem compromisso.
Agendar diagnóstico