Esta semana em cloud (31/ago–06/set): a migração saiu da madrugada e virou pipeline

Q: Validar schema antes de provisionar o destino muda tanto assim?

Muda o custo do 'não'. No desenho antigo, você descobria incompatibilidade depois de criar o ambiente de destino, consumir capacidade e já ter vendido a data internamente — o que transforma cada bloqueio técnico em negociação política. O Fabric Migration Assistant inverte isso: você sobe um DACPAC do banco de origem, recebe o relatório de compatibilidade com objetos que falham, o motivo de cada falha e a cadeia de dependências, e nada é provisionado nem cobrado enquanto avalia. Na prática, dá para validar vários bancos candidatos em uma tarde e sequenciar os mais fáceis primeiro. A conversa com o comitê de mudança passa a ser feita com evidência em vez de estimativa.

Banner - Esta semana em cloud (31/ago–06/set): a migração saiu da madrugada e virou pipeline

TL;DR — O Fabric ganhou validação de schema antes de provisionar o destino, o Azure Repos ganhou sincronização contínua com cutover de 30 minutos, o Power BI abriu janela de opt-in para trocar ODBC por ADBC e o Kubernetes 1.37 habilitou Storage Version Migration por padrão. Quatro fornecedores, o mesmo desenho: validar antes, sincronizar durante, cortar rápido. E dois relógios já marcados para 2027: o fim das vendas do BizTalk e o desligamento do ODBC.

A semana passada foi sobre o preço da capacidade. Esta foi sobre uma palavra que ninguém coloca no roadmap com orgulho: migração.

Não foi um anúncio. Foram sete, de quatro organizações diferentes, entre segunda e sexta — e todos com a mesma forma. A Microsoft levou a GA o assistente que valida schema antes de criar o banco de destino, colocou em preview a migração de repositórios que sincroniza enquanto o time trabalha, e abriu a janela de validação para trocar o driver dos conectores de dados. O Google publicou como automatizou dual-write para o Spanner. A CNCF publicou como tirar um serviço crítico do namespace default sem parar nada. E o Kubernetes 1.37 ligou por padrão a API que reescreve objetos armazenados depois de uma mudança de versão.

Nenhum deles é sobre a mesma tecnologia. Todos são sobre a mesma mudança de desenho: a migração deixou de ser um evento de madrugada e virou um pipeline com etapas nomeadas — validar, sincronizar, cortar.

Por que quatro fornecedores lançaram a mesma coisa na mesma semana?

Porque o relógio venceu para todo mundo ao mesmo tempo, e ele não é seu.

Na segunda-feira a Microsoft anunciou que o BizTalk Server 2020 é a última versão da linha e que a compra de novas licenças se encerra em 31 de março de 2027. Não é desligamento — o suporte mainstream vai até abril de 2028, com extensão paga depois. É algo mais desconfortável: a confirmação de que o produto não tem futuro, entregue a uma base instalada que no Brasil ainda sustenta faturamento, EDI e integração bancária em empresas grandes.

No mesmo bloco de dias veio a transição de ODBC para ADBC nos conectores do Power BI e do Fabric — Snowflake, BigQuery, Databricks, Spark, Impala, Dremio. E aqui o desenho é explícito, com dois eventos separados no calendário:

Evento	Quando	O que acontece
Ativação padrão	Segundo semestre de 2026	ADBC vira o driver de novas conexões. Modelos, dataflows e relatórios existentes continuam em ODBC até serem editados.
Corte	Início de 2027	ODBC é desabilitado no serviço. Todas as conexões passam a ADBC. Não há opt-out por tenant.

O espaço entre as duas linhas dessa tabela é a coisa mais importante que a Microsoft entregou nesta semana. Ele existe para uma finalidade só: você validar em produção, com opt-in por conexão, enquanto o resto do parque continua rodando no driver antigo. É a diferença entre descobrir que um refresh quebrou numa terça de validação e descobrir no fechamento contábil.

O padrão se repete no Enterprise Live Migrations, que entrou em preview pública para levar repositórios do Azure Repos para o GitHub Enterprise Cloud com data residency. O fluxo tem três etapas — Validate, Synchronize, Cut over — e a sincronização é contínua: o time segue commitando no Azure Repos enquanto os dados já estão sendo replicados. O corte final fica em menos de 30 minutos para a maioria dos repositórios. A própria documentação é honesta sobre o escopo: migra repositório, histórico, branches, tags, políticas de branch (convertidas em rulesets) e metadados de pull request; não migra work items, definições de pipeline, releases, wikis nem Azure Artifacts. E o suporte é apenas para GHE.com — quem está no github.com padrão fica de fora nesta preview.

Essa honestidade sobre o que não é migrado é parte do mesmo movimento. Migração parcial declarada é melhor que migração total prometida.

O que muda quando a validação vem antes do provisionamento?

Muda quem paga pela surpresa.

