Migrar SharePoint sem parar a operação

Há duas formas de correr uma migração de SharePoint. Uma é escolher um fim de semana, desligar tudo, copiar e rezar. A outra é aceitar que a operação não pode parar, e desenhar a migração à volta desse facto.

Fizemos a segunda em farms globais na Comissão Europeia, na intranet de publicação do Governo irlandês, e em migrações de on-premises para SPFx em clientes Fortune 500. O padrão repete-se sempre.

O que muda quando se olha de outra maneira

A tentação é tratar a migração como um problema de transporte de dados. Também nós a tratámos assim, no início. Não é. É um problema de continuidade.

Os ficheiros acabam sempre por chegar ao destino. O que estraga um projeto é o dia em que alguém abre o portal e não encontra o documento de que precisa naquele momento. Que ele exista noutro sítio é irrelevante: para aquela pessoa, naquele instante, o sistema falhou. E perde-se ali a confiança, que custa muito mais a recuperar do que qualquer ficheiro.

O que fazemos antes de mover um único byte

Inventário a sério. Não é contar sites. É perceber quais estão vivos, quais já ninguém abre há anos, quem é o dono de cada um, e quais têm permissões que ninguém consegue explicar. Uma parte substancial do que se encontra não deve ser migrada: deve ser arquivada ou eliminada. E essa é uma decisão de negócio, não técnica.

Mapa de dependências. Fluxos, formulários, personalizações e integrações que alguém montou há sete anos e que ainda alimentam um relatório que o conselho de administração lê todas as segundas-feiras. É aqui que moram as surpresas.

Decisão sobre o que já lá está. As web parts clássicas não sobrevivem à migração. A pergunta não é como convertê-las, é se vale a pena convertê-las. Muitas vezes a resposta honesta é que não vale.

Migração por ondas, não por big bang

Move-se por grupos com fronteiras claras: uma direção, uma função, um conjunto de sites com o mesmo dono. Durante cada onda, origem e destino coexistem, com a origem em modo de leitura. Se alguma coisa correr mal, ninguém fica sem trabalhar: recua-se uma onda, não o projeto inteiro.

No papel, isto é mais lento. Na prática é muito mais rápido, porque não há paragens que ninguém planeou.

O que se ganha ao fazer assim

Ganha-se o direito de errar em pequeno. Numa migração big bang, o primeiro erro é público, é grande, e chega ao topo da organização no mesmo dia. Por ondas, o primeiro erro afeta trinta pessoas, corrige-se numa manhã, e a onda seguinte já não o repete.

Nada fica ao acaso. É essa a diferença entre uma migração de que se fala pelo resultado e uma de que se fala pelo fim de semana.