Migração de modelo de dados no Power Pages: o que a GA muda na prática

Nos contratos de sustentação que a S4R mantém, é comum encontrar portais construídos há alguns anos sobre o modelo de dados antigo do Power Pages (o chamado Standard Data Model, ou SDM), rodando sem problemas até o dia em que uma atualização de plataforma ou uma nova funcionalidade exige o modelo mais recente, o Enhanced Data Model (EDM). Até pouco tempo, migrar esse portal de um modelo para o outro era um trabalho manual, arriscado e difícil de testar antes de ir para produção. A Microsoft anunciou a disponibilidade geral (GA) do utilitário de migração de SDM para EDM dentro do Power Platform CLI, agora também com suporte a quatro templates de portal do Dynamics 365.

O que o SDM e o EDM representam na prática

O Standard Data Model foi, por anos, a estrutura padrão de dados usada pelos portais Power Pages (antigo Dynamics 365 Portals) para representar páginas, permissões e conteúdo dentro do Dataverse. O Enhanced Data Model é a evolução dessa estrutura, pensada para se alinhar melhor com os recursos mais recentes da plataforma e com o restante do Power Platform. Sites novos já podem ser provisionados diretamente sobre o EDM desde junho deste ano, mas quem tem um portal mais antigo construído sobre o SDM precisa migrar para continuar recebendo os recursos novos sem limitação.

Essa diferença entre modelo de dados não é um detalhe técnico irrelevante para quem só usa o portal pelo navegador. Ela afeta diretamente a capacidade de evoluir o site mais adiante: funcionalidades recentes de Power Pages passam a ser desenhadas em torno do EDM, e um portal que permanece no SDM corre o risco de ficar progressivamente mais isolado dessas novidades.

Por que a migração manual era um risco

Antes da disponibilidade geral do utilitário, migrar um portal de SDM para EDM dependia de ajustes manuais na estrutura de dados do Dataverse, com alto potencial de erro: um relacionamento mal migrado ou uma permissão de página reconfigurada de forma incorreta podia derrubar partes do portal sem aviso imediato, e o problema só aparecia quando um usuário final tentava acessar uma página específica.

Com o utilitário agora disponível de forma estável no Power Platform CLI, essa migração passa a ser um processo repetível e testável: é possível migrar primeiro um ambiente de homologação, validar que páginas, formulários e permissões continuam funcionando como antes, e só depois aplicar a mesma rotina em produção.

Esse ganho de previsibilidade importa principalmente para quem opera o portal em sustentação, sem o orçamento de um projeto de reconstrução completa. Antes, uma migração de modelo de dados exigia praticamente recriar manualmente a estrutura de permissões e relacionamentos do zero, testando página por página. Com o utilitário maduro, o esforço se concentra em validar o resultado, não em executar a transformação à mão, o que reduz tanto o tempo de projeto quanto a superfície de erro humano.

O que muda com o suporte aos templates de portal do Dynamics 365

A parte mais relevante do anúncio para quem usa casos de uso prontos do Dynamics 365 é que o utilitário passou a suportar quatro templates de portal específicos. Isso significa que empresas que construíram seu portal de atendimento, de parceiros ou de clientes a partir de um desses templates agora conseguem migrar para o EDM sem precisar reconstruir manualmente as customizações feitas sobre o template original.

Antes desse suporte, um portal baseado em template corria o risco de perder parte da estrutura esperada pelo template durante uma migração manual, porque o template pressupõe um conjunto específico de entidades e relacionamentos que nem sempre eram preservados corretamente numa migração feita à mão.

O que dá trabalho e o que pode esperar

Para quem mantém um portal em produção, a pergunta prática é quando migrar, não se vai precisar migrar. Alguns pontos ajudam a decidir o momento certo:

• Se o portal está estável e nenhuma funcionalidade nova do Power Pages está bloqueada por depender do EDM, a migração pode ser planejada com calma, dentro de uma janela de manutenção regular.
• Se o portal já apresenta limitações conhecidas que só se resolvem no modelo novo, ou se há planos de evolução que dependem de recursos recentes, a migração deixa de ser opcional e passa a ser pré-requisito.
• Portais construídos a partir de um dos quatro templates agora suportados têm menos risco na migração do que portais totalmente customizados, que ainda exigem testes mais cuidadosos em homologação.

O que não deveria esperar, independentemente do prazo escolhido para migrar, é o inventário: saber exatamente qual modelo de dados cada portal em produção está usando hoje, e qual template (se algum) serviu de base para ele. Esse levantamento é o que permite decidir com segurança quando migrar, em vez de descobrir o problema no meio de uma atualização de plataforma.

Testar antes de migrar em produção

Mesmo com o utilitário maduro, a recomendação permanece a mesma de qualquer migração de estrutura de dados: rodar primeiro num ambiente que espelhe a produção, validar os cenários de uso mais críticos do portal (login de usuários externos, submissão de formulários, exibição de conteúdo restrito por permissão) e só então aplicar a mudança no ambiente que os clientes finais acessam.

Isso é particularmente importante em portais voltados ao público externo, onde uma falha de permissão não migrada corretamente pode expor conteúdo que deveria ser restrito, ou, no sentido contrário, bloquear o acesso de usuários que deveriam conseguir entrar.

Um roteiro de teste que costuma funcionar bem inclui pelo menos três perfis de usuário diferentes (um visitante anônimo, um usuário autenticado comum e um usuário com permissão administrativa dentro do portal), revisando para cada um se o conteúdo visível depois da migração é exatamente o mesmo visível antes. Diferenças nesse comportamento quase sempre indicam que alguma permissão de página não foi preservada corretamente durante a migração, e é muito mais fácil corrigir isso num ambiente de testes do que depois que usuários reais começam a reportar acesso indevido ou bloqueado.

O custo de deixar a migração para depois

É tentador tratar essa migração como algo que pode ficar indefinidamente na fila de pendências, já que o portal no modelo antigo continua funcionando. O risco não é uma quebra imediata, é o acúmulo de distância entre o que o portal pode fazer hoje e o que a plataforma passa a oferecer como padrão. Cada nova funcionalidade do Power Pages desenhada em torno do EDM que a empresa não consegue adotar é um custo de oportunidade silencioso: a equipe de negócio pede um recurso, a equipe técnica responde que depende de uma migração de modelo de dados ainda não feita, e o pedido fica engavetado.

Com o tempo, esse tipo de pendência tende a se acumular com outras atualizações de plataforma, até o ponto em que a migração deixa de ser uma tarefa pontual e passa a exigir também reconciliar customizações feitas ao longo de vários anos. Planejar a migração enquanto o portal ainda está relativamente simples de testar é, na prática, mais barato do que esperar o cenário se complicar.

Por onde começar

Para quem mantém um ou mais portais Power Pages em produção, o primeiro passo não é rodar o utilitário, é mapear:

• Qual modelo de dados (SDM ou EDM) cada portal está usando hoje.
• Se o portal foi construído a partir de um template de Dynamics 365, e qual dos quatro agora suportados.
• Quais funcionalidades recentes do Power Pages a empresa gostaria de adotar e que dependem do EDM.

Com esse inventário em mãos, a migração em si se torna uma atividade planejada de sustentação, com janela de testes definida, em vez de uma correção de emergência feita sob pressão.

Se a sua empresa mantém portais Power Pages ou Dynamics 365 Portals e não tem certeza de qual modelo de dados está em uso hoje, um especialista da S4R pode ajudar a fazer esse levantamento e planejar a migração com segurança.