A migração do Microsoft Project Online para o ecossistema Microsoft 365 não deve ser tratada como “troca de ferramenta”. Em organizações com PMO maduro, o Project Online costuma ser a espinha dorsal de cronogramas, governança, timesheets, workflows, dados de portfólio e relatórios executivos. Migrar com segurança exige um checklist que preserve três ativos: capacidade, rastreamento histórico e confiança nos dados.
Antes do checklist, o contexto de prazo importa. A Microsoft comunicou o fim de novas vendas para SKUs “Project Online-only” em 1º de outubro de 2025 e a aposentadoria oficial do Project Online em 30 de setembro de 2026. O comunicado também esclarece que Project Desktop não é afetado pela aposentadoria do Project Online.
Diagnóstico rápido: qual é o seu “tipo de Project Online”?
Você só consegue migrar bem quando sabe como a sua instância é usada. Em geral, caímos em 4 padrões:
- Operacional leve: projetos pequenos, poucos campos customizados, pouco uso de PWA/PPM avançado.
- PMO estruturado: EPTs, campos corporativos, governança, relatórios, templates e padronização.
- Cronogramas pesados: projetos com milhares de tarefas, dependências críticas, caminho crítico e baseline.
- Automação e processos: workflows, aprovações, integrações e timesheets como processo central.
Este checklist assume que você quer evitar downgrade de maturidade, mesmo que parte do trabalho migre para ferramentas mais modernas.
Checklist em 8 fases (o que fazer e como validar)
Fase 1 — Inventário do que existe hoje
O erro mais caro é “migrar o que aparece na tela” e esquecer os bastidores. Levante, documente e quantifique:
- Portfólio: número de projetos (ativos, concluídos, arquivados), tipos de projeto, programas, dependências entre projetos.
- Planejamento: tamanho médio dos cronogramas (tarefas), frequência de atualização, uso de baseline, recursos e capacidade.
- Configuração PWA: Enterprise Project Types (EPT), campos corporativos (custom fields), lookup tables, calendários, categorias/grupos de segurança.
- Workflows: aprovações, gates, criação automática de projeto, processos com dependência de estado/fase.
- Timesheets: quem usa, para quê (custo, apontamento real, compliance), integrações com financeiro/ERP.
- Project Sites e documentos: SharePoint associado, bibliotecas, listas, issues/risks (se houver).
- Relatórios: Power BI, OData, extrações, KPIs executivos, relatórios regulatórios.
Critério de “feito”: você consegue responder, em números, “o que eu tenho”, “quem usa”, “para qual decisão” e “o que quebra se eu desligar”.
Fase 2 — Classificação por complexidade e criticidade
Classifique projetos e processos em duas dimensões:
- Complexidade do cronograma: baixo / médio / alto (tarefas, dependências, baseline, recursos).
- Criticidade de governança: baixo / médio / alto (comitês, auditoria, OKRs, priorização, compliance).
Isso evita uma migração “tamanho único” que força projetos complexos para ferramentas de execução simples, gerando retrabalho e perda de previsibilidade.
Critério de “feito”: você tem uma matriz com 4 quadrantes e sabe quais projetos migram primeiro e quais exigem arquitetura híbrida.
Fase 3 — Definição de arquitetura-alvo (o desenho antes da obra)
Aqui você define “quem faz o quê” no novo mundo. O padrão mais resiliente é:
- Planejamento avançado continua onde é forte (ex.: Project Desktop para cronograma robusto)
- Execução/colaboração fica no ecossistema Microsoft 365 (Planner/Teams)
- Governança e portfólio ficam em uma camada de PPM (processo + dados + BI + automação)
- BI e indicadores centralizados (Power BI), com fonte confiável (Dataverse/SQL/serviço)
A própria Microsoft reforça que o Project Desktop não é afetado pela aposentadoria do Project Online e que Planner (incluindo capacidades premium) segue disponível.
Critério de “feito”: existe um diagrama simples (1 página) mostrando ferramentas e responsabilidade por: cronograma, governança, demandas, riscos, indicadores, aprovações, timesheets e histórico.
Fase 4 — Plano de dados: o que será migrado, arquivado e auditável
Divida dados em 3 classes:
- Dados vivos (operacionais): projetos em andamento, backlog, demandas atuais.
- Dados históricos (compliance/consulta): projetos concluídos, lições aprendidas, decisões, baselines antigas.
- Dados de governança: fases, aprovações, documentos, relatórios oficiais.
Atenção: após a aposentadoria, o serviço não estará mais disponível, então o plano de retenção (exportar/armazenar) precisa estar fechado com antecedência.
Critério de “feito”: existe uma política clara de retenção (ex.: 5 anos), com local de armazenamento e método de consulta (ex.: Power BI sobre base histórica).
Fase 5 — Workflows, automações e integrações (onde as migrações falham)
Se você usa workflow para aprovar projetos, criar sites, aplicar templates ou controlar gates, isso precisa ser redesenhado.
No Microsoft 365 moderno, a regra é: processo em Power Platform (Power Automate/Power Apps) + dados em Dataverse/SharePoint + visibilidade em Power BI.
Critério de “feito”: lista de workflows com “equivalente novo” definido e protótipo do processo crítico validado com o PMO (nem que seja em baixa fidelidade).
Fase 6 — Segurança, permissões e governança de acesso
Mapeie e reprojete:
- Quem cria projetos
- Quem aprova
- Quem edita cronograma vs quem só consome dashboards
- Quem acessa histórico e documentos
Evite replicar permissões antigas cegamente. O objetivo é reduzir risco e aumentar clareza.
Critério de “feito”: matriz de papéis e permissões (RACI) e validação com TI/Segurança.
Fase 7 — Piloto controlado (migração sem “big bang”)
O piloto deve representar a realidade: pegue um projeto simples e um complexo, além de um caso com workflow ou timesheet.
O que validar no piloto:
- integridade do cronograma (dependências, baseline, marcos)
- governança (status, gates, aprovações)
- relatórios executivos (KPIs iguais ou melhores)
- experiência do usuário (PM, PMO, liderança)
Critério de “feito”: check de aceite com stakeholders e lista de ajustes antes do rollout.
Fase 8 — Cutover e estabilização (o que ninguém planeja)
O “go-live” não é fim: é início da estabilização. Planeje:
- janela de congelamento (o que muda e quando)
- plano de contingência (rollback ou coexistência temporária)
- suporte dedicado nas primeiras 2–4 semanas
- revisão de métricas (adoção, tempo de atualização, qualidade dos dados)
Critério de “feito”: plano operacional com responsabilidades, datas e métricas de sucesso.
Checklist resumido para colar no seu documento interno
Se você quiser um bloco compacto para usar como “controle de execução”, aqui vai uma versão objetiva:
- Inventário completo (PWA, projetos, workflows, timesheets, sites, relatórios)
- Classificação por complexidade e criticidade
- Arquitetura-alvo definida (cronograma vs governança vs BI)
- Plano de dados (vivo, histórico, governança) + retenção
- Workflows e integrações redesenhados e prototipados
- Segurança e permissões revisadas
- Piloto com casos representativos aprovado
- Cutover + estabilização + métricas de adoção
Faq
Migrar dados é transferir projetos, cronogramas e informações para um novo ambiente. Migrar governança é preservar como o PMO aprova, prioriza, acompanha status, controla fases e mantém rastreabilidade. Na prática, a governança é o que sustenta previsibilidade e decisões executivas, e costuma ser a parte mais crítica da migração.
A abordagem mais segura é migrar por etapas. Um piloto com projetos simples e complexos ajuda a validar cronogramas, relatórios e processos antes do rollout. Isso reduz risco de retrabalho e evita que projetos críticos sejam prejudicados por uma mudança apressada.
Projetos concluídos normalmente devem ser tratados como histórico, com política de retenção definida. Em vez de tentar “recriar” tudo, o ideal é garantir um repositório consultável (por exemplo, base histórica + dashboards), preservando rastreabilidade e evidências para auditoria.
Podem, mas raramente como “cópia fiel”. A prática moderna é redesenhar processos com Power Platform, conectando dados e automações ao Microsoft 365. O importante é preservar o objetivo do workflow (governança), e não o mecanismo antigo.
Uma migração é bem-sucedida quando a organização mantém ou melhora: integridade do cronograma, visibilidade executiva, confiabilidade dos dados, governança e adoção do time. Métricas como taxa de atualização, tempo para gerar relatórios e redução de controles paralelos são sinais claros de sucesso.
