Como migrar de Azure Synapse para Microsoft Fabric

Migrar do Synapse para o Fabric é reengenharia de plataforma, não upgrade de versão#

Saber como migrar de Azure Synapse para Microsoft Fabric é uma pergunta que chega quase sempre depois de uma reunião com a Microsoft, com um slide dizendo que o Fabric é a evolução natural do Synapse. A parte que o slide não conta é que não existe botão de "atualizar". O Fabric não é o Synapse com uma interface nova: é uma plataforma SaaS diferente, com modelo de capacidade, armazenamento e governança próprios. Migrar significa remontar componentes, reescrever objetos que não têm equivalente direto e provar, número a número, que o novo ambiente entrega o mesmo resultado do antigo.

Isso não quer dizer que a migração seja ruim ou que você deva evitá-la. Quer dizer que ela precisa ser tratada como um projeto de engenharia com fases, testes e critério de saída, e não como uma tarefa de infraestrutura de um fim de semana. Neste artigo eu vou mostrar o mapeamento real de cada componente do Synapse para o Fabric, uma estratégia faseada que já usamos em cliente, como funciona a fase de coexistência que reduz risco, e onde a migração costuma dar errado. Sem romantizar o esforço.

O que muda de fato entre Synapse e Fabric#

O Synapse é um workspace no Azure que junta motores separados: o dedicated SQL pool (o antigo SQL Data Warehouse), os serverless SQL pools, os Apache Spark pools e os pipelines de integração. Cada um tem seu próprio faturamento, sua própria escala e, na prática, seu próprio silo de armazenamento. Você provisiona DWUs para o SQL pool, provisiona nós para o Spark pool, e conecta tudo com pipelines.

O Fabric inverte a lógica. Ele é SaaS, com uma capacidade única (medida em unidades de capacidade, as CUs) que alimenta todas as cargas de trabalho, e um armazenamento único, o OneLake, onde tudo é gravado em formato Delta Lake. Warehouse, Lakehouse, notebooks e pipelines dividem o mesmo lago de dados. Essa unificação é a grande vantagem do Fabric e, ao mesmo tempo, o que obriga a repensar a arquitetura em vez de simplesmente copiar objetos de um lado para o outro.

A tabela abaixo resume a correspondência entre os componentes. Guarde-a: ela é o mapa da migração.

Componente no Azure Synapse	Equivalente no Microsoft Fabric	Nível de esforço
Dedicated SQL pool (data warehouse)	Warehouse (Fabric Data Warehouse)	Médio a alto
Serverless SQL pool (consulta sobre lake)	SQL analytics endpoint do Lakehouse	Baixo a médio
Apache Spark pool	Notebooks Spark do Fabric	Médio
Synapse Pipelines	Data Factory do Fabric (pipelines e Dataflows Gen2)	Médio
Armazenamento em ADLS Gen2	OneLake (Delta) com shortcuts para o ADLS	Baixo
Datasets do Power BI sobre o pool	Modelo semântico com Direct Lake	Baixo a médio

Repare que nenhuma linha diz "esforço nulo". Mesmo o que parece 1 para 1, como o serverless SQL pool virando o endpoint SQL do Lakehouse, exige revalidar permissões, revisar queries e testar performance.

O dedicated SQL pool é o item que mais dá trabalho#

Se existe um componente que decide o cronograma da migração, é o dedicated SQL pool. No Fabric ele mapeia para o Warehouse, que também fala T-SQL e também guarda dados em Delta no OneLake. A boa notícia é que a linguagem é familiar. A má notícia é que o Warehouse do Fabric não é idêntico ao dedicated SQL pool, e as diferenças aparecem justamente nos objetos que empresas mais usam.

O dedicated SQL pool tem recursos de distribuição de dados que o Warehouse do Fabric trata de forma diferente. Comandos e conceitos como CREATE TABLE AS SELECT continuam existindo, mas as opções de distribuição por hash, round-robin e replicated, tão presentes no Synapse, não têm o mesmo controle manual no Fabric, porque o motor gerencia a distribuição de outro jeito. Stored procedures, funções e views geralmente migram bem, mas cada uma precisa ser testada, porque diferenças de suporte a certos tipos de dados, a IDENTITY, a chaves e constraints, e a alguns comandos de DDL vão aparecer.

Na prática, o trabalho aqui é:

1. Inventariar todos os objetos do SQL pool: tabelas, views, procedures, funções e permissões.
2. Reescrever o DDL das tabelas removendo o que não se aplica ao Fabric, como as cláusulas de distribuição.
3. Migrar os dados, idealmente via OneLake, gravando em Delta e evitando cópias intermediárias desnecessárias.
4. Recriar procedures e views, testando cada uma contra o resultado do ambiente antigo.
5. Revisar segurança: usuários, roles e, se houver, segurança em nível de linha precisam ser remapeados para o modelo do Fabric.

Não subestime o passo 4. Uma procedure que roda em segundos no dedicated SQL pool pode se comportar diferente no Warehouse, e ajustar isso é onde o cronograma escorrega. Se o seu ambiente tem centenas de objetos, esse é o núcleo do esforço, e é aqui que uma frente dedicada de engenharia de dados faz diferença entre um projeto de semanas e um de meses.

