O fim de duas plataformas que marcaram minha carreira

Em 2012 eu escrevia código para o SharePoint Server. Em 2019 passei a configurar o Project Online e o PWA como analista funcional de PPM. Ontem, 30 de setembro de 2026, o Project Online foi aposentado. Em julho já tinha sido a vez do SharePoint Server. E eu estava, nos dois casos, do lado de quem desliga.

Não é uma coincidência que me deixa nostálgico. É um marco que vale registrar, porque conta uma história maior que a minha: a de uma geração inteira de soluções corporativas saindo do servidor da empresa para a nuvem, e do código customizado para a plataforma.

Duas datas, não uma

Vale separar os fatos, porque é fácil misturar.

O SharePoint Server 2016 e 2019 tiveram o fim de suporte em 14 de julho de 2026. Quem roda SharePoint on premises nessas versões está hoje sem atualização de segurança, o que na prática empurra a base instalada para o SharePoint Online ou para a Subscription Edition.

O Project Online foi aposentado pela Microsoft em 30 de setembro de 2026. Alguns clientes conseguiram extensão de prazo, e um dos projetos que acompanho, num governo estadual, ganhou fôlego até 2027. Mas para a maioria a data foi ontem. Num projeto que fechamos na véspera, numa indústria nacional de grande porte, a migração terminou dois dias antes do desligamento.

Juntando as duas, 2026 é o ano em que as duas tecnologias sobre as quais construí boa parte da carreira saíram de cena. Não é o fim de uma versão. É o encerramento de um jeito de trabalhar.

A decisão: Planner Premium ou um app próprio

Quando o Project Online tem data para acabar, a primeira pergunta não é técnica. É para onde ir. E na prática ela se resume a dois caminhos: migrar para o Planner Premium, o sucessor que a própria Microsoft indica, ou construir um aplicativo próprio na Power Platform que reproduza o que a empresa usava.

O app próprio seduz. Você modela exatamente os campos que o PMO usa, desenha as telas do jeito que o gerente de projeto gosta, e não depende do roadmap de ninguém. O problema aparece quando você lista o que um cronograma precisa: cálculo de datas a partir de predecessoras, caminho crítico, calendário de dias úteis, linha de base, hierarquia de tarefas resumo que recalcula sozinha. Isso é um motor de agendamento. Construir um do zero é um projeto de anos, e mantê-lo é um custo que nunca acaba.

O Planner Premium já traz esse motor, mantido pela Microsoft, e grava tudo no Dataverse. Isso muda o jogo para relatório e integração: os dados do cronograma passam a morar em tabelas que o Power BI, o Fabric e qualquer fluxo da Power Platform leem nativamente. Num dos projetos, o trabalho de relatório se resumiu a trocar a origem da consulta no Fabric, do Project Online para o Dataverse, mantendo o mesmo formato de saída. Os painéis nem perceberam a mudança.

Por isso a decisão que tomamos nos dois casos foi a mesma, e não foi "um ou outro". Foi dividir: o cronograma vai para o Planner Premium, porque reconstruir motor de agendamento é desperdício. O que o Planner não cobre, como acompanhamento de follow up, orçamento, metadados próprios do PMO, vai para um app na Power Platform e para listas que ficam ao lado.

Não se reconstrói motor de agendamento. Usa-se o que já existe para o cronograma, e constrói-se só o que é próprio do negócio.

O que o Planner Premium não conta na demo

A decisão certa não deixa o caminho fácil. O Planner Premium tem uma particularidade que pega quem vem do mundo de app: os dados estão no Dataverse, você enxerga as tabelas, mas não pode simplesmente escrever nelas.

As tabelas de projeto e tarefa são controladas pelo motor de agendamento. Criar ou alterar tarefa por fora, com um Patch ou um fluxo comum, é bloqueado ou deixa o cronograma inconsistente. A escrita tem que passar pela API de agendamento de projetos, que agrupa as operações num conjunto e deixa o motor recalcular tudo no fim. Isso transforma o script de migração em outra coisa: não é copiar linha de uma base para outra, é reconstruir o cronograma operação por operação, na ordem que o motor aceita.

É daí que vêm os problemas que só aparecem depois da virada. Tarefas que chegaram desaninhadas, fora da hierarquia original. Linhas de base que não bateram com o plano do Project. Predecessoras que não recalcularam as datas como o gerente esperava. Calendário configurado para dias úteis e tarefas caindo em fim de semana. E, por cima de tudo, a expectativa: quem usou Project Online por anos espera o mesmo produto com outra cara, e o Planner Premium é outro produto, com outras regras.

O que de fato se migra num cronograma

Migrar Project Online para Planner Premium parece, de longe, uma troca de ferramenta. De perto é um transplante de estrutura de dados.

Um cronograma não é uma lista de tarefas. É uma hierarquia, com tarefas resumo que contêm subtarefas em vários níveis e uma ordem entre irmãs que carrega significado. Tem vínculos de dependência. Tem linha de base. O Project modelava tudo isso de um jeito; o Planner Premium modela de outro. A migração vive ou morre na fidelidade dessa tradução.