O Fabric Migration Assistant para SQL database chegou a GA com uma função que parece burocrática e não é: Validate. Você exporta um DACPAC do SQL Server de origem, sobe no assistente, e recebe o quadro de compatibilidade antes de existir qualquer banco de destino — quais objetos de schema implantam limpos, quais usam recursos não suportados, o motivo de cada falha e a cadeia de dependências entre eles. Nada é provisionado, nenhuma capacidade é consumida enquanto você avalia.

A frase do anúncio que resume a mudança é boa demais para parafrasear: "a migração só começa quando você já sabe como vai terminar".

Quem já conduziu migração de banco em empresa grande sabe por que isso importa, e não é pelo tempo economizado. No desenho antigo, a ordem era: aprovar o projeto, provisionar o destino, começar a implantar, então descobrir a incompatibilidade. Nesse ponto a data já foi comunicada, o orçamento já foi consumido e cada bloqueio técnico vira negociação política. Antecipar a validação transforma o relatório de incompatibilidade de má notícia em insumo de planejamento — dá para escopar esforço, entregar uma lista concreta de remediação a quem opera o sistema de origem e entrar no comitê de mudança com evidência, não com estimativa.

O mesmo desenho aparece no processo de migração de modelos publicado para o Microsoft Foundry e o Azure OpenAI: seis fases — Discover, Assess, Adapt, Validate, Roll out, Retire — com o alerta de que Adapt e Validate consomem o grosso do tempo, porque o risco real não é técnico, é comportamental. Trocar um modelo por outro mais novo não quebra a chamada de API; quebra o prompt que dependia de uma peculiaridade do modelo antigo, silenciosamente, em produção.

Tem um parque legado com data de validade marcada? A Nuvem Online planeja e executa a migração com validação antes do corte.

E quando não existe ferramenta pronta para o seu caso?

Aí o padrão continua valendo — só que você implementa na mão. E dois textos desta semana mostram como.

O primeiro é o relato publicado na CNCF sobre migrar um deployment crítico para fora do namespace default sem downtime. O problema é banal e universal: um serviço de autenticação nasceu no default anos atrás, e hoje ninguém sabe exatamente quem o chama pelo nome curto. A solução não foi coordenar um cutover entre times — foi criar um Service do tipo ExternalName no namespace antigo, apontando por CNAME para o novo. O nome antigo continua resolvendo; cada consumidor migra a referência quando puder. Para o ingress, uma exceção temporária e explícita na política do OPA permitiu a sobreposição controlada dos dois caminhos.

É a mesma ideia do Synchronize do ELM, do opt-in por conexão do ADBC e do dual-write: manter os dois endereços válidos ao mesmo tempo, e transformar o corte numa decisão reversível.

O segundo é o time de engenharia financeira do Google contando como automatizou a migração de mais de 30 DAOs para o Spanner com dual-write. O detalhe interessante não é o uso de CLI de IA em modo headless — é o que eles fizeram com ele: trataram os prompts como artefatos versionados no repositório, com validação automática de paridade de dados entre a escrita antiga e a nova. Migração que roda em pipeline precisa ser auditável como pipeline. Prompt em histórico de chat não é.

E o terceiro veio do próprio Kubernetes. A versão 1.37 promoveu a StorageVersionMigration (storagemigration.k8s.io/v1) a estável e a habilitou por padrão em todos os clusters. A função é reescrever objetos já armazenados quando a versão de storage preferida muda — de v1beta1 para v1, tipicamente após um upgrade de API — e também re-gravar dados depois de uma troca de chave de criptografia em repouso. Antes disso, a saída era script de kubectl get | kubectl replace ou o migrador out-of-tree: tedioso, propenso a erro e difícil de monitorar.

Vale reparar no que aconteceu ali. O Kubernetes olhou para uma tarefa de migração que todo administrador fazia na unha, e a absorveu como controlador do control plane, ligado por padrão. É a definição operacional de "virou rotina".

O que isso significa para quem opera infra no Brasil?

Três consequências práticas, em ordem de urgência.

1. O inventário é a parte que você pode começar hoje. Todas as ferramentas desta semana pressupõem que você sabe o que tem e quem consome. O Validate do Fabric precisa do DACPAC certo; o ExternalName precisa da lista de quem chama o nome antigo; o dual-write precisa saber quais caminhos de escrita existem. Na prática, o gargalo de migração raramente é a execução — é descobrir que existe um host atrás de um Ingress que ninguém documentou, rodando uma versão de runtime que ninguém sabe precisar. Esse trabalho não depende de licença, de orçamento nem de aprovação. Depende de alguém sentar e mapear.

2. Contrato implícito é o que quebra em silêncio. O caso do modelo de linguagem que muda de comportamento sem quebrar a API é o mesmo caso da regra de nomenclatura que vivia num sistema legado e some quando a origem do dado muda: tudo continua respondendo 200, e o valor está errado. Migração de conector, de banco, de modelo e de gateway compartilham esse risco. A defesa é a mesma nos quatro casos — um teste de paridade que compara saída velha e nova com dado real, rodando durante a janela de sobreposição. Se a sua janela de sobreposição é de zero minuto, você não tem onde rodar esse teste.