Spark pools viram notebooks, e essa é a parte mais tranquila#

Quem já usava Spark pools no Synapse tem a transição mais suave. Os notebooks Spark do Fabric rodam o mesmo Apache Spark, com PySpark, Spark SQL e Scala. O código de transformação em si costuma ser aproveitável com poucos ajustes.

O que muda é o entorno. No Synapse você aponta o Spark para o ADLS Gen2 via configuração de linked services e caminhos abfss. No Fabric, os notebooks leem e escrevem no OneLake, que já vem montado no workspace, e o padrão é gravar em tabelas Delta dentro de um Lakehouse. As diferenças aparecem em três frentes: caminhos de arquivo, gerenciamento de bibliotecas e sessões, e a forma de referenciar dados externos, que no Fabric é resolvida com shortcuts do OneLake em vez de montar o storage manualmente. Nada disso é reescrita de lógica, é reconfiguração de plumbing.

Um detalhe honesto: o Fabric gerencia a computação Spark de forma mais automática que o Synapse, o que simplifica a operação, mas tira parte do controle fino sobre tamanho de cluster que alguns times usavam para otimizar custo. Vale conhecer o modelo de capacidade antes de assumir que o comportamento será igual.

Pipelines migram de conceito, mas não por exportar e importar#

Os Synapse Pipelines, que são praticamente o Azure Data Factory embutido no Synapse, mapeiam para o Data Factory do Fabric. A experiência é parecida: as mesmas atividades de Copy, os mesmos conceitos de pipeline, orquestração e triggers. Para transformação de dados no estilo Power Query, o Fabric traz os Dataflows Gen2.

O ponto que gera frustração é a expectativa de exportar os pipelines do Synapse e importar no Fabric intactos. Não é assim que funciona de forma confiável. Conectores, linked services e integration runtimes precisam ser recriados e reconfigurados no Fabric. Pipelines simples de cópia se recriam rápido; pipelines com muita lógica condicional, parâmetros e dependências exigem reconstrução cuidadosa e novo teste ponta a ponta. Se você já tem os pipelines bem documentados, o caminho é mais curto. Para entender a mecânica do Data Factory dentro do Fabric antes de começar, vale olhar como montamos pipelines de dados no Fabric em projetos reais.

Uma estratégia faseada é o que separa migração de aposta#

Migrar tudo de uma vez, no chamado big bang, é a forma mais rápida de perder a confiança da diretoria nos números. A abordagem que recomendamos é faseada, com coexistência planejada. O Synapse e o Fabric convivem por um período, os dois lendo dos mesmos dados quando possível, até que o Fabric prove paridade e assuma a operação.

Fase	Objetivo	Entregável de saída
1. Avaliação e inventário	Mapear objetos, dependências e uso real	Inventário completo e plano de escopo
2. Prova de conceito	Validar um domínio de dados de ponta a ponta no Fabric	Warehouse, notebooks e pipeline de um assunto funcionando
3. Migração incremental	Migrar por domínio de negócio, não tudo junto	Cada domínio validado e em produção no Fabric
4. Coexistência e paridade	Rodar Synapse e Fabric em paralelo e comparar números	Relatório de paridade aprovado
5. Cutover e desligamento	Redirecionar consumo e desativar o Synapse	Synapse desprovisionado, custo cessado

A vantagem de migrar por domínio de negócio, e não por tipo de componente, é que cada domínio entra em produção completo e testável. Você entrega valor cedo, aprende com o primeiro domínio e aplica o aprendizado nos seguintes, em vez de descobrir um problema estrutural só no final, quando já migrou tudo.

O OneLake ajuda muito na coexistência. Como ele centraliza o armazenamento em Delta, você pode usar shortcuts para apontar para dados que ainda estão no ADLS Gen2 do Synapse, sem copiar nada. Isso permite que o Fabric leia dados do ambiente antigo durante a transição, encurtando a janela em que os dois mundos precisam ser mantidos em sincronia manual.

Sem teste de paridade número a número, a migração não terminou#

O critério de "pronto" de uma migração não é o pipeline rodar sem erro. É o número do Fabric bater com o número do Synapse. Essa validação é a parte que menos aparece nos planos e mais protege o projeto.

O teste de paridade compara resultados dos dois ambientes sobre o mesmo período e as mesmas regras. Na prática:

• Selecione um conjunto de consultas e relatórios críticos, aqueles que a diretoria olha.
• Rode a mesma consulta no dedicated SQL pool e no Warehouse do Fabric, com os mesmos filtros.
• Compare totais, granularidade e casos de borda, não só o total geral, porque um erro de junção pode acertar o total e errar a quebra.
• Documente cada divergência, encontre a causa (tipo de dado, regra de negócio implícita, diferença de arredondamento) e resolva antes do cutover.

Divergências vão aparecer, e isso é normal. Diferenças de tratamento de tipos, de conversão de datas e de regras que estavam escondidas em uma procedure antiga são os suspeitos de sempre. O erro é tratar a divergência como detalhe e seguir. Quando um projeto de analytics avançado depende desses números para decisão, paridade não é etapa opcional, é o critério de aceite.

