Como migrar do Bubble para código sem perder seus dados

Como migrar seu app do Bubble para React e Supabase sem perder dados: o que dá para levar, o que fazer com as senhas, passo a passo e quanto custa.

Como migrar do Bubble para código sem perder seus dados

Resposta curta: dá para migrar um app do Bubble para código próprio sem perder dados, mas não existe botão de exportar. O Bubble não entrega o código do seu app. Você leva os dados, os arquivos e a lógica de negócio documentada, e reconstrói a aplicação em outra tecnologia. As senhas dos usuários não podem ser exportadas, então todo mundo vai precisar criar uma senha nova ou entrar por link mágico no primeiro acesso.

Este guia mostra quando a migração vale a pena, o que dá e o que não dá para levar, o passo a passo para React + Supabase e os erros que mais custam caro.

Eu fiz essa migração no Instamilhas, um marketplace de negociação de milhas que saiu do Bubble para React e Supabase. Boa parte do que está aqui vem dessa experiência.


Quando vale migrar, e quando não vale

Migrar custa tempo e dinheiro. Não vale a pena só porque código "é melhor". Vale quando o Bubble começa a atrapalhar o negócio.

Sinais de que chegou a hora:

  • A conta mensal ficou imprevisível. O Bubble cobra por workload units, uma medida de quanto processamento o seu app consome. Cada busca, carregamento de página e workflow gasta unidades. Quando o plano estoura, o excedente custa US$ 0,30 a cada mil unidades, e se você desligar o excedente o app pode sair do ar (Jet Admin). Na prática, quanto mais o produto cresce, menos você consegue prever a fatura.
  • O app ficou lento e otimizar consultas no editor visual virou um trabalho maior que o próprio produto.
  • Você precisa de algo que a plataforma não faz bem: integração fiscal brasileira, regra de negócio complexa, processamento pesado em segundo plano, controle fino de permissões.
  • Um investidor ou comprador perguntou sobre o código. Não ter o código-fonte pesa em captação e em venda da empresa.
  • Você depende de plugins de terceiros que podem parar de funcionar a qualquer momento.

Sinais de que ainda não é a hora:

  • O produto ainda não foi validado. Migrar algo que talvez mude completamente no mês que vem é desperdício.
  • A conta do Bubble é baixa e estável, e o app atende bem.
  • Você não tem orçamento para manter um app em código depois. Código próprio exige alguém que saiba mantê-lo.

O que dá e o que não dá para levar

Item Dá para levar? Como
Dados do banco Sim Exportação em CSV por tipo de dado ou via Data API
Arquivos e imagens Sim Baixando a partir das URLs gravadas nos registros
Usuários (nome, e-mail, dados de perfil) Sim Junto com os dados
Senhas dos usuários Não O Bubble não exporta senhas; cada usuário cria uma nova
Código das páginas e workflows Não O Bubble não exporta código; a aplicação é reconstruída
Regras de privacidade Não diretamente Viram políticas de segurança no banco novo
Design Não como arquivo Serve de referência visual para a reconstrução

O ponto que mais surpreende é o das senhas. Não existe forma de levá-las, e mesmo os valores criptografados não ajudariam sem o método que o Bubble usa internamente (fórum do Bubble). Mais abaixo mostro como lidar com isso sem perder usuários.


Por que React + Supabase

Existem vários destinos possíveis. Recomendo React com Supabase para a maioria dos apps que saem do Bubble, por quatro motivos:

  • O Supabase usa PostgreSQL, o banco relacional mais usado do mundo. Seus dados ficam num formato padrão, que você pode levar para qualquer lugar.
  • Autenticação pronta, com e-mail e senha, login com Google e link mágico. Isso resolve a questão das senhas.
  • Armazenamento de arquivos incluído, para receber as imagens e documentos que estavam no Bubble.
  • Segurança por linha (RLS): as regras de "quem pode ver o quê" ficam no próprio banco. É o equivalente às regras de privacidade do Bubble, com controle maior.

Do lado da interface, React com TypeScript é o padrão de mercado. Qualquer desenvolvedor consegue dar manutenção.


