A Microsoft vem acelerando a modernização das ferramentas de migração para o Azure — e a aposentadoria do Data Migration Assistant (DMA) marca oficialmente essa transição. Se antes o DMA era a porta de entrada para avaliações de compatibilidade e migrações iniciais, agora o futuro está na experiência integrada e automatizada do Azure Database Migration Service (DMS) com Integration Runtime (IR).

🔄 O que muda com o fim do DMA?

O DMA cumpriu bem o papel de identificar problemas de compatibilidade e realizar pequenas migrações offline. Porém, ele exigia muito trabalho manual e não atendia com eficiência cenários corporativos modernos, como migrações contínuas e em grande escala.

Agora, com o Azure DMS, temos:
✔️ Processos online ou offline
✔️ Automação fim a fim
✔️ Monitoramento em tempo real
✔️ Redução de downtime
✔️ Suporte a grandes ambientes e workloads críticos

O Integration Runtime se torna peça-chave nessa evolução, pois atua como uma ponte segura entre o ambiente local e a nuvem — garantindo performance, conectividade híbrida e proteção de dados em trânsito.

Por que o Integration Runtime faz a diferença?

O Self-hosted Integration Runtime permite migrar bases de dados que não podem ficar expostas diretamente à internet, mantendo:

🔐 Conexões seguras com rede interna
⚙️ Alta disponibilidade local
🚀 Melhor throughput de migração
🛡️ Conformidade com políticas corporativas

📌 Benefícios práticos dessa nova abordagem

Antes (DMA)	Agora (DMS + IR)
Avaliação manual + migração parcial	Pipeline completo de migração
Suporte limitado a online migrations	Online, com mínimo downtime
Falta de automação e governança	Observabilidade, logs e controle
Sem escalabilidade corporativa	Suporte a grandes bancos e múltiplos servidores

📌 Vamos para o mão na massa de uma base de dados simples para entender o processo.

No Azure, busque por Azure Data Migration Service e crie um novo projeto de migração

Segue selecionando o cenário e tipo recursos de database de origem e destino

Vamos criar o serviço de migração de dados e alocá-lo em um resource group, atribuindo um nome ao serviço, que aqui chamo de MigrationDbEstudo. DbEstudo é uma base de dados em SQL que criei para realizar este laboratório. Clique em Review e Create para criar o recurso no Azure.

Serviço será criado como mostra a tela a seguir:

📌 Base de dados SQL Server.

Criei uma instância de banco de dados, conforme a imagem em anexo. Como a criação de um servidor SQL não é o foco deste laboratório, deixo apenas o script para criação da base para testes.

O scrit cria uma base de dados chamada de EstudoDB. Estou utilizando um servidor Windows Server 2016 com SQL Data Base 2017.

https://github.com/ErickMedeiros/scriptSQLDb_Estudo

📌 Base de dados Azure SQL Database.

Criei uma instância de base de dados no Azure SQL Database com o mesmo da instância Local, EstudoDB.

📌 Configuração do serviço no servidor:

stou autenticado no Azure e agora dentro do servidor, origem da base de dados que será migrada para o Azure SQL Database por meio do Azure Database Migration Service. Vamos da inicio ao processo de Migração clicando na opção Start Migration.

O cenário utilizado será o de migração offline. Esse cenário requer o self-hosted Integration Runtime, que é o foco deste artigo.

Vamos configurar o runtime no servidor.

Vamos realizar primeiro o download da Integration Run time e copiar em um bloco de nota uma das chaves para autenticação

Segue a página para download:

Aqui vou utilizar a última versão disponível.

Após baixar e executar o arquivo msi. Logo a tela exibirá:

Segue o padrão Next, Next, Install

Depois de finalizar a instalação a janela de configuração do Integration Runtime (Sef-hosted)

O próximo passo copiar e colar uma da chaves disponibilizadas e deixamos impressa em nosso bloco de notas. Cola e aguardar o verificador ficar ok, depois clicar em registrar.

Segue a configuração do servidor no Integration Runtime com seu respectivo Node.

Depois é finalizar a configuração para iniciar o processo de integração por alguns minutos.

Ao finalizar a mensagem de registro com sucesso é informada.

Clique em Launch Configuration Manager para visualizar mais informações:

o Azure agora podemos observar o Integration runtime com nosso servidor jpa registrado:

Vamos iniciar nossa migração

Voltamos a janela anteriormente vista mas já com o Integration Runtime instalado e clique em Select

Essa instância de SQL está sendo executada em uma VM no Azure, existe

e colocar os parâmetros de configuração do servidor (instância SQL de origem)

Segue a base dados EstudoDB

Segue a origem e destino das bases.

Migração do Schema e todas as tabelas do banco

Esse é um sumário da Migration onde com todos os paramentos. Estamos prontos para migrar. Vamos iniciar o processo.

Surgirá a janela:

Após finalizar o processo:

Verificando os dados após migração:

Validando os dados:

🎯 Reflexão final

O fim do DMA não representa apenas a aposentadoria de uma ferramenta:
é um marco da evolução das migrações para a nuvem, trazendo mais:

✨ Modernização
🛡️ Segurança
📈 Produtividade
⚡ Performance

Organizações que ainda dependem do DMA devem se adaptar rapidamente para evitar impactos futuros em governança e suporte.

Se você está planejando migrar SQL Server para Azure, o momento é agora — com uma stack moderna e alinhada ao futuro do cloud.

---

💬 Já está utilizando o Azure DMS com Integration Runtime? Como tem sido sua experiência? Vamos trocar ideias nos comentários!