# Checklist de migração de site

> Use ao planear uma migração de domínio, CMS, estrutura de URLs ou protocolo.

## Preencher antes de executar

- `{{MIGRATION_TYPE}}`
- `{{CURRENT_SETUP}}`
- `{{TARGET_SETUP}}`
- `{{GO_LIVE_DATE}}`
- `{{TEAM_AND_TOOLS}}`

## Prompt

```
Está a produzir um plano de migração de site para SEO.

Tipo de migração: {{MIGRATION_TYPE}}
Configuração atual: {{CURRENT_SETUP}}
Configuração alvo: {{TARGET_SETUP}}
Data de go-live: {{GO_LIVE_DATE}}
Equipa e ferramentas disponíveis: {{TEAM_AND_TOOLS}}

Produza quatro fases: Pré-migração (de agora até ao go-live), Dia do lançamento, Primeiras 72 horas, Semanas 2-8.

Para cada fase devolva uma tabela: Tarefa | Responsável | Porque é que importa | Como verificar que está feita | Bloqueante? (Sim / Não).

Depois acrescente:
- "Baselines a capturar antes de mudar seja o que for" - as exportações e datas exatas necessárias.
- "Gatilhos de rollback" - as medições concretas que justificariam reverter.
- "Coisas habitualmente esquecidas neste tipo de migração" - cinco itens específicos de {{MIGRATION_TYPE}}, não genéricos.

Restrições:
- Todas as tarefas têm de ter um passo de verificação. Uma tarefa sem forma de ser verificada não é uma tarefa.
- Não inclua tarefas irrelevantes para {{MIGRATION_TYPE}}. Uma mudança de protocolo não precisa de refazer o mapa de redirecionamentos se os caminhos não mudarem - diga isso em vez de encher.
- Marque como Bloqueante tudo o que tenha de acontecer antes do code freeze.
- Sem travessões e sem resumo final.
```

## Como obter um resultado melhor

- Nomeie o CMS real dos dois lados: os itens habitualmente esquecidos ficam muito mais específicos.
- Capture as exportações de baseline no mesmo dia em que gera o plano, não na semana do lançamento.
- Acorde os gatilhos de rollback por escrito com o cliente ou stakeholder antes do go-live.

---

Da biblioteca de prompts da QuQi - https://www.quqi.io/pt/prompts/migration-checklist-builder