O passo a passo da migração

1. Faça o inventário do app

Antes de qualquer código, documente o que existe. Para cada página: o que ela mostra, quem acessa e quais ações estão nela. Para cada workflow: o que dispara, o que faz e o que altera no banco. Liste também os tipos de dados, os campos, os option sets, os plugins e as integrações externas.

Essa é a etapa que mais gente pula e a que mais economiza depois. Workflow esquecido é funcionalidade que some na migração e só é descoberta quando um usuário reclama.

Aproveite para cortar. Toda migração é uma chance de jogar fora a funcionalidade que ninguém usa. Se uma tela não é aberta há meses, ela não precisa ser reconstruída.

2. Modele o banco novo

O banco do Bubble é flexível, e isso cobra seu preço: listas guardadas dentro de campos, dados duplicados, tipos genéricos. Na migração, modele direito:

  • Cada tipo de dado vira uma tabela.
  • Listas dentro de campos viram tabelas de relacionamento.
  • Option sets viram tabelas de apoio ou tipos enumerados.
  • Toda tabela ganha uma coluna com o ID antigo do Bubble (por exemplo, bubble_id). Ela é essencial para religar os registros na importação e para conferir os dados depois.

3. Exporte os dados

O Bubble oferece dois caminhos:

  • CSV pela aba Data: você exporta um tipo de dado por vez. Os registros relacionados aparecem como IDs únicos, então você precisa de todos os CSVs para remontar as relações (RapidDev).
  • Data API: você ativa a API nas configurações e baixa os registros em JSON. Ela retorna no máximo 100 registros por requisição, então é preciso paginar (RapidDev).

Para apps com poucos milhares de registros, o CSV resolve. Para volumes maiores ou para sincronizar várias vezes durante a migração, um script usando a Data API é mais confiável.

4. Transforme e importe

Os dados raramente entram no banco novo do jeito que saíram. Um script de transformação faz o trabalho:

  • converte datas e números para o formato certo;
  • separa as listas em tabelas de relacionamento;
  • troca os IDs do Bubble pelos IDs novos, usando a coluna bubble_id como ponte;
  • corrige o que estava inconsistente: e-mails duplicados, campos vazios obrigatórios, registros órfãos.

Importe primeiro num ambiente de teste e confira as contagens. O número de registros de cada tabela tem que bater com o do Bubble.

5. Leve os arquivos

Imagens e documentos ficam hospedados pelo Bubble, e os registros guardam só a URL. Se você mantiver essas URLs, o app novo continua dependente do Bubble e quebra quando você cancelar a conta.

O certo é baixar cada arquivo, enviar para o armazenamento do Supabase e atualizar a URL no registro. Um script faz isso em lote, usando as URLs que vieram na exportação.

6. Resolva os usuários e as senhas

Como as senhas não vêm junto, você tem três opções:

  • Link mágico no primeiro acesso. O usuário digita o e-mail, recebe um link e entra. Depois disso, define uma senha nova se quiser. É a opção com menos atrito, e é a que costuma ser recomendada por quem já migrou bases grandes (fórum do Bubble).
  • Redefinição de senha obrigatória. Simples de fazer, mas parte dos usuários desiste no caminho.
  • Validar a senha antiga no Bubble durante a transição. Funciona, mas mantém o Bubble ligado e exige cuidado de segurança. Só vale para casos específicos.

Qualquer que seja a escolha, avise os usuários antes. Um e-mail explicando que o sistema mudou e como vai ser o primeiro acesso evita uma enxurrada de chamados no suporte.

7. Reconstrua a lógica

Aqui é onde está a maior parte do trabalho:

  • Páginas viram telas em React.
  • Regras de privacidade viram políticas de segurança por linha no Supabase.
  • Workflows de interface viram funções no front-end.
  • Workflows de backend e agendados viram funções no servidor (Edge Functions) ou rotinas agendadas no banco.
  • Plugins viram integrações diretas com as APIs que eles usavam.

Desenvolvimento assistido por inteligência artificial acelera muito essa etapa. Com o inventário do passo 1 bem feito, cada página e cada workflow vira uma especificação clara do que precisa ser construído.

8. Rode em paralelo e vire a chave

Não desligue o Bubble no dia em que o app novo fica pronto. A sequência segura é:

  1. Coloque o app novo num endereço de teste e use você mesmo por alguns dias.
  2. Faça uma importação final dos dados, com o Bubble em modo somente leitura ou num horário de pouco uso, para não perder nada gravado no meio do caminho.
  3. Aponte o domínio para o app novo.
  4. Mantenha a conta do Bubble ativa por mais um mês, como garantia, antes de cancelar.

Erros que mais custam caro

  • Pular o inventário. É o erro número um. A funcionalidade esquecida aparece depois da virada, com usuário reclamando.
  • Manter as URLs dos arquivos no Bubble. O app funciona até o dia em que a conta é cancelada.
  • Não guardar o ID antigo. Sem ele, religar relacionamentos e conferir os dados vira trabalho manual.
  • Copiar a estrutura do banco do Bubble do jeito que está. Você leva para o código os mesmos problemas de desempenho que o motivaram a sair.
  • Não avisar os usuários sobre o primeiro acesso. A primeira semana vira suporte em vez de produto.
  • Querer adicionar funcionalidades durante a migração. Migre primeiro, evolua depois. Fazer as duas coisas ao mesmo tempo dobra o prazo e o risco.

Quanto custa e quanto tempo leva

Depende principalmente de três fatores: número de telas, quantidade e complexidade dos workflows, e volume de dados.

Como referência, um app pequeno, com até 10 telas e dois perfis de usuário, pode ser reconstruído em cerca de duas semanas. Na V1 Studio, essa reconstrução cabe no MVP em 14 dias, que custa R$ 7.500. Os três primeiros projetos saem por R$ 4.500, em troca de depoimento e autorização para usar o projeto como estudo de caso.

A migração dos dados é orçada à parte, porque o esforço varia muito: alguns milhares de registros limpos levam um dia; centenas de milhares de registros com relacionamentos bagunçados levam bem mais.

Apps maiores, com dezenas de telas, várias integrações e workflows complexos, entram como projeto próprio, normalmente de quatro a dez semanas.


Perguntas frequentes

Dá para exportar o código do meu app do Bubble?

Não. O Bubble não oferece exportação de código-fonte. Você exporta os dados e os arquivos, e a aplicação é reconstruída em outra tecnologia.

Vou perder os dados dos meus usuários?

Não. Nomes, e-mails e todos os dados de perfil podem ser exportados. A única coisa que não pode ser levada são as senhas.

Meus usuários vão ter que criar outra conta?

Não precisam criar outra conta, porque os dados continuam lá. Eles só precisam definir uma senha nova ou entrar por um link mágico enviado ao e-mail no primeiro acesso.

Posso migrar aos poucos?

É possível manter o Bubble funcionando enquanto o app novo é construído e usar uma importação final na virada. Rodar os dois sistemas ao mesmo tempo, com usuários reais nos dois, é mais arriscado e raramente compensa.

Quanto tempo meu app fica fora do ar?

Com uma virada bem planejada, de minutos a poucas horas, normalmente num horário de pouco uso.

Vale migrar para outra ferramenta no-code em vez de código?

Pode valer se o seu problema for só o preço. Mas você troca uma dependência por outra. Migrar para código padrão, como React e PostgreSQL, é a única forma de ter o produto inteiramente sob seu controle.


Quer saber quanto custa migrar o seu app?

Na V1 Studio, o primeiro passo é um diagnóstico gratuito de 30 minutos. Você mostra o app no Bubble, eu digo o que vale reconstruir, o que dá para cortar e quanto custa a migração. Se não for a hora de migrar, eu digo isso também.

Agendar diagnóstico gratuito


Fontes

← Todos os posts

Próximo passo

Sua ideia cabe em duas semanas?

Uma conversa de 30 minutos para avaliar o corte de escopo. Se não couber, isso fica claro antes de você investir.

Agendar diagnóstico