Os riscos que mais derrubam esse tipo de projeto#

Ser honesto sobre o esforço inclui ser honesto sobre onde ele costuma travar. Os riscos mais comuns que vemos:

1. Subestimar a reescrita do SQL pool. A expectativa de que tudo migra por ser T-SQL ignora as diferenças de recursos entre dedicated SQL pool e Warehouse. É o item que mais estoura prazo.
2. Ignorar o modelo de capacidade e custo. O Fabric cobra por CUs de forma diferente do modelo de DWUs do Synapse. Sem dimensionar a capacidade certa, o custo surpreende, para mais ou para menos, e a performance decepciona.
3. Não planejar a governança e a segurança. Permissões, segurança em nível de linha e catalogação precisam ser remapeadas. Migrar dado sem migrar controle de acesso é criar um problema de compliance.
4. Pular a coexistência. Cortar o Synapse antes de o Fabric provar paridade tira a rede de segurança. Se algo der errado no cutover, não há para onde voltar.
5. Tratar como projeto de TI, sem o negócio. Quem valida se o número está certo é a área de negócio. Sem esse aval, o cutover vira campo de batalha de desconfiança.

Nenhum desses riscos é impeditivo. Todos são gerenciáveis com fase de avaliação séria, capacidade dimensionada, e uma janela de coexistência que dê tempo de validar antes de desligar.

Vale a pena migrar agora?#

Depende de onde você está. Se o seu Synapse está estável e sem pressão de custo, não há urgência: migre quando fizer sentido de negócio. Se você está começando um projeto novo de dados, começar direto no Fabric evita a migração inteira. E se o Synapse já mostra limitações, ou se você quer aproveitar o Direct Lake e a unificação do OneLake, a migração se justifica pelo ganho, desde que planejada com fases e paridade. A pior decisão é migrar no susto, sem inventário e sem teste.

Perguntas frequentes#

Existe uma ferramenta automática para migrar do Synapse para o Fabric? A Microsoft oferece assistentes e caminhos de migração que aceleram partes do processo, especialmente cópia de dados e criação de itens no Fabric. Mas não existe um botão que faça a migração completa sozinho. Objetos de código, como stored procedures, views e pipelines com lógica, precisam ser revisados, ajustados e testados por gente que entende as regras de negócio por trás deles.

Quanto tempo leva uma migração de Synapse para Fabric? Não dá para prometer um número honesto sem ver o ambiente. O que define o prazo é o volume de objetos no dedicated SQL pool, a complexidade dos pipelines e a quantidade de regra de negócio escondida em código. Ambientes pequenos e bem documentados são questão de semanas; ambientes grandes, com centenas de procedures e dependências, são projetos de meses conduzidos por domínio.

Posso rodar o Synapse e o Fabric ao mesmo tempo? Sim, e é exatamente o recomendado. A fase de coexistência mantém os dois em paralelo enquanto você valida a paridade dos números. O OneLake facilita isso com shortcuts, permitindo que o Fabric leia dados que ainda estão no ADLS Gen2 do Synapse, sem duplicar armazenamento durante a transição.

Meus notebooks e código Spark vão funcionar no Fabric? Na maior parte, sim. O Fabric roda o mesmo Apache Spark, então a lógica em PySpark, Spark SQL e Scala tende a ser aproveitada. O que muda é a configuração do entorno: caminhos de arquivo passam a apontar para o OneLake, o acesso a dados externos usa shortcuts, e o gerenciamento de bibliotecas e de sessões segue o modelo do Fabric.

O custo do Fabric é menor que o do Synapse? Não é uma resposta de sim ou não. O modelo é diferente: o Fabric usa capacidade única em CUs para todas as cargas, enquanto o Synapse cobra por pool separadamente. Dependendo do seu padrão de uso, o Fabric pode consolidar e simplificar o custo, ou surpreender se a capacidade for mal dimensionada. Dimensionar a capacidade certa faz parte do projeto de migração, não é detalhe posterior.

Preciso migrar meus relatórios de Power BI junto? Os relatórios em si continuam, mas vale revisar a camada de conexão. No Fabric, o Direct Lake permite que o Power BI leia direto do Delta no OneLake, sem importar nem usar DirectQuery, o que muda performance e atualização. Migrar o backend para o Fabric é a oportunidade de repensar o modelo semântico para aproveitar isso, em vez de manter a conexão antiga por inércia.

Conclusão#

Migrar de Azure Synapse para Microsoft Fabric é uma decisão de plataforma que compensa quando é feita com método: inventário, migração por domínio, coexistência e paridade número a número antes do cutover. O esforço é real, concentrado na reescrita do SQL pool e na validação, mas é gerenciável e o ganho de unificação sobre o OneLake justifica quando o momento é certo. O erro caro é subestimar o trabalho e migrar sem rede de segurança.

Se você está avaliando essa migração e quer um plano faseado, com escopo e paridade definidos, fale com a gente. A Fynx já conduziu migrações e projetos de dados de ponta a ponta no ecossistema Microsoft e ajuda a fazer isso sem apagão de números.