3. Fim de vida é decisão de arquitetura, não de compras. O anúncio do BizTalk é o exemplo do ano, mas o padrão é recorrente — foi assim quando o nginx-ingress foi descontinuado e o Gateway API virou o caminho padrão, e será assim na próxima. A pergunta útil não é "quando o suporte acaba", é "o que eu ganho de portabilidade na saída". Migrar BizTalk para um conjunto de serviços gerenciados de um único fornecedor resolve o suporte e mantém o acoplamento; migrar para uma arquitetura de integração baseada em padrões abertos custa mais no primeiro ano e devolve opção de escolha no terceiro. Já discutimos essa aritmética em detalhe no caso de Kubernetes on-premises em infraestrutura estatal.

O que mais aconteceu na semana

Fora do fio da migração, quatro movimentos merecem nota:

OpenTelemetry graduou no CNCF. O projeto entra no mesmo patamar de maturidade de Kubernetes e Prometheus. Na prática, cai o último argumento de risco contra padronizar instrumentação em OTel: a especificação está estável e o suporte dos fornecedores de observabilidade é generalizado.
Kubernetes 1.37 fechou o ciclo do DRA. O suporte a Extended Resources via Dynamic Resource Allocation chegou a GA, depois de três releases em construção — junto com o modo rootless (KubeletInUserNamespace) em beta e o HorizontalPodAutoscaler capaz de escalar até zero réplica. A CNCF publicou o contraponto necessário na sexta: infraestrutura de IA não é problema de GPU, é problema de infraestrutura heterogênea, onde CPU, memória, storage e rede precisam ser orquestrados por etapa do pipeline.
Um ator de ameaça com foco no sistema financeiro brasileiro foi documentado. O Google Threat Intelligence publicou o perfil do BREEZE COMET, com motivação financeira e alvo explícito no Brasil, incluindo o ecossistema de pagamentos instantâneos. Leitura obrigatória para quem opera infra de instituição financeira ou de meios de pagamento aqui.
Rede e perímetro seguiram virando configuração declarativa. O Azure Firewall Explicit Proxy chegou a GA (controle de tráfego outbound sem alterar rota), as Confidential VMs no Azure Linux para AKS ficaram disponíveis e o Windows Server 2025 entrou em GA no AKS. É o tipo de release que não vira manchete e muda o desenho do próximo cluster.

Perguntas Frequentes

Por que tanta ferramenta de migração apareceu na mesma semana?
Porque o calendário de fim de vida de uma geração inteira de produtos venceu ao mesmo tempo. O BizTalk Server 2020 é a última versão da linha e para de ser vendido em 31 de março de 2027; os drivers ODBC embarcados nos conectores do Power BI e do Fabric são desligados no início de 2027; o Azure Repos perdeu tração para o GitHub. Quando o relógio é do fornecedor e não seu, ele precisa reduzir o atrito da saída — senão a migração vira motivo para avaliar o concorrente. O efeito colateral é bom para quem opera: ferramentas que antes eram consultoria paga viraram recurso de plataforma. O que não mudou é quem responde pelo risco do cutover.

Validar schema antes de provisionar o destino muda tanto assim?
Muda o custo do "não". No desenho antigo, você descobria incompatibilidade depois de criar o ambiente de destino, consumir capacidade e já ter vendido a data internamente — o que transforma cada bloqueio técnico em negociação política. O Fabric Migration Assistant inverte isso: você sobe um DACPAC do banco de origem, recebe o relatório de compatibilidade com objetos que falham, o motivo de cada falha e a cadeia de dependências, e nada é provisionado nem cobrado enquanto avalia. Na prática, dá para validar vários bancos candidatos em uma tarde e sequenciar os mais fáceis primeiro. A conversa com o comitê de mudança passa a ser feita com evidência em vez de estimativa.

Dá para migrar sem downtime quando não existe ferramenta pronta para o meu caso?
Dá, e o padrão é o mesmo das ferramentas: manter os dois endereços válidos ao mesmo tempo e cortar depois. O relato publicado na CNCF sobre tirar um serviço crítico do namespace default usa um Service do tipo ExternalName como ponte de DNS — o nome antigo continua resolvendo para o novo destino, e cada time consumidor migra a referência no próprio ritmo, sem janela coordenada. O mesmo raciocínio vale para banco (dual-write com validação de paridade), para conector (opt-in por conexão) e para API. O que torna isso viável não é a ferramenta, é ter inventário: saber quem chama o quê. Sem esse mapa, qualquer cutover é aposta.

Tenho BizTalk rodando. Quanto tempo eu realmente tenho?
Mais do que a manchete sugere, mas menos do que o projeto exige. O fim das vendas em março de 2027 não desliga nada do que já está licenciado — o suporte mainstream segue até abril de 2028, com suporte estendido pago disponível depois disso. O problema é a aritmética do outro lado: migração de integração corporativa costuma levar de 18 a 24 meses, porque o trabalho não é reescrever orquestrações e sim redescobrir regras de negócio que só existem dentro delas. Contando para trás a partir de 2028, quem ainda não começou o inventário está atrasado. E o inventário é justamente a parte que não depende de licença nem de aprovação de orçamento — dá para começar nesta semana.

Fontes: