Go-live e adoção
Runbook de cutover
A viragem propriamente dita — minuto a minuto, com atribuição de papéis, janela de freeze, comunicação e um botão de roll-back explícito. Um bom cutover é entediante; é exatamente esse o objetivo.
Atualizado em 18/05/2026
Go-live · 5.4
Porque é importante agora
O cutover é o momento em que toda a preparação se junta. Improvisar aqui custa dias, não horas. Um bom runbook parece exageradamente detalhado — até alguém às 02h14 da manhã ter de tomar uma decisão sob pressão e o guião lhe dizer exatamente o que fazer.
O que entrega?
Runbook
Guião passo a passo com horas, ações, donos e validações.
Atribuição de papéis e war room
Quem se senta onde, quem liga a quem, war room física ou virtual.
Critérios de roll-back
Que situação dispara o regresso atrás, quem decide, como se faz.
Matriz de comunicação
O que comunica internamente e externamente, quando, por que canal.
Perguntas-chave
- 1Quando — fim de semana, período de férias, sexta à noite? Qual é a janela mais calma com o menor impacto?
- 2Janela de freeze — a partir de que momento já não se podem fazer alterações nos sistemas-fonte? Como é que isso é comunicado?
- 3Atribuição de papéis — cutover lead, tech lead, comunicação, validador de negócio, sponsor de prevenção? Um backup por papel.
- 4Passos — para cada ação: o que faz, quanto tempo demora, quem executa, que verificação valida o sucesso?
- 5Pontos de decisão (gates) — depois de que passos se pode avançar e quais os critérios? Quem assina?
- 6Procedimento de roll-back — descrito concretamente, testado em dry run. Que ações, quanto tempo demora, qual é o ponto sem retorno?
- 7Comunicação — mensagem aos utilizadores antes, página de estado durante, mensagem "está tudo em produção" depois. Por canal e por idioma.
- 8Parceiros externos — consultor de implementação Gfacility, fornecedor IdP, hosting, eventualmente admin do tenant M365: quem está em prevenção, em que linha de escalonamento?
- 9Smoke tests logo após o go-live — que 10-15 cenários executa para ganhar confiança de que funciona?
- 10Segurança — contas de serviço, chaves API, OAuth secrets — quem as detém, como as guarda em segurança durante o fim de semana?
Modelo — Runbook (excerto)
| Hora | Passo | Dono | Validação | Roll-back? |
|---|---|---|---|---|
| Sex 18:00 | Comunicação "início do freeze" | PM | Email enviado, banner intranet | N/A |
| Sex 19:00 | Sistema-fonte em só leitura | Admin da origem | Teste de escrita manual falha | Repor read-write |
| Sex 19:30 | Exportação delta final | Tech lead | Contagens ≥ esperado | Reexecutar script |
| Sex 20:30 | Script de migração em produção | Tech lead | Logs limpos, contagem bate | Restore do snapshot |
| Sex 22:00 | Ativar SSO + integrações | IT-Identity | Login com conta de teste | Rollback da config SSO |
| Sex 23:00 | Smoke tests (15 cenários) | Validadores de negócio | 14/15 PASS | Decisão por cenário |
| Sáb 00:00 | Gate go/no-go 1 | Cutover lead | Sponsor assina | → Roll-back |
| Sáb 09:00 | Champions testam no local | Champions | Registo de issues ≤ 5 P2 | — |
| Dom 18:00 | Comunicação "ao vivo seg 8:00" | PM | Email + Teams + intranet | — |
| Seg 08:00 | Hypercare oficialmente iniciado | Hypercare lead | Hotline aberta | — |
| … | … | … | … | … |
Modelo — Critérios de roll-back
Gatilho 1 — Qualidade de dados
Diferença > 2% nos totais entre origem e destino após migração. Decisão de roll-back em 30 min.
Gatilho 2 — SSO falha
> 5% das contas de teste não consegue fazer login. Roll-back salvo se houver workaround em 60 min.
Gatilho 3 — Smoke tests falham
> 3 em 15 cenários falham. Não passar em qualquer gate go/no-go. Análise do problema + decisão.
Ponto sem retorno
Sábado 12:00 — a partir daí o roll-back já não é viável sem perder o trabalho do fim de semana. Decida antes desse momento.