Go-live e adoção
Migração de dados e limpeza
Que histórico migra para o Gfacility, o que descarta, o que arquiva — e como valida que tudo aterra corretamente? Salte a limpeza e leva o caos antigo para a casa nova.
Atualizado em 18/05/2026
Go-live · 5.1
Porquê primeiro
Migração e limpeza são inseparáveis. “Migrar tudo” soa seguro — até começar o Gfacility com 14.000 tickets de 2017 cujo estado ninguém já compreende. Importar dados maus torna todos os relatórios pouco fiáveis e todas as sugestões da IA inúteis. Limpe primeiro, depois migre.
O que entrega?
Matriz de migração
Por entidade de origem: entidade-destino, regras de transformação, data de referência, scope.
Lista de ações de limpeza
Duplicados, registos obsoletos, referências partidas — quem limpa o quê antes da migração?
Estratégia de arquivo
O que não migra, e como continua acessível dentro das obrigações de retenção.
Relatório de dry run
Resultado de pelo menos duas execuções de dry run: contagens, discrepâncias, tempo de execução.
As cinco famílias de entidades
A migração segue sempre os mesmos passos, independentemente do sistema-fonte:
Master data
Utilizadores, organizações, localizações, centros de custo. Primeiro, porque todas as outras entidades dependem deles.
Configuração
Classificações, campos personalizados, grupos de trabalho, fluxos de trabalho. Manual ou por exportação — geralmente pouco volume.
Dados transacionais
Tickets abertos, reservas em curso, tarefas planeadas. Volume baixo, valor elevado — leve tudo.
Histórico
Tickets fechados, reservas antigas. Decida que período (12 ou 24 meses) e como preserva a sua linha de reporting.
Base de conhecimento
Artigos, FAQs, modelos. Muitas vezes uma oportunidade para limpar e reestruturar de imediato.
Anexos
Fotos, PDFs, documentos ligados a tickets e ativos. Habitualmente o mais pesado em volume.
Perguntas-chave
- 1Que sistemas-fonte contêm dados que têm de ir para o Gfacility — TOPdesk, ServiceNow, listas Excel, ferramentas internas, recursos do Outlook?
- 2Fronteiras de scope por entidade — só registos ativos, só os últimos 24 meses, só departamentos específicos?
- 3Limpeza antes da migração — quem remove duplicados, desativa utilizadores dormentes, fecha tickets "órfãos" sem dono?
- 4Regras de transformação — como mapeia categorias antigas para novas classificações? O que faz "desconhecido"?
- 5Estratégia de anexos — migrar junto, armazenamento separado, ou ir buscar a pedido ao arquivo?
- 6Data de referência e freeze — quando é que a origem é "congelada" (sem mais alterações) e o que faz com os registos novos que cheguem entretanto?
- 7Validação — que verificações executa depois da migração (totais, amostras, registos-tipo revistos manualmente)?
- 8Solução de arquivo — para os dados que não migram: a ferramenta antiga fica em modo só de leitura? Com que período de retenção, dono e modelo de acesso?
- 9Repetibilidade — consegue fazer dry run da migração pelo menos duas vezes antes do cutover real? Idempotente (re-executar não altera nada)?
- 10Impacto RGPD — leva consigo dados pessoais cujo prazo de retenção já expirou? O DPO verifica antes da migração.
Modelo — Matriz de migração por entidade
| Entidade | Origem | Volume | Scope | Ação de limpeza | Dono | Validação |
|---|---|---|---|---|---|---|
| Utilizadores | Entra ID | ~2.400 | Ativos (login 90d) | Desativar dormentes | IT-Identity | Total +/- 1% |
| Localizações | Excel + M365 Rooms | ~180 | Todas reserváveis | Revalidação de capacidades | FM | Verificação manual 100% |
| Tickets abertos | TOPdesk | ~340 | Todos os abertos | Fechar > 6m | Service Manager | Amostra de 50 |
| Tickets fechados | TOPdesk | ~14.200 | Últimos 24m | Redação PII > 12m | Service Manager + DPO | Totais mensais |
| Histórico de reservas | M365 | ~85.000 | Últimos 12m | Nenhuma — só leitura | Workplace lead | Agregados |
| Artigos KB | Wiki SharePoint | ~220 | Top-150 mais lidos | Reescrever + etiquetar | Service Manager | Revisão de conteúdo |
| … | … | … | … | … | … | … |
Passos
- 1Inventariar os sistemas-fonte e atribuir um responsável por entidade.
- 2Executar sprints de limpeza — duplicados, contas dormentes, mais antigos do que a retenção. Melhor na origem do que durante a migração.
- 3Escrever o mapeamento de transformação: campo de origem → campo Gfacility, com regras explícitas para "desconhecido" e "vazio".
- 4Primeira dry run no ambiente de aceitação, com volume previsto — só para medir contagens, tempo de execução e erros.
- 5Corrigir erros, apertar o mapeamento e devolver à origem as ações de limpeza necessárias.
- 6Segunda dry run com estado de limpeza representativo — utilizadores finais verificam uma amostra.
- 7Acordar a estratégia de arquivo — a origem fica só de leitura durante 12 meses, depois exporta para cold storage.
- 8Entregar relatório go/no-go ao comité de direção: contagens batem, erros < X, sign-off dos donos de entidade.