Migrar do Drupal para WordPress com um freelancer

Como migrar um site do Drupal para o WordPress com um freelancer: plano de transição de conteúdo e funcionalidades

Migrar do Drupal para o WordPress não é simplesmente transferir páginas. Sites em Drupal costumam depender de tipos de conteúdo, taxonomias, campos, permissões e módulos que não têm equivalentes diretos no WordPress. Se esses detalhes forem ignorados, o novo site pode parecer pronto, mas os filtros de busca podem deixar de funcionar, os créditos dos autores podem desaparecer ou os arquivos de mídia podem se desvincular do conteúdo.

Um freelancer pode gerenciar o trabalho, mas o projeto também exige decisões claras por parte do proprietário do site. Antes de perguntar como migrar um site do Drupal para o WordPress com um freelancer, faça um inventário do conteúdo, identifique as funcionalidades que as pessoas realmente usam e defina como os dois sistemas devem ser diferentes após o lançamento. Para quem pretende contratar freelancer para migração de site, esse planejamento ajuda a transformar uma instrução vaga para “mover tudo” em um plano que pode ser testado.

1. Mapeie os tipos de conteúdo do Drupal para as estruturas do WordPress

Comece listando os tipos de conteúdo do Drupal e os campos associados a cada um. Um artigo de notícias pode conter título, resumo, texto, autor, data de publicação, tema e imagem de destaque. Uma página de produto pode ter outro conjunto de campos e uma relação com uma categoria ou fornecedor. O freelancer precisa desse inventário antes de escolher as estruturas do WordPress; em outras palavras, é preciso mapear conteúdo do Drupal para WordPress de acordo com as necessidades reais do site.

Os nós do Drupal podem ser convertidos em posts ou páginas padrão do WordPress, mas alguns conteúdos merecem um tipo de post personalizado. Por exemplo, um diretório de organizações com arquivo próprio e campos de perfil costuma ficar mais claro como um tipo de post “Organização” do que como um conjunto de páginas comuns. Dependendo do uso, as taxonomias podem se tornar categorias do WordPress ou taxonomias personalizadas. Uma tabela que mapeie cada campo ajuda a deixar essas decisões explícitas.

Não presuma que nomes de campos iguais significam comportamentos iguais. Um campo do Drupal que permite vários valores pode exigir uma configuração diferente no WordPress de um campo que armazena apenas um valor; além disso, uma data armazenada com fuso horário pode exigir uma regra explícita de conversão. Registre exemplos de valores incomuns para que o freelancer possa testá-los, em vez de adivinhar.

Inclua também as URLs no mapeamento. Se um artigo do Drupal estiver atualmente em /news/community-update, decida se o WordPress manterá esse caminho ou o redirecionará para um novo. Uma planilha com o tipo de conteúdo de origem, a estrutura de destino, os campos, as regras de taxonomia e o tratamento das URLs servirá de referência para ambas as partes durante os testes.

2. Decida o que reconstruir, substituir ou deixar para trás

Módulos do Drupal costumam dar suporte a fluxos de trabalho específicos, e copiar apenas a funcionalidade visível não basta se o processo por trás dela for importante. Liste os módulos e as funções personalizadas usados atualmente pelo site e indique quem depende de cada um. Um login para membros, uma fila de aprovação editorial e uma busca facetada podem exigir três soluções diferentes no WordPress.

Classifique cada item em um de três grupos: reconstruir no WordPress, substituir por uma ferramenta disponível ou deixar para trás. Por exemplo, talvez nem seja necessário migrar um calendário de eventos antigo sem eventos futuros. Um diretório público que ainda recebe acessos diários pode precisar de uma alternativa com campos pesquisáveis. Um processo de aprovação personalizado pode exigir desenvolvimento caso a nova configuração editorial não consiga reproduzir as etapas necessárias.

Peça ao freelancer que descreva a solução proposta e suas limitações para cada funcionalidade que será mantida. Se uma substituição mudar quem pode editar o conteúdo ou como os visitantes o encontram, documente essa alteração antes do início do desenvolvimento. “Funciona como no Drupal” não é um critério de aceitação útil; “os editores podem enviar um artigo para revisão sem publicá-lo” é.

Separe as funções essenciais das preferências. Isso ajuda a controlar o escopo quando um módulo do Drupal não tem equivalente direto e dá ao proprietário a oportunidade de aprovar um processo mais simples. Para outras dúvidas sobre a contratação de um profissional autônomo ou de uma equipe, consulte devo contratar um freelancer.

3. Prepare uma amostra representativa para a migração

Antes de transferir o banco de dados inteiro, peça ao freelancer que migre uma pequena amostra com diferentes formatos de conteúdo. Uma página básica testa campos simples e URLs. Um artigo com muitas taxonomias testa as associações de termos e a hierarquia. Um item com bastante mídia testa arquivos de imagem, legendas e conteúdo incorporado. Se o site tiver um tipo de conteúdo especial, inclua pelo menos um exemplo.

A amostra deve ser grande o suficiente para revelar diferentes casos, mas pequena o bastante para que o proprietário ou editor possa revisar cada registro. Combinem quais itens de origem serão usados e o que significa estar “correto” em cada caso. Por exemplo, a amostra de artigo pode precisar manter o autor original, dois termos temáticos, uma data de atualização e um anexo para download.

Compare o resultado no WordPress com o Drupal, e não apenas com uma maquete de design. Verifique se o conteúdo pode ser editado, se os filtros de taxonomia retornam os itens esperados e se a mídia aparece no lugar certo. Uma página pode parecer correta mesmo com termos ausentes do banco de dados. Corrigir o mapeamento após uma amostra sai muito mais barato do que descobrir o mesmo erro em milhares de registros.

Peça ao freelancer que registre os problemas encontrados na amostra e as alterações feitas no mapeamento. Esse registro será a primeira versão das notas de migração e evitará que uma transferência posterior dependa da memória de alguém.

4. Defina regras para a revisão do conteúdo e a transferência para a equipe editorial

A migração não é o momento ideal para tomar decisões editoriais sem registrá-las. Defina com antecedência o que fazer com rascunhos obsoletos, páginas duplicadas, valores de campo não compatíveis e conteúdo marcado para revisão. Uma regra prática pode ser migrar por padrão o conteúdo publicado e manter os rascunhos em uma lista de revisão separada; a escolha exata depende do processo de publicação do site.

É preciso definir quem será responsável por lidar com duplicatas. O freelancer pode sinalizar registros com títulos ou URLs iguais, mas um editor deve decidir se eles serão mesclados, excluídos ou mantidos. Se duas páginas do Drupal tiverem informações diferentes apesar de títulos parecidos, uma limpeza automática poderá remover conteúdo útil. Mantenha um registro das decisões com a URL de origem, a ação escolhida e o editor responsável.

Defina também uma regra para mídia incorporada. Alguns conteúdos do Drupal podem apontar para arquivos armazenados em um local antigo ou incorporar vídeos usando o código de um provedor desatualizado. Decida se o freelancer deve copiar o arquivo, substituir a incorporação ou sinalizar o caso para revisão editorial. Valores de campo incompatíveis devem ser informados, e não descartados sem aviso: a ausência de um valor pode afetar um produto, perfil ou aviso legal.

Defina quem verificará a cópia migrada e como as exceções serão encaminhadas. Por exemplo, o freelancer pode gerar uma planilha com os registros sem imagens, e o editor pode fornecer substituições antes do lançamento. Uma transferência bem definida mantém o trabalho técnico de migração separado da aprovação editorial.

5. Valide os dados migrados além da aparência

Uma revisão visual identifica problemas de layout, mas não confirma se todos os campos e relacionamentos foram transferidos corretamente. Compare os registros do Drupal e do WordPress quanto a títulos, texto, valores de campos, associações de taxonomia, autoria, datas e relações com arquivos de mídia. Escolha verificações adequadas ao modelo de conteúdo do site, em vez de se limitar a revisar a página inicial.

Sempre que possível, use exportações ou consultas ao banco de dados para comparar a quantidade de registros e os campos selecionados. Se houver 240 eventos do Drupal no escopo, o relatório de migração deve contabilizar os registros correspondentes no destino ou listar as exclusões específicas. Não presuma que os números coincidem sem conferir. Se o total final ainda não for conhecido, marque-o para verificação em vez de inventar um número.

Teste também os relacionamentos na interface do WordPress. Abra um arquivo de taxonomia e confirme que um artigo associado a um termo aparece ali. Verifique o arquivo de autores se a autoria for usada na navegação. Abra vários itens com muita mídia e confirme se as imagens ou os anexos estão associados aos registros corretos, e não apenas se os arquivos existem em algum lugar da biblioteca de mídia.

Documente as exceções com detalhes suficientes para que seja possível resolvê-las: identificador de origem, URL de destino, problema, responsável e status. Uma observação como “algumas imagens estão erradas” é difícil de resolver. Indicar o artigo afetado e a imagem ausente dá ao freelancer e ao editor uma tarefa concreta.

6. Planeje a entrada em produção considerando as alterações no conteúdo

O conteúdo pode continuar mudando enquanto o freelancer desenvolve o WordPress. Antes de iniciar a migração, escolha entre congelar o conteúdo ou fazer uma transferência das alterações finais. Com o congelamento, os editores param de publicar no Drupal por um período combinado enquanto a transferência final e as verificações são feitas. Com o processo de alterações finais, o freelancer importa o conteúdo inicial e, depois, transfere os registros criados ou alterados desde então.

O congelamento é mais simples de explicar, mas pode atrapalhar uma redação ou organização com muita atividade. A transferência das alterações finais permite continuar publicando, mas exige um método confiável para identificar registros alterados e evitar duplicatas. Pergunte quem acompanhará as mudanças, quando será feita a última importação e como as atualizações realizadas durante a entrada em produção serão verificadas.

Prepare uma lista de verificação para o lançamento com etapas específicas: importação final concluída, páginas prioritárias revisadas, redirecionamentos testados, formulários enviados com sucesso e responsáveis pelo conteúdo avisados. Se uma etapa crítica falhar, defina se o lançamento será adiado ou se haverá uma solução alternativa aprovada. Essa decisão deve ser tomada antes da pressão do dia do lançamento.

7. Finalize os acessos, a documentação e a preparação para reverter a migração

Na transferência final, confirme que o freelancer entregou os scripts de migração, o mapeamento de campos, o registro de exceções e as instruções para executar qualquer importação final. Peça anotações sobre tipos de post personalizados, taxonomias, tarefas agendadas e etapas manuais necessárias para quem fizer a manutenção no futuro. Sem instruções, pode ser difícil reutilizar um script quando o site precisar de uma correção meses depois.

Revise também os acessos às contas. Remova contas temporárias ou reduza permissões que já não sejam necessárias e troque as credenciais, caso tenham sido compartilhadas durante a migração. Designe uma pessoa responsável pela administração do WordPress para que o site não dependa do login pessoal de um antigo prestador de serviços.

Estar preparado para reverter a migração significa guardar uma cópia do site Drupal que possa ser restaurada e saber quem poderá recuperá-la se houver um problema grave no lançamento do novo site. Defina onde ficará o backup, quem será responsável pela restauração e quais condições acionarão a reversão. Não remova o site antigo só porque o WordPress já está no ar; mantenha-o até que as verificações acordadas sejam aprovadas e a equipe confirme que o conteúdo e os fluxos de trabalho importantes funcionam como esperado.