Como Migrar um Site Drupal para WordPress: Um Guia Técnico Completo
Migrar do Drupal para o WordPress significa transferir o conteúdo da sua base de dados, ficheiros de media, estrutura de URL e contas de utilizador da arquitetura CMS baseada em entidades do Drupal para o modelo de tipos de publicação do WordPress — sem perder capital de SEO, quebrar links internos ou causar tempo de inatividade. O processo envolve uma importação de conteúdo ao nível da base de dados através do plugin FG Drupal to WordPress, seguida de mapeamento de permalinks, configuração de redirecionamentos 301 e reconstrução do tema.
Este guia abrange todas as fases dessa migração em detalhe técnico preciso: estratégia de backup pré-migração, configuração do ambiente, extração de credenciais da base de dados, importação orientada por plugin, reconciliação da estrutura de URL e validação pós-lançamento. Quer esteja a executar o Drupal 7, 9 ou 10, o fluxo de trabalho abaixo aplica-se.
Por Que Migrar do Drupal para o WordPress
O Drupal é uma framework poderosa, mas a sua complexidade acarreta um custo operacional real. As atualizações de módulos introduzem frequentemente alterações disruptivas, a criação de temas requer conhecimentos de templates Twig, e as edições de conteúdo de rotina exigem envolvimento de programadores. O WordPress, por outro lado, oferece uma curva de aprendizagem mais suave, um ecossistema de plugins muito maior e um custo total de propriedade mais baixo para sites com muito conteúdo que não requerem o controlo de acesso granular ou a modelação de conteúdo complexa do Drupal.
O argumento de desempenho também é relevante. Uma instalação WordPress num ambiente de VPS Hosting devidamente configurado com LiteSpeed, cache de objetos e armazenamento NVMe irá consistentemente superar uma stack Drupal sobrecarregada em infraestrutura partilhada.
Principais motivações de migração por caso de uso:
- Equipas editoriais frustradas com a UX de administração do Drupal e fluxos de trabalho de publicação lentos
- Agências a consolidar sites de clientes numa única CMS gerível
- Programadores a reduzir a sobrecarga de manutenção das cadeias de dependências de módulos do Drupal
- Equipas de SEO que procuram uma integração mais estreita com ferramentas nativas do WordPress como Yoast ou Rank Math
Drupal vs. WordPress: Comparação de Arquitetura
Compreender as diferenças estruturais entre as duas plataformas é essencial antes de começar. Pressupostos incorretos sobre como o conteúdo é armazenado são a principal causa de migrações falhadas ou incompletas.
| Dimensão | Drupal | WordPress |
|---|---|---|
| Modelo de conteúdo | Entidades (nós, termos de taxonomia, campos) | Tipos de publicação (posts, páginas, CPTs) |
| Esquema de base de dados | Altamente normalizado, multi-tabela por tipo de conteúdo | Modelo wp_posts + wp_postmeta simples |
| Roteamento de URL | Aliases de caminho armazenados na tabela path_alias | Regras de reescrita de permalink via .htaccess |
| Motor de temas | Templates Twig + hooks de pré-processamento | Hierarquia de templates PHP + hooks |
| Funções de utilizador | Permissões granulares por função | Hierarquia de funções fixa (Subscritor → Administrador) |
| Gestão de media | Entidade de ficheiros geridos com anexos de campo | Biblioteca de Media com tipo de publicação de anexo |
| Multilíngue | Módulo de Idioma principal | Requer plugin WPML ou Polylang |
| REST API | Módulos principais JSON:API + REST | WP REST API integrada |
| Complexidade de alojamento | Alta (requer Composer, Drush) | Baixa (stack LAMP/LEMP padrão) |
| Ecossistema de plugins/módulos | ~50.000 módulos | ~60.000+ plugins |
A lacuna arquitetural mais crítica é o modelo de entidade de conteúdo. O Drupal armazena parágrafos, campos personalizados e referências de taxonomia em múltiplas tabelas unidas. O plugin FG Drupal to WordPress mapeia estes para meta de publicação e termos de taxonomia do WordPress, mas layouts complexos baseados em parágrafos irão requerer reconstrução manual.
Lista de Verificação Pré-Migração
Antes de tocar em qualquer ambiente, complete todos os itens desta lista. Ignorar passos aqui é a principal causa de perda de dados e tempo de inatividade prolongado.
- Audite o inventário de conteúdo do seu Drupal: tipos de nó, vocabulários de taxonomia, contagem de utilizadores, contagem de ficheiros e tamanho total da base de dados
- Identifique quaisquer módulos Drupal sem equivalente no WordPress (ex.: Rules, lógica complexa de Webform, Commerce)
- Confirme que o seu servidor WordPress cumpre os requisitos mínimos: PHP 8.1+, MySQL 8.0+ ou MariaDB 10.6+, limite de memória PHP de 256 MB
- Decida uma janela de migração — idealmente um período de baixo tráfego
- Ative o modo de manutenção no Drupal durante a passagem final de importação para evitar desvios de conteúdo
- Verifique que o servidor WordPress consegue alcançar o host da base de dados Drupal (mesmo servidor, host remoto ou túnel SSH)
Passo 1: Fazer Backup do Seu Website Drupal
Um backup completo e verificado é inegociável. Precisa tanto do dump da base de dados como do diretório de ficheiros.
Backup da Base de Dados via Drush
Se tiver o Drush instalado (padrão para Drupal 9/10), este é o método mais rápido:
drush sql-dump --result-file=/var/backups/drupal_backup_$(date +%Y%m%d).sql --gzipBackup da Base de Dados via mysqldump
mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gzBackup do Diretório de Ficheiros
tar -czf /var/backups/drupal_files_$(date +%Y%m%d).tar.gz /var/www/html/drupal/sites/default/files/Backup via phpMyAdmin (Método GUI)
- Inicie sessão no phpMyAdmin através do painel de controlo do seu alojamento
- Selecione a base de dados Drupal na barra lateral esquerda
- Clique em Exportar, escolha o método de exportação Rápida, formato SQL
- Clique em Executar para descarregar o ficheiro
.sql
Armazene todos os arquivos de backup fora do servidor — carregue-os para armazenamento remoto ou descarregue-os localmente via SFTP. Um backup que existe apenas no mesmo servidor que o site a ser migrado não é um backup real.
Passo 2: Configurar o WordPress no Seu Servidor de Destino
Instale uma instância limpa do WordPress no seu ambiente de destino. Não importe conteúdo Drupal para um site WordPress existente a menos que tenha planeado explicitamente a fusão de conteúdo — o importador não irá desduplicar.
Requisitos do Servidor
| Requisito | Mínimo | Recomendado |
|---|---|---|
| Versão PHP | 7.4 | 8.2 |
| MySQL/MariaDB | MySQL 5.7 / MariaDB 10.3 | MySQL 8.0 / MariaDB 10.11 |
| Limite de memória PHP | 64 MB | 256 MB |
max_execution_time | 30s | 300s |
upload_max_filesize | 8 MB | 128 MB |
Para sites Drupal de grande dimensão (10.000+ nós, bibliotecas de media com vários GB), um VPS com cPanel dá-lhe acesso direto à configuração PHP, parâmetros de ajuste MySQL e gestão de tarefas cron — tudo o que irá precisar durante uma migração pesada.
Instalação do WordPress via WP-CLI
cd /var/www/html/wordpress
wp core download
wp config create --dbname=wp_database --dbuser=wp_user --dbpass=secure_password --dbhost=localhost
wp core install --url="https://yourdomain.com" --title="Site Title" --admin_user=admin --admin_password=strongpassword --admin_email=admin@yourdomain.comInstalação com Um Clique via cPanel
Se o seu alojamento disponibiliza cPanel, navegue até ao Softaculous Apps Installer, selecione WordPress, preencha as credenciais da base de dados e de administrador, e clique em Instalar. O processo demora menos de dois minutos.
Após a instalação, configure imediatamente estas definições PHP em php.ini ou via .htaccess:
php_value max_execution_time 300
php_value memory_limit 256M
php_value post_max_size 128M
php_value upload_max_filesize 128MPasso 3: Instalar e Configurar o Plugin FG Drupal to WordPress
O plugin FG Drupal to WordPress (versão gratuita disponível; Premium recomendado para sites de grande dimensão) trata da migração ao nível da base de dados de nós, termos de taxonomia, utilizadores e ficheiros de media.
Instalação
- No seu painel de administração WordPress, vá a Plugins > Adicionar Novo
- Pesquise por
FG Drupal to WordPress - Clique em Instalar Agora, depois em Ativar
Em alternativa, instale via WP-CLI:
wp plugin install fg-drupal-to-wp --activateComparação de Funcionalidades Gratuitas vs. Premium
| Funcionalidade | Gratuito | Premium |
|---|---|---|
| Suporte Drupal 6/7 | Sim | Sim |
| Suporte Drupal 8/9/10 | Parcial | Completo |
| Migração de parágrafos | Não | Sim |
| Migração de utilizadores | Não | Sim |
| Migração de Webform | Não | Sim |
| E-commerce (Drupal Commerce) | Não | Sim |
| Conteúdo multilíngue | Não | Sim |
| Suporte prioritário | Não | Sim |
Para qualquer site em produção a executar Drupal 8 ou posterior, a versão Premium vale o custo. Tentar reconstruir manualmente conteúdo baseado em parágrafos é muito mais dispendioso em tempo de programador.
Passo 4: Recolher as Credenciais da Base de Dados Drupal
O plugin FG Drupal to WordPress liga-se diretamente à sua base de dados Drupal. Precisa de quatro valores: nome da base de dados, nome de utilizador, palavra-passe e host.
Encontrar Credenciais no settings.php do Drupal
grep -A 20 "'database'" /var/www/html/drupal/sites/default/settings.phpO resultado irá conter um bloco como este:
$databases['default']['default'] = [
'database' => 'drupal_db_name',
'username' => 'drupal_db_user',
'password' => 'drupal_db_password',
'host' => 'localhost',
'port' => '3306',
'driver' => 'mysql',
];Considerações sobre Acesso Remoto à Base de Dados
Se o WordPress e o Drupal estão em servidores diferentes, a base de dados Drupal deve aceitar ligações remotas. No servidor da base de dados Drupal:
GRANT SELECT ON drupal_database.* TO 'drupal_user'@'wordpress_server_ip' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;Certifique-se também de que a porta 3306 está aberta na firewall apenas para o IP do servidor WordPress — nunca exponha o MySQL a 0.0.0.0.
Se não conseguir abrir uma porta MySQL direta, utilize um túnel SSH:
ssh -L 3307:localhost:3306 user@drupal_server_ip -N -fEm seguida, defina o host da base de dados do plugin para 127.0.0.1 e a porta para 3307.
Passo 5: Executar a Importação de Conteúdo
Navegue até Ferramentas > Importar no seu painel WordPress, desloque-se até à secção Drupal e clique em Executar Importador.
Configuração das Definições do Importador
Separador de ligação à base de dados:
- Host da base de dados:
localhost(ou IP remoto / endereço do túnel SSH) - Porta:
3306(ou a sua porta personalizada) - Nome da base de dados: valor de
settings.php - Nome de utilizador / Palavra-passe: valores de
settings.php - URL de ficheiros Drupal: o URL público do seu diretório
sites/default/files/do Drupal — necessário para o download de media
Clique em Testar a ligação antes de prosseguir. Uma ligação falhada nesta fase é quase sempre causada por um de três problemas: credenciais incorretas, uma firewall a bloquear a porta MySQL, ou o utilizador da base de dados Drupal sem privilégios SELECT na base de dados de destino.
Separador de comportamento — definições recomendadas para a maioria das migrações:
- Importar publicações: Sim
- Importar páginas: Sim
- Importar categorias e etiquetas: Sim
- Descarregar imagens e anexos: Sim (necessário para copiar media para o diretório de uploads do WordPress)
- Remover dados WordPress antes da importação: Sim (apenas numa instalação nova — isto trunca
wp_postse tabelas relacionadas)
Iniciar a Importação
Clique em Iniciar / Retomar o Importador. O plugin processa conteúdo em lotes. Para sites de grande dimensão, a importação pode expirar e requerer múltiplos ciclos de retoma — este é o comportamento esperado, não um erro. Basta clicar em Retomar cada vez.
Monitorize o registo de importação apresentado no ecrã. Fique atento a:
Error downloading file — indica que o URL de ficheiros Drupal está incorreto ou o diretório de ficheiros não está acessível publicamente
Erros Duplicate entry — geralmente inofensivos, indicando que o plugin está a ignorar registos já importados numa retoma
MySQL server has gone away — indica que wait_timeout é demasiado baixo no servidor MySQL; aumente-o para pelo menos 600 segundos
SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
Passo 6: Reconciliar a Estrutura de URL e Configurar Redirecionamentos
Este é o passo que a maioria dos guias subestima. As incompatibilidades na estrutura de URL entre o Drupal e o WordPress são a principal causa de quedas de classificação SEO após a migração.
Padrões de URL do Drupal (Comuns)
Padrão de URL Drupal
Descrição
/node/123
Caminho de nó padrão (sem alias)
/about-us
Alias de caminho (mais comum)
/taxonomy/term/5
Página de termo de taxonomia
/user/1
Perfil de utilizador
/content/article-title
Alias prefixado por tipo de conteúdo
Configuração de Permalink do WordPress
Vá a Definições > Permalinks e selecione uma estrutura que corresponda o mais possível aos seus aliases de caminho Drupal. Para a maioria dos sites Drupal que utilizam aliases limpos, /%postname%/ é a escolha correta.
/%postname%/
Se o seu site Drupal utilizava URLs prefixados por categoria como /blog/article-title, use:
/%category%/%postname%/
Implementar Redirecionamentos 301
Instale o plugin Redirection (de John Godley) para gerir regras de redirecionamento. Para redirecionamentos em massa, exporte os seus aliases de caminho Drupal da base de dados:
SELECT source, alias FROM path_alias WHERE langcode = 'en';
Em seguida, importe o CSV resultante para o plugin Redirection, mapeando cada alias Drupal para o seu equivalente WordPress. Para URLs no estilo /node/123 que nunca foram aliasados, crie redirecionamentos baseados em regex:
/node/([0-9]+)$ → /?p=$1
Isto mapeia IDs de nó Drupal para IDs de publicação WordPress — mas só funciona se o plugin FG preservou os IDs de nó originais como IDs de publicação, o que faz por padrão.
Crítico: Teste cada redirecionamento com curl -I antes de entrar em produção:
curl -I https://yourdomain.com/old-drupal-path
Verifique se a resposta é HTTP/2 301 com o cabeçalho Location correto, não um 302 ou um 200 com um redirecionamento suave.
Passo 7: Migrar Temas e Reconstruir o Design
Os temas Drupal (baseados em Twig) não têm equivalente direto no WordPress. Deve reconstruir o design visual usando um tema WordPress como base.
Estratégia de Seleção de Tema
Temas baseados em blocos (FSE): Use o Editor de Site WordPress para controlo total do layout sem construtores de páginas. Melhor para programadores familiarizados com marcação de blocos.
Temas clássicos com construtor de páginas: Temas como Astra ou GeneratePress combinados com Elementor ou Bricks Builder oferecem o equivalente mais próximo ao Layout Builder do Drupal.
Tema filho personalizado: Se o seu site Drupal tinha um design muito personalizado, construa um tema filho baseado num tema pai minimalista (Underscores, Blocksy) e replique o CSS.
Reconstruir Menus de Navegação
Os menus Drupal não migram automaticamente. Reconstrua-os em Aparência > Menus (temas clássicos) ou no bloco de Navegação do Editor de Site (temas FSE). Consulte a sua estrutura de menu Drupal:
drush eval "print_r(menu_tree_all_data('main', NULL));"
Ou consulte a base de dados diretamente:
SELECT ml.link_path, ml.link_title, ml.weight, ml.depth
FROM menu_links ml
WHERE ml.menu_name = 'main-menu' AND ml.hidden = 0
ORDER BY ml.weight;
Widgets e Blocos
Os blocos Drupal mapeiam vagamente para widgets WordPress e blocos Gutenberg. Reconstrua as regiões de barra lateral e rodapé em Aparência > Widgets ou diretamente no Editor de Site. Os tipos de bloco Drupal personalizados com lógica PHP precisarão de ser reconstruídos como shortcodes WordPress ou blocos personalizados.
Passo 8: Auditoria de Conteúdo Pós-Migração
Não ignore esta fase. As ferramentas de migração automatizada lidam bem com conteúdo estruturado, mas falham silenciosamente em casos extremos.
Verificações de Integridade de Conteúdo
Media incorporada: As referências de ficheiros inline do Drupal utilizam um formato de token personalizado ([file:123] ou <drupal-media uuid="..."/>). Estes não irão renderizar no WordPress. Pesquise na base de dados por estes tokens:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%drupal-media%' OR post_content LIKE '%[file:%';
Shortcodes e Views: As Views do Drupal não têm equivalente no WordPress. Qualquer página que renderizasse uma View (ex.: uma listagem de conteúdo filtrada) ficará em branco. Reconstrua-as usando WP_Query, arquivos de tipo de publicação personalizado ou um plugin como Posts Table Pro.
Campos personalizados: Os dados de campo Drupal migrados via plugin Premium ficam em wp_postmeta. Verifique se os valores dos campos estão presentes:
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_key LIKE 'field_%' LIMIT 50;
Contas de utilizador: Se migrou utilizadores, verifique o mapeamento de funções. A função authenticated user do Drupal mapeia para Subscriber do WordPress. O editor do Drupal mapeia para Editor do WordPress. O administrator do Drupal mapeia para Administrator do WordPress. Audite o mapeamento e ajuste conforme necessário.
Deteção de Links Quebrados
Instale o Broken Link Checker ou execute um rastreamento com o Screaming Frog no seu ambiente de staging antes da mudança de DNS. Corrija todos os 404s internos antes de entrar em produção — não confie na monitorização pós-lançamento para os detetar.
Passo 9: Desempenho e Reforço de Segurança
Um site WordPress recentemente migrado precisa de reforço antes de estar pronto para produção.
Configuração de Cache
Instale o LiteSpeed Cache (se num servidor LiteSpeed) ou o W3 Total Cache / WP Rocket para ambientes Apache/Nginx. Configure:
Cache de página com um TTL de pelo menos 3600 segundos para páginas estáticas
Cache de objetos suportado por Redis ou Memcached
Cabeçalhos de cache do browser via .htaccess ou configuração do servidor
SSL/HTTPS
Certifique-se de que o seu site WordPress é servido exclusivamente via HTTPS. Se ainda não tiver um certificado, os Certificados SSL podem ser provisionados rapidamente e configurados para renovação automática. Atualize as definições de URL do site WordPress:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
Force HTTPS em .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Lista de Verificação de Reforço de Segurança
Desative XML-RPC se não for necessário: adicione add_filter('xmlrpc_enabled', '__return_false'); a functions.phpwp_ padrão (requer renomeação da base de dados — faça isto antes da importação se possível)755, ficheiros 644, wp-config.php 600find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.phpPasso 10: Mudança de DNS e Lançamento
Realize a mudança de DNS durante a sua janela de menor tráfego. O processo deve demorar menos de 15 minutos de trabalho efetivo, com uma janela de propagação de até 48 horas (tipicamente 1–4 horas para a maioria dos resolvers).
Verificações Finais Pré-Mudança
- Execute um rastreamento completo do URL de staging e confirme zero 404s
- Verifique se todos os redirecionamentos 301 retornam cabeçalhos
Locationcorretos - Teste formulários de contacto, funcionalidade de pesquisa e quaisquer fluxos de e-commerce
- Confirme que o Google Search Console está verificado no novo site
- Gere e submeta um novo sitemap XML via Yoast SEO ou Rank Math
Processo de Atualização de DNS
Se registou o seu domínio através do Registo de Domínios, atualize o registo A diretamente no painel de gestão DNS. Reduza o TTL para 300 segundos pelo menos 24 horas antes da mudança para minimizar o atraso de propagação.
A record: yourdomain.com → [new WordPress server IP]
TTL: 300 (pre-cutover), restore to 3600 post-cutoverMonitorização Pós-Lançamento
- Ative a ferramenta de mudança de endereço do Google Search Console se o próprio domínio mudou
- Monitorize os Core Web Vitals no Search Console durante os primeiros 30 dias — espere uma flutuação temporária de classificação enquanto o Google rastreia e re-indexa
- Configure o UptimeRobot ou equivalente para monitorização de disponibilidade
- Verifique os registos de erros do servidor diariamente durante a primeira semana:
tail -f /var/log/apache2/error.log
# or for Nginx:
tail -f /var/log/nginx/error.logResubmissão a Motores de Pesquisa
Submeta o seu sitemap atualizado no Google Search Console:
- Vá a Search Console > Sitemaps
- Introduza
sitemap.xml(ousitemap_index.xmlpara sites de grande dimensão) - Clique em Submeter
Submeta também ao Bing Webmaster Tools e verifique o site de forma independente — o índice do Bing é utilizado por vários motores de pesquisa de IA incluindo o Copilot.
Recomendações de Infraestrutura de Alojamento
O desempenho do seu site WordPress migrado depende fortemente da infraestrutura subjacente. Uma migração de Drupal para WordPress é o momento ideal para também modernizar a sua stack de alojamento.
Para sites com tráfego moderado (10.000–100.000 visitas mensais), um plano de VPS Hosting com pelo menos 2 vCPUs, 4 GB RAM e armazenamento NVMe proporciona margem suficiente para WordPress com cache de página completa. Para sites de alto tráfego ou com uso intensivo de recursos, os Servidores Dedicados eliminam completamente o problema de vizinhos ruidosos e dão-lhe controlo total sobre parâmetros do kernel, configuração MySQL e ajuste da stack de rede.
Se está a gerir múltiplos sites de clientes ou prefere uma experiência de gestão de servidor orientada por GUI, os Painéis de Controlo VPS oferecem uma variedade de opções incluindo cPanel, Plesk e DirectAdmin — cada um suportando gestão WordPress multi-site, backups automatizados e provisionamento SSL a partir de uma única interface.
Matriz de Decisão Técnica: Quando Usar Cada Abordagem de Migração
| Cenário | Abordagem Recomendada | Ferramenta Principal |
|---|---|---|
| Drupal 7, site pequeno (<500 nós) | Versão gratuita do plugin FG, mesmo servidor | FG Drupal to WordPress (gratuito) |
| Drupal 9/10, conteúdo com muitos parágrafos | Plugin FG Premium, servidor de staging | FG Drupal to WordPress Premium |
| Drupal Commerce → WooCommerce | FG Premium + add-on WooCommerce | FG + módulo de migração WooCommerce |
| Site Drupal multilíngue | FG Premium + WPML | FG + plugin WPML |
| Drupal com Views complexas | Reconstrução manual necessária | WP_Query + CPT UI |
| Migração para servidor diferente | Túnel SSH para acesso à base de dados | Encaminhamento de porta SSH |
| Requisito de zero tempo de inatividade | Implementação blue-green | Redução de TTL DNS + staging |
Principais Conclusões Técnicas
- Faça backup antes de qualquer coisa. Um dump SQL comprimido e um tarball de
sites/default/files/são a sua rede de segurança. Verifique que ambos estão completos e restauráveis antes de começar. - Teste a conectividade da base de dados antes de executar o importador. A maioria das migrações falhadas para no teste de ligação devido a regras de firewall ou concessões
SELECTem falta. - O conteúdo Drupal baseado em parágrafos requer o plugin Premium. A versão gratuita irá ignorar silenciosamente os campos de parágrafo, deixando o conteúdo incompleto sem qualquer mensagem de erro.
- Os redirecionamentos 301 não são opcionais. Cada URL Drupal que tem backlinks externos ou indexação em motores de pesquisa deve redirecionar para o seu equivalente WordPress com um 301 permanente. Um redirecionamento em falta é um sinal de classificação perdido.
- Reduza o TTL do DNS 24 horas antes da mudança. Defina-o para 300 segundos para que a propagação seja concluída em minutos, não horas, quando mudar o registo A.
- Audite
wp_postmetapara campos Drupal não mapeados. Os dados de campos personalizados ficam aí após a importação — verifique se estão presentes e corretamente indexados antes de desativar a instância Drupal. - Não desative o Drupal imediatamente. Mantenha o ambiente Drupal em execução (em modo de manutenção, não acessível publicamente) durante pelo menos 30 dias após o lançamento como referência e opção de reversão.
- Resubmeta o seu sitemap no mesmo dia em que entrar em produção. Não espere que o Googlebot descubra a nova estrutura organicamente — a submissão ativa acelera o rastreamento.
FAQ
Posso migrar uma instalação Drupal multisite para o WordPress?
Sim, mas cada subsite Drupal deve ser migrado individualmente. O plugin FG Drupal to WordPress não trata nativamente o multisite Drupal numa única passagem. Execute uma importação separada para cada subsite, visando uma rede WordPress Multisite ou instalações WordPress autónomas dependendo da sua arquitetura.
As palavras-passe dos utilizadores Drupal serão transferidas para o WordPress?
Não. O Drupal utiliza um hash SHA-512 com sal (ou bcrypt em versões mais recentes) que é incompatível com o hashing baseado em phpass do WordPress. O plugin FG Premium migra as contas de utilizador mas redefine as palavras-passe, acionando um e-mail de redefinição de palavra-passe para cada utilizador. Planeie a comunicação com os utilizadores em conformidade.
Como trato os tipos de conteúdo Drupal sem equivalente no WordPress?
Registe Tipos de Publicação Personalizados (CPTs) equivalentes no WordPress antes de executar a importação. O plugin FG Premium permite-lhe mapear tipos de conteúdo Drupal para CPTs WordPress. Sem este mapeamento, todos os nós assumem por padrão o tipo de publicação post, colapsando a sua taxonomia de conteúdo.
O que acontece aos termos de taxonomia do Drupal durante a migração?
Os vocabulários Drupal mapeiam para taxonomias WordPress. O mapeamento padrão converte tags do Drupal para etiquetas WordPress e categories do Drupal para categorias WordPress. Os vocabulários personalizados requerem registo manual de taxonomia no WordPress antes da importação, ou serão descartados.
Quanto tempo demora a migração de um site Drupal de grande dimensão?
Para um site com 5.000 nós e 2 GB de media, espere 2–4 horas de tempo de importação num servidor bem equipado, mais 4–8 horas de auditoria de conteúdo pós-migração e configuração de redirecionamentos. A mudança de DNS efetiva demora menos de 15 minutos. O tempo total decorrido desde o início até estar em produção é tipicamente de um a dois dias úteis para uma migração completa e de qualidade de produção.
