# Migração da versão WordPress

## Estratégia segura

Não migrar diretamente tabelas WordPress para produção. Criar um processo ETL com quatro fases:

1. exportação do WordPress e dos ficheiros;
2. normalização e validação num staging;
3. importação para tabelas SaaS com mapa de IDs;
4. reconciliação de contagens, hashes e permissões.

## Correspondências principais

| WordPress/SUITE | Digital Dossier Cloud |
|---|---|
| utilizador WordPress | `users` |
| instituição/site | `tenants` |
| associação utilizador/utente | `memberships` e relações verticais |
| utente/cliente | `dossiers` |
| sala/turma | `education_rooms` |
| ficha do utente | `student_profiles` + `guardians` |
| pasta física | `folders` |
| ficheiro e metadados GFC | `documents` |
| logs | `audit_logs` |
| modelo de email | `email_templates` |
| pedido de assinatura | `signature_requests` |
| partilha temporária | `shares` |

## Ficheiros

Para cada ficheiro:

- calcular SHA-256;
- copiar para o storage privado do tenant;
- preservar nome original, MIME, tamanho, datas e autor;
- registar o ID WordPress em `metadata.legacy_id`;
- validar que a soma de ficheiros e bytes coincide com a origem.

## Palavras-passe

Os hashes WordPress não devem ser convertidos para hashes Laravel por SQL. Há duas opções:

- obrigar a redefinição de palavra-passe;
- implementar temporariamente um verificador de hash WordPress que rehasha para Argon/Bcrypt após o primeiro login.

A redefinição é a opção mais simples e previsível.

## Assinaturas pendentes

Migrar o estado e a auditoria, mas emitir novos links. Não reutilizar tokens públicos WordPress na nova plataforma.