Fim do Release Planner exige rever como sua empresa acompanha novidades Microsoft

A partir de 15 de novembro de 2026, o Release Planner deixa de existir. Esse é o site onde, duas vezes por ano, a Microsoft publicava o conjunto fechado de novidades que chegariam a Dynamics 365, Power Platform e Dataverse na wave seguinte, com datas previstas e a possibilidade de adiar recursos específicos por ambiente. Esse modelo de duas ondas de lançamento por ano acaba. No lugar dele entra o AI at Work roadmap, uma página única e contínua, onde anúncios de novos recursos aparecem à medida que ficam prontos, sem esperar a próxima janela semestral.

Para quem hoje usa o Release Planner como insumo de planejamento de mudanças (revisar o que vem, decidir o que testar primeiro, avisar usuários-chave sobre o que vai mudar), a pergunta prática não é se a mudança é boa ou ruim. É como montar, a partir de novembro, um processo de acompanhamento que não dependia mais de duas datas fixas no calendário.

O que muda de fato

O modelo de release waves tinha uma vantagem operacional clara: previsibilidade. Duas vezes por ano, uma equipe de administração de Power Platform ou de Dynamics 365 sabia exatamente quando revisar a lista de novidades, quando testar em ambiente de sandbox e quando comunicar mudanças para os usuários finais. Esse ciclo virava, na prática, parte do calendário de governança da própria empresa.

O AI at Work roadmap troca essa previsibilidade por continuidade. Os anúncios não têm mais uma data de corte semestral: um recurso pode ser anunciado, entrar em preview e chegar à disponibilidade geral em semanas, fora de qualquer janela fixa. Isso reflete o ritmo real de lançamento de recursos de IA generativa na plataforma, que já vinha acontecendo fora do calendário de release waves havia algum tempo, mas formaliza essa mudança para todo o portfólio de Dynamics 365, Power Platform e Dataverse.

Por que isso pesa mais para quem sustenta ambientes em produção

Nos ambientes que sustentamos para clientes, o valor do calendário de release waves nunca esteve só na novidade em si. Estava em conseguir dizer, com alguma antecedência, “esse recurso muda esse comportamento, vamos testar antes de virar padrão”. Duas vezes por ano, isso cabia numa rotina fixa de revisão. Com anúncios contínuos, a mesma disciplina de revisão precisa acontecer com mais frequência e em intervalos menores, ou corre o risco de um recurso mudar comportamento em produção sem que ninguém tenha percebido a tempo.

Isso é particularmente sensível em recursos habilitados automaticamente. Boa parte das mudanças que chegavam via release wave era opt-in por padrão em muitos tenants, mas parte também vinha habilitada automaticamente, e a Microsoft sempre publicava esse detalhe na documentação da wave. Sem a wave como unidade de referência, encontrar esse detalhe passa a depender de acompanhar o roadmap ativamente, item por item, e não apenas ler um documento consolidado duas vezes por ano.

O que não muda

Vale separar o que é mudança de formato do que é mudança de conteúdo. A Microsoft continua publicando o que vem por vir, continua indicando datas previstas de disponibilidade geral e continua dando visibilidade sobre recursos em preview. O AI at Work roadmap não é uma redução de transparência, é uma mudança na cadência e na estrutura da informação: sai o documento fechado por wave, entra o feed contínuo por recurso.

Também não muda o processo de administração dentro de cada ambiente. Configurações de ambiente, políticas de DLP, controles de acesso e o processo de aprovação para promover mudanças de sandbox para produção continuam exatamente como estavam. O que muda é apenas a fonte de onde a informação sobre novidades futuras é coletada e com que frequência ela precisa ser revisada.

Também continua existindo a possibilidade de adiar a entrada de um recurso específico em determinados ambientes, quando a Microsoft oferece esse controle. O que deixa de existir é o agrupamento desses controles numa única página organizada por wave; cada recurso passa a trazer sua própria informação de disponibilidade e de controle, publicada no momento do próprio anúncio.

O risco de simplesmente ignorar a mudança

O caminho mais fácil, para muitas equipes, é continuar tratando o acompanhamento de novidades como uma tarefa semestral, só que sem mais ter um documento único para consultar nessa data. Esse caminho tende a criar um ponto cego: a equipe segue revisando “a cada seis meses”, só que agora está revisando um roadmap que já recebeu anúncios contínuos ao longo de todo o período, sem que ninguém tenha acompanhado item por item. O efeito prático é descobrir uma mudança de comportamento em produção depois que ela já aconteceu, em vez de antes.

Esse risco é maior em empresas que têm processos críticos de negócio automatizados em Power Automate, aplicações de missão em Power Apps ou processos de venda e atendimento em Dynamics 365, porque são justamente os cenários em que uma mudança de comportamento não avisada com antecedência custa mais caro para corrigir depois.

Há ainda um risco secundário, menos falado: o de comunicação interna. Quando existia uma wave publicada duas vezes por ano, era relativamente simples montar um comunicado único para as áreas de negócio, listando o que vinha por aí. Sem esse documento consolidado, a tentação é parar de comunicar novidades para usuários finais até que algo quebre visivelmente, o que transforma a área de TI de quem avisa mudanças em quem apenas responde a reclamações depois que elas já aconteceram.

Por onde começar

Adaptar o processo de acompanhamento de novidades ao formato contínuo não exige reconstruir a governança do zero. Também não exige contratar uma ferramenta de monitoramento externa antes de tentar resolver o problema com o que já existe internamente. Três ajustes cobrem a maior parte do problema:

• Troque a revisão semestral por uma revisão recorrente mais curta (mensal, por exemplo), dedicada especificamente a checar o que foi publicado no AI at Work roadmap desde a última revisão.
• Separe, nessa revisão, os itens que afetam ambientes de produção diretamente daqueles que são apenas novidades de interesse geral; nem todo anúncio exige ação imediata.
• Documente, para cada recurso relevante identificado, se a habilitação é automática ou depende de ação manual, e registre isso num controle simples que a equipe de administração já usa (uma planilha ou um quadro já resolve).

Nenhum desses passos depende de ferramenta nova. Depende de decidir, agora, que a revisão de novidades vai acontecer com outra frequência, antes que o hábito antigo de “duas vezes por ano” continue por inércia sem que exista mais o documento que sustentava esse hábito.

Uma mudança de processo, não só de site

A aposentadoria do Release Planner é, na superfície, a troca de um site por outro. Na prática, é uma mudança na forma como qualquer empresa que depende de Dynamics 365, Power Platform ou Dataverse precisa organizar o acompanhamento de novidades da plataforma. Quem trata isso como só uma questão de onde consultar a lista de recursos tende a manter a rotina antiga e perder a vantagem real da mudança, que é saber de uma novidade relevante semanas antes, em vez de meses depois.

Se sua empresa quer revisar como o acompanhamento de novidades da Microsoft está estruturado hoje e ajustar esse processo para o modelo contínuo, um especialista da S4R pode ajudar a montar essa rotina dentro da operação de sustentação já existente.