Na indústria, a varredura do que tinha sido migrado mostrou o tamanho do problema. Milhares de tarefas ficaram com o pai divergente, penduradas no lugar errado da árvore. Centenas de vínculos não sobreviveram. Quase duas mil tarefas inativas no original chegaram como se fossem trabalho real.

Nenhum desses números aparece numa demo. Eles aparecem quando você exporta a base dos dois lados, antes e depois, e compara linha a linha. Foi o que fizemos: extração do estado original, extração do estado migrado, e uma análise apontando cada tarefa fora do lugar, cada vínculo perdido, cada inativa tratada como ativa.

A correção religou a maior parte das tarefas automaticamente. Sobrou um resto que exigiu decisão caso a caso, porque usuários tinham reorganizado tarefas no meio do caminho, e aí não existe regra. Teve ainda a ordem entre irmãs, embaralhada em centenas de pontos. É o tipo de detalhe que ninguém especifica num requisito e que todo gerente de projeto percebe no primeiro dia.

O SharePoint no fundo, em sincronia

Há uma parte do PWA que o Planner Premium simplesmente não recebe. Anos de follow up, orçamentos, anexos, relacionamentos entre projetos, campos que o PMO criou e que viraram parte do processo. Deixar isso para trás não era opção, e enfiar tudo no cronograma também não.

A saída foi manter o SharePoint como camada de fundo. Fluxos do Power Automate extraíram esse histórico do PWA para listas do SharePoint, e passaram a manter essas listas em sincronia com o que vive no Dataverse. O app de follow up, construído na Power Platform, lê e escreve ali. O cronograma fica no Planner Premium; o que é próprio do negócio fica no SharePoint, conectado por sincronia, sem disputar espaço com o motor de agendamento.

Tem uma ironia que eu gosto nisso. O SharePoint que eu programava em 2012 continua lá, só que noutro papel. Deixou de ser a plataforma onde tudo acontecia e virou a base silenciosa que guarda a memória do que aconteceu.

O lado SharePoint da mesma mudança

A saída do SharePoint on premises é o mesmo movimento, com outra cara. Num projeto para um órgão público com dezenas de unidades regionais, o trabalho foi tirar arquivos de servidores locais, aqueles file servers com pastas aninhadas que ninguém sabe mais quem criou, e levar para o SharePoint Online e o Teams.

A decisão de arquitetura ali foi respeitar o modelo mental de quem usava. Cada regional ganhou um site hub replicando a estrutura do antigo servidor de arquivos, com visual padronizado. Poderia ter sido a oportunidade de reinventar a organização das pastas. Não foi, de propósito.

Migração e reorganização são dois projetos. Juntar os dois é a forma mais rápida de fazer a nuvem parecer pior que o servidor antigo.

O trabalho técnico veio acompanhado de treinamento, regional por regional, porque a parte difícil da migração de arquivos não é mover o byte. É o momento em que a pessoa abre o Teams pela primeira vez procurando a pasta que ela usava há dez anos.

Por que eu vejo isso como progresso, não como perda

Seria fácil escrever este texto como lamento. Passei anos aprendendo as entranhas dessas plataformas, e vê-las saírem tem algo de estranho. Mas eu discordo da leitura nostálgica, por um motivo concreto.

O que acabou não foi a capacidade. Foi o fardo de operar a capacidade. Manter SharePoint Server significava manter servidor, aplicar patch, planejar failover. Manter Project Online significava uma plataforma de PPM pesada para um uso que, na maioria das empresas, era uma fração do que ela entregava. O que a nuvem e a Power Platform fizeram foi separar o problema de negócio da infraestrutura que antes vinha obrigatoriamente junto.

Quem começou comigo, escrevendo web parts e configurando PWA, teve que decidir uma coisa nos últimos anos: migrar junto com a plataforma, ou ficar especialista numa tecnologia que ia encolher. Eu escolhi migrar, e por isso neste ano estou do lado de quem desliga, não do lado de quem foi desligado.

O que fica, de método

Olhando as migrações lado a lado, o que elas têm em comum não é a tecnologia. É o método.

Escolher o destino pelo que não vale a pena reconstruir. Medir o estado antes e depois com dado, não com opinião. Respeitar a estrutura que as pessoas já conhecem. Guardar a memória do sistema antigo em vez de jogá-la fora. Em todos os casos, a parte que mais consumiu energia não foi a transferência, foi a validação de que o destino era fiel à origem.

Isso não é específico de SharePoint nem de Project. É o que vai valer para a próxima plataforma que a Microsoft aposentar, e vai aposentar outra. Ferramenta tem data de validade. Método, não.

Comecei em 2012 construindo sobre uma plataforma que acabou este ano. Vou terminar a década construindo sobre outra, que também vai acabar um dia. O que carrego de um ciclo para o outro não é o produto. É o jeito de pensar a migração.