# O que transfere ao sair do Bubble e o que se refaz > Seus dados saem do Bubble. Sua lógica não. Veja o que a plataforma documenta sobre os dois lados e como essa divisão define o custo real de migrar. - Autor: Marlon Trettin - Publicado: 2026-08-21 · Atualizado: 2026-08-21 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/o-que-transfere-ao-sair-do-bubble --- Quando você migra do Bubble, os seus dados vão junto e a lógica da aplicação não. O Bubble documenta os dois lados: dado de usuário sai em CSV ou pela API, e o app em si não pode ser exportado como código. Essa divisão define o custo real de sair, e não tem nada a ver com o Bubble ser bom ou ruim. ## TL;DR - Dado é portátil. A documentação do próprio Bubble descreve [exportação em CSV e uma API](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) para acesso programático. - Lógica não é portátil. O Bubble afirma que os apps rodam só na plataforma dele e que sair significa reconstruir a lógica da aplicação. - O custo de migrar acompanha quanta regra de negócio você acumulou dentro da plataforma, não quantas telas o app tem. - Responda quanto ficar custa no ano que vem antes de precificar uma reconstrução. ## O que realmente transfere quando você sai do Bubble? Três coisas se comportam de formas diferentes, e saber qual é qual transforma um medo vago em projeto com escopo. Seus dados transferem. A página de [posse de aplicação e de dados](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership) descreve exportar dados criados pelo usuário em arquivos CSV e usar a API do Bubble para automatizar o acesso aos mesmos dados. Para a maioria dos times, essa era a parte que mais preocupava e é a que está genuinamente resolvida. Seu design transfere em parte. O Bubble diz que pode ajudar a exportar o design, o que na prática significa que você fica com a referência visual e o inventário de telas. Você não fica com os componentes. Sua lógica não transfere. Todo workflow, condição, regra de privacidade e rotina agendada foi escrita no editor do Bubble e roda no runtime do Bubble. Esses são reconstruídos. ## Por que a lógica da aplicação não pode ir junto? Porque você é dono do que fez, e o Bubble é dono do que ele fez. A documentação usa uma comparação simples: a Microsoft é dona do Word, você é dono dos documentos que escreve nele. Seu app é o documento, o runtime é o Word. Essa fronteira é deliberada. E vem com uma salvaguarda que quase ninguém lê: o Bubble afirma que, se a empresa encerrasse as operações, o código-fonte seria liberado sob licença aberta para que os apps continuassem rodando. Então o enquadramento honesto é mais simples que a história de aprisionamento. O Bubble é um runtime, e runtime que você não escreveu é runtime que você não leva. Toda plataforma dessa categoria funciona igual. ## Quando ficar custa mais do que reconstruir? Quando a plataforma passa a tomar decisões que deveriam ser suas. Duas delas merecem atenção, e as duas são documentadas. A primeira é o trabalho medido. O Bubble cobra trabalho de servidor em unidades de workload, e o [FAQ de preços](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) fixa o excedente base em US$ 0,30 por 1.000 unidades para quem não tem assinatura de tier. Isolado, é uma linha de custo. O problema é que ele escala com a forma como o app foi construído, e não com o quanto ele fatura, então workflow ineficiente vira conta recorrente em silêncio. A segunda é mais dura. A mesma página descreve o que acontece com o overage desligado quando o app bate o limite: ele sai do ar e volta no início do próximo ciclo de cobrança. Disponibilidade vira função de uma configuração de cobrança. O que faz disso uma questão de arquitetura e não de preço é de onde vem o consumo. O [guia de workload](https://manual.bubble.io/help-guides/workload/understanding-workload) diz que são doze tipos de atividade rastreados, e que o mesmo trabalho pode rodar no cliente ou no servidor dependendo de como o app foi construído. Dois apps com tráfego idêntico podem cobrar valores bem diferentes porque alguém escolheu uma busca no lugar de uma consulta direta. Nenhum desses fatos significa que você deve sair. Significam que a decisão tem prazo, que o prazo é definido pela sua curva de crescimento, e que parte dessa curva está sob seu controle antes mesmo de considerar migrar. ## Como escopar a reconstrução sem chutar? Conte a lógica. Contagem de tela é o número que os times usam porque é visível, e é o número que engana. Faça o inventário de quatro coisas: workflows e seus desvios, conexões com APIs externas, tipos de dado com seus relacionamentos, e regras de permissão por papel. Essa lista é a área real da reconstrução, e costuma ser bem menor do que a contagem de telas sugere, porque boa parte das telas é variação das mesmas poucas operações. A diferença aparece rápido quando você conta. Imagine um app de operação com sessenta páginas, número grande o bastante para travar a conversa. Contar a lógica embaixo dele normalmente revela uma fração disso em workflows, um punhado de integrações e uma lista curta de papéis. Você escopa contra os workflows. As páginas viram tarefa de design, e design é barato perto de lógica que precisa ser raciocinada duas vezes. É também a hora de decidir o que não reconstruir. Sistema que cresceu dentro de editor visual acumula workflow que existe porque alguém precisou uma vez. Migrar é a licença rara para apagar. ## Como é a migração na prática? Ela roda em sequência. Acertar essa ordem importa mais do que qual stack você escolhe no fim. Exporte e modele os dados primeiro. O CSV e a API entregam os registros, mas registro não é esquema. O que chega é a estrutura de dados do Bubble, e reconstruí-la igual importa as restrições das quais você queria escapar. Três perguntas separam o modelo real dos seus acidentes. Quais campos existem porque o negócio precisa, e quais existem porque um workflow precisava de um lugar para guardar um valor? Quais listas deveriam ser relacionamentos? Quais option sets viraram, na prática, uma tabela? Responder isso antes de escrever qualquer esquema é a decisão de cauda mais longa, porque tudo construído depois herda a resposta. Depois reconstrua a lógica contra o inventário. Rode os dois sistemas em paralelo sobre trabalho real antes de virar a chave, porque as falhas que importam são as que ninguém documentou. 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. As divergências são a especificação que ninguém escreveu. Dois casos nossos mostram formatos diferentes disso. 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 começou a reconstrução em Next.js e Supabase. No [sistema da UniTrust](/cases/unitrust) 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: quanto tempo a operação aguentava enquanto a reconstrução acontecia. O roteiro completo da decisão está em [migrar do Bubble para código](/blog/migrar-do-bubble-para-codigo). ## Perguntas frequentes **Dá para exportar o código-fonte do meu app no Bubble?** Não. A documentação do Bubble afirma que os apps rodam apenas na plataforma e que não há como exportar a aplicação como código. Você exporta seus dados, e o Bubble oferece ajuda para exportar o design, mas a lógica é reconstruída. **Migrar significa reescrever tudo de uma vez?** Não, e fazer assim é o erro mais comum. O padrão mais seguro é reconstruir a lógica contra um inventário, rodar o sistema novo em paralelo com o antigo sobre trabalho real, e virar a chave por workflow em vez de por app. **Meus dados sobrevivem à mudança?** Sim. Essa é a parte bem documentada: exportação em CSV e a API do Bubble alcançam os seus registros. O risco está em outro lugar: levar o modelo de dados antigo intacto e herdar todos os limites que o moldaram. ## O próximo passo Se você está pesando essa decisão e quer uma segunda leitura do seu próprio inventário antes de fechar um plano, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para percorrer isso com você. [Agende uma conversa](/contato).