Migração de Azure SQL para on-premises: BACPAC ou DACPAC?

Para um banco de poucos gigabytes, um único arquivo BACPAC resolve a migração do Azure SQL Database para SQL Server on-premises sem drama. Para um banco de vários terabytes, BACPAC completo tende a ser a escolha errada: o SqlPackage lê todos os dados pela rede antes de conseguir comprimi-los em arquivo, então o tempo de exportação cresce com o volume bruto que precisa atravessar essa rede — e uma falha perto do fim custa a operação inteira de novo, egress incluído. A alternativa mais robusta separa schema (DACPAC) da carga de dados, migrando o volume por um caminho paralelo e incremental.

Essa decisão apareceu de forma concreta ao planejar a migração de um banco de produção do Azure SQL Database com 2,8 TB para SQL Server on-premises. O runbook inicial previa um único BACPAC. A pergunta que motivou a mudança de estratégia foi simples: o que acontece se a exportação falhar às 90% do caminho?

Por que BACPAC completo não escala com o volume

Um BACPAC não é uma cópia binária do banco — é um pacote lógico, gerado lendo os dados através da conexão de rede e comprimindo o resultado localmente. Para bancos pequenos isso é rápido o suficiente para não importar. Para 2,8 TB, o processo pode levar muitas horas, exigir vários terabytes de espaço temporário para o arquivo intermediário e falhar perto do final por qualquer instabilidade de rede, timeout ou espaço em disco — sem produzir nada reaproveitável da execução anterior.

O custo de uma repetição é, na prática, outra operação completa de egress de rede. Isso torna o BACPAC monolítico uma aposta cara justamente no cenário em que ele é mais arriscado: bancos grandes, onde qualquer falha perto do fim é mais provável só pela duração maior da janela de exposição a problemas.

Separar schema e dados muda o cálculo

A alternativa usa dbatools para tratar schema e dados como dois problemas diferentes, cada um com a ferramenta certa.

Primeiro, o schema sai isolado como DACPAC:

Export-DbaDacPackage `  -SqlInstance $AzureSqlServer `  -Database $Database `  -Type Dacpac `  -FilePath "C:\Migration\Database.dacpac" `  -SqlCredential $AzureCred

Depois, é publicado no destino on-premises, criando toda a estrutura sem nenhuma linha de dado:

Publish-DbaDacPackage `  -SqlInstance $TargetServer `  -Database $Database `  -Path "C:\Migration\Database.dacpac"

Os dados seguem por um caminho separado — bcp, Azure Data Factory com self-hosted integration runtime, SSIS, ou scripts por tabela e partição — o que abre espaço para paralelismo controlado e retomada por partição em vez de reiniciar tudo.

A sequência que faz a carga de terabytes funcionar

Para um volume desse tamanho, a ordem das etapas importa tanto quanto a ferramenta escolhida:

1. Criar as tabelas sem índices secundários, triggers ou constraints pesadas — cada um desses elementos multiplica o custo de cada linha inserida.
2. Dividir tabelas grandes por intervalo de chave primária ou por data, permitindo cargas paralelas com limite controlado de concorrência.
3. Criar índices e habilitar constraints só depois que os dados já estão carregados.
4. Atualizar estatísticas.
5. Validar contagens de linha e checksums por tabela — não apenas o total do banco, que pode mascarar uma tabela zerada compensada por outra maior que o esperado.
6. Aplicar uma carga incremental final, curta, para fechar a diferença entre o início da carga e o corte real.

O ponto crítico está no último passo. O DACPAC resolve apenas o schema; o seed inicial de dados pode acontecer com a produção ainda online, mas alguma coisa precisa capturar o que mudou na origem durante essa carga longa — change data capture, change tracking, uma coluna rowversion ou updated_at, replicação por ferramenta externa, ou, no limite, uma janela final de indisponibilidade curta para aplicar o delta. Sem um desses mecanismos, o destino fica consistente com um instante do passado, não com o momento do corte.

Quanto isso custa, na prática

Para uma cópia temporária de 2,8 TB no Azure SQL (General Purpose, região Brasil Sul) seguida de download para on-premises, os componentes que efetivamente geram cobrança são armazenamento da cópia, compute da cópia, e a saída de rede dos dados transferidos:

Somando armazenamento, egress e cada faixa de compute, o total de uma execução de 24 horas fica entre aproximadamente US$ 577 (≈ R$ 2.990) com 8 vCores e US$ 743 (≈ R$ 3.850) com 32 vCores — conversão ilustrativa a R$ 5,18, sem impostos. Se a operação se estender por 48 horas, o total sobe para uma faixa entre US$ 653 e US$ 986, dependendo do compute escolhido para a cópia.

Essas premissas partem de preços públicos de armazenamento em torno de US$ 0,2185/GB/mês na região usada e egress padrão com os primeiros 100 GB gratuitos e cerca de US$ 0,181/GB no restante — valores que mudam por contrato, região e o tempo, então servem como ordem de grandeza para orçar a operação, não como cotação final. Um ponto que vale reforçar: o volume de rede é cobrado pelos dados efetivamente lidos, então não é seguro descontar a compressão do BACPAC do cálculo de egress — o SqlPackage lê os dados brutos pela rede antes de formar o arquivo comprimido.

Para orçamento conservador de uma tentativa de 2,8 TB, um valor em torno de R$ 4 mil cobre a operação com folga — e reforça por que uma segunda tentativa do mesmo BACPAC monolítico, por causa de uma falha perto do fim, é um custo real, não apenas um contratempo operacional.

O risco operacional de rodar em horário de pico

A pergunta natural depois de decidir a estratégia é se alguma dessas etapas pode rodar durante o horário de operação normal. A resposta depende de distinguir dois riscos diferentes: bloqueio direto de tabelas e degradação de recursos.

CREATE DATABASE ... AS COPY OF mantém a produção online e gera uma cópia transacionalmente consistente sem manter lock prolongado sobre as tabelas da aplicação. Inventários e validações, por consultarem majoritariamente catálogos e DMVs, tendem a gerar apenas locks leves e breves. A exportação do BACPAC ou DACPAC acontece a partir da cópia, não da produção, então não bloqueia diretamente as tabelas de origem.

O risco real não é bloqueio — é degradação. Criar a cópia consome CPU, Data IO, Log IO, workers e throughput, o que pode aumentar latência de consulta, throttling, timeouts e o tempo das transações da própria aplicação. Esse risco cresce quando a produção já opera acima de 70–80% dos limites contratados, quando o banco está em um Elastic Pool compartilhado com a cópia, ou quando vários bancos são copiados ao mesmo tempo — o efeito de vizinho barulhento é real num pool compartilhado.

Para reduzir esse risco durante o pico, a cópia deve ficar num banco standalone ou pool isolado, um banco por vez, com escala temporária se necessário, monitorando sys.dm_db_resource_stats, métricas do pool e sys.dm_database_copies — com critério definido para abortar se CPU, Data IO ou Log IO passarem de 80–90%, ou se a latência da aplicação subir de forma perceptível.

Próximo passo

A decisão entre BACPAC completo e DACPAC com carga incremental muda o perfil de risco, o tempo e o custo de uma migração — e vale ser tomada antes de rodar qualquer script, não depois de uma primeira tentativa falhar. Vale também revisar o que faz uma validação de migração aprovar um destino incompleto antes de confiar no relatório final de qualquer uma das duas abordagens.

Para quem está planejando uma migração de Azure SQL para on-premises e quer essa decisão calculada com o ambiente real, a H1 Data oferece um diagnóstico gratuito do ambiente SQL Server: dimensionamento da estratégia de migração, estimativa de custo e janela de risco operacional.