Migração de Sistemas Legados para Next.js: Estratégia Strangler Fig com Zero-Downtime

Para diretores de tecnologia (CTOs) e gestores de engenharia, poucas decisões são tão aterrorizantes quanto modernizar um sistema legado em produção.

Seja um monólito construído em PHP antigo (versões 5 ou 7), uma aplicação Express desestruturada, ou um sistema desktop em Delphi que atende a operação há duas décadas, o cenário é quase sempre o mesmo:

• O sistema é lento, difícil de manter e repleto de débitos técnicos.
• Novos desenvolvedores se recusam a trabalhar na tecnologia legada.
• Porém, a empresa depende 100% dele para faturar todos os dias.

A reação instintiva de muitas equipes é propor o chamado "Big Bang Rewrite": congelar o sistema atual e passar um ano reescrevendo tudo do zero em uma nova stack. Na prática corporativa, mais de 70% dessas iniciativas falham, estouram o orçamento ou são canceladas no meio do caminho por subestimar regras de negócio obscuras acumuladas ao longo dos anos.

A engenharia de elite não arrisca a sobrevivência do negócio em apostas cegas. Em 2026, a metodologia padrão ouro para migrações corporativas com Zero-Downtime é o padrão Strangler Fig (Estrangulador de Monólitos).

Neste manual de arquitetura, vamos detalhar a estratégia exata para estrangular sistemas legados de forma cirúrgica e progressiva, utilizando Next.js App Router na Vercel e Supabase no backend.

---

1. A Filosofia do Padrão Strangler Fig

O nome é inspirado em figueiras tropicais que germinam nos galhos mais altos de árvores antigas. Com o passar do tempo, as raízes da figueira descem até o solo, envolvem o tronco hospedeiro e gradualmente assumem o seu lugar, até que a árvore original desaparece sem nunca ter sido derrubada abruptamente.

No software, o princípio é idêntico:

1. Nunca desligue o monólito legado no primeiro dia.
2. Posicione uma camada moderna de roteamento (Next.js) à frente do tráfego.
3. Migre uma única tela ou serviço crítico por vez (ex: o novo checkout, a tela de login ou um painel analítico).
4. O tráfego das rotas migradas é atendido pelo Next.js; todas as demais requisições continuam fluindo silenciosamente para o monólito legado.
5. Quando a última rota for portada, o servidor antigo é desativado com risco zero.

                  [ Tráfego dos Usuários (ex: app.empresa.com.br) ]
                                          │
                                          ▼
                   ┌──────────────────────────────────────────────┐
                   │        Next.js App Router (Proxy Edge)       │
                   └───────┬──────────────────────────────┬───────┘
                           │                              │
         Rota migrada? SIM │                              │ NÃO (Rota legada)
                           ▼                              ▼
             ┌───────────────────────────┐  ┌───────────────────────────┐
             │ Next.js Server Components │  │ Servidor Legado Antigo    │
             │   (Nova UI + Supabase)    │  │   (PHP, Node, Delphi API) │
             └───────────────────────────┘  └───────────────────────────┘

---

2. Implementando o Proxy Reverso Nativo no next.config.ts

A maior vantagem do Next.js moderno é a sua capacidade de atuar nativamente como um Proxy Reverso de alta performance através da API de rewrites.

Isso dispensa a configuração de proxies complexos no NGINX ou Cloudflare Workers logo no início. O Next.js recebe todas as requisições no domínio principal e encaminha o que ainda não foi migrado para a URL interna do servidor legado.

Configuração de Proxy no next.config.ts

// next.config.ts
import type { NextConfig } from "next";

const LEGACY_SERVER_URL = process.env.LEGACY_BACKEND_URL 
  || "https://legacy-app.internal.empresa.com.br";

const nextConfig: NextConfig = {
  async rewrites() {
    return {
      // Executado apenas se a rota nao existir nas pastas do App Router
      fallback: [
        {
          source: "/:path*",
          destination: `${LEGACY_SERVER_URL}/:path*`,
        },
      ],
    };
  },
};

export default nextConfig;

Como essa configuração opera na prática?

1. Se o usuário acessa /dashboard e existe uma pasta src/app/dashboard/page.tsx no Next.js, o framework renderiza o Server Component moderno em milissegundos.
2. Se o usuário clica em /faturamento/notas-fiscais (módulo que ainda não foi reescrito), o Next.js busca o conteúdo no servidor legado em background e entrega o HTML/dados ao navegador sob o mesmo domínio.
3. O cliente não vê troca de URL, não é redirecionado para outro subdomínio e a sessão permanece contínua.

---

3. Coexistência de Bancos de Dados: Supabase + Banco Legado

O maior gargalo de migrações é o banco de dados. Se o monólito grava dados em um MySQL ou SQL Server antigo e o novo Next.js grava no Postgres do Supabase, como evitar inconsistências?

Existem duas abordagens de elite:

Abordagem A: Foreign Data Wrappers (FDW)

O Postgres do Supabase possui capacidade nativa de consultar e gravar em tabelas de outros bancos externos (MySQL, SQL Server ou outro Postgres) como se fossem tabelas locais.

-- Conectando o Supabase Postgres ao banco legado MySQL
CREATE EXTENSION IF NOT EXISTS mysql_fdw;

CREATE SERVER legacy_mysql_server
  FOREIGN DATA WRAPPER mysql_fdw
  OPTIONS (host 'mysql.legado.interno', port '3306');

CREATE USER MAPPING FOR postgres
  SERVER legacy_mysql_server
  OPTIONS (username 'migrador', password 'segredo_seguro');

IMPORT FOREIGN SCHEMA legado_db
  FROM SERVER legacy_mysql_server INTO legacy_tables;

Com isso, o Next.js pode consultar dados legados diretamente via SQL moderno no Supabase sem duplicar registros nem criar rotinas de sincronização frágeis. Para detalhes práticos, consulte nosso manual sobre Foreign Data Wrappers no Supabase.

Abordagem B: Dual-Writing com Triggers ou CDC

Para migrações definitivas de esquemas, utiliza-se replicação lógica baseada em logs (Change Data Capture - CDC). Quando um registro muda no sistema legado, uma mensagem é postada e sincronizada com o Postgres, permitindo que a nova aplicação valide os dados em tempo real antes de assumir a escrita principal.

---

4. Autenticação Unificada Durante o Período de Transição

Durante os meses de migração, os colaboradores da sua empresa não podem ser forçados a fazer dois logins diferentes ao navegar entre telas novas e antigas.

A arquitetura recomendada para unificação de sessão:

1. Domínio Base Compartilhado: Garanta que ambos os ambientes rodem sob o mesmo domínio raiz (ex: app.empresa.com.br no Next.js e roteamento interno).
2. Tokens JWT Compartilhados: Configure o monólito legado para emitir ou validar o mesmo token JWT utilizado pelo Supabase Auth.
3. Cookies HTTP-Only: Grave a sessão em um cookie compartilhado com domain=.empresa.com.br; Secure; HttpOnly. Tanto as Server Actions do Next.js quanto os scripts legados têm acesso à mesma credencial para autenticar requisições.

---

5. Rollback em 1 Segundo: A Proteção Financeira da Diretoria

Em migrações do tipo "Big Bang", se um bug crítico paralisar o faturamento no Go-Live, desfazer a implantação leva horas e pode corromper bancos inteiros.

Com o padrão Strangler Fig no Next.js, o rollback é instantâneo:

// Exemplo de controle de Feature Flag no next.config.ts
const USE_NEW_BILLING = process.env.ENABLE_NEW_BILLING_MODULE === "true";

// Se qualquer instabilidade ocorrer no modulo novo:
// 1. Altera a flag no painel da Vercel (Edge Config) para false.
// 2. O Next.js imediatamente volta a encaminhar /billing para o monólito legado.
// 3. Tempo total de recuperacao: menos de 3 segundos.

Essa salvaguarda elimina completamente o estresse das implantações de fim de semana e permite que a equipe técnica lance melhorias em horário comercial com total segurança.

---

Checklist Corporativo para Modernização de Sistemas

Antes de escrever a primeira linha da nova arquitetura, certifique-se de validar os seguintes pontos com a sua liderança:

• Mapeamento de Rotas por Faturamento: Identifique quais módulos geram mais valor e comece pelas telas de maior impacto e menor acoplamento (ex: dashboards e relatórios).
• Configuração de Proxy Reverso: Implemente as regras de rewrites no Next.js para garantir que o monólito antigo responda como fallback transparente.
• Unificação de Cookies de Sessão: Garanta que o token JWT do Supabase Auth transite entre as duas plataformas sem forçar deslogue dos usuários.
• Estratégia de Banco de Dados: Defina se a transição utilizará FDW ou replicação de dados CDC para evitar perda de histórico transacional.
• Plano de Rollback Automatizado: Tenha variáveis de ambiente na Vercel prontas para reverter rotas problemáticas em segundos.

---

Conclusão: Modernização Inteligente é Evolução, Não Loteria

Modernizar softwares corporativos não precisa ser um pesadelo de noites sem dormir ou projetos cancelados.

Ao adotar o Next.js como proxy inteligente e o Supabase como a fundação de dados moderna, a sua empresa transforma um monólito obsoleto em uma arquitetura modular de alta performance, sem parar a operação por um único segundo.

Se a sua diretoria precisa planejar a modernização de um software legado crítico, avaliar a infraestrutura atual ou executar uma migração segura para a nuvem, conheça nossos serviços de modernização de sistemas ou solicite um diagnóstico técnico com nosso time de especialistas.