15%

Poupe 15% em todos os serviços

Teste as suas habilidades e obtenha Desconto em qualquer plano

Utilizar o código:

Skills
Começar a trabalhar
23.10.2024

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ãoDrupalWordPress
Modelo de conteúdoEntidades (nós, termos de taxonomia, campos)Tipos de publicação (posts, páginas, CPTs)
Esquema de base de dadosAltamente normalizado, multi-tabela por tipo de conteúdoModelo wp_posts + wp_postmeta simples
Roteamento de URLAliases de caminho armazenados na tabela path_aliasRegras de reescrita de permalink via .htaccess
Motor de temasTemplates Twig + hooks de pré-processamentoHierarquia de templates PHP + hooks
Funções de utilizadorPermissões granulares por funçãoHierarquia de funções fixa (Subscritor → Administrador)
Gestão de mediaEntidade de ficheiros geridos com anexos de campoBiblioteca de Media com tipo de publicação de anexo
MultilíngueMódulo de Idioma principalRequer plugin WPML ou Polylang
REST APIMódulos principais JSON:API + RESTWP REST API integrada
Complexidade de alojamentoAlta (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 --gzip

Backup da Base de Dados via mysqldump

mysqldump -u drupal_user -p drupal_database_name | gzip > /var/backups/drupal_backup_$(date +%Y%m%d).sql.gz

Backup 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)

  1. Inicie sessão no phpMyAdmin através do painel de controlo do seu alojamento
  2. Selecione a base de dados Drupal na barra lateral esquerda
  3. Clique em Exportar, escolha o método de exportação Rápida, formato SQL
  4. 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

RequisitoMínimoRecomendado
Versão PHP7.48.2
MySQL/MariaDBMySQL 5.7 / MariaDB 10.3MySQL 8.0 / MariaDB 10.11
Limite de memória PHP64 MB256 MB
max_execution_time30s300s
upload_max_filesize8 MB128 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.com

Instalaçã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 128M

Passo 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

  1. No seu painel de administração WordPress, vá a Plugins > Adicionar Novo
  2. Pesquise por FG Drupal to WordPress
  3. Clique em Instalar Agora, depois em Ativar

Em alternativa, instale via WP-CLI:

wp plugin install fg-drupal-to-wp --activate

Comparação de Funcionalidades Gratuitas vs. Premium

FuncionalidadeGratuitoPremium
Suporte Drupal 6/7SimSim
Suporte Drupal 8/9/10ParcialCompleto
Migração de parágrafosNãoSim
Migração de utilizadoresNãoSim
Migração de WebformNãoSim
E-commerce (Drupal Commerce)NãoSim
Conteúdo multilíngueNãoSim
Suporte prioritárioNãoSim

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.php

O 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 -f

Em 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_posts e 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.php
  • Altere o prefixo de tabela wp_ padrão (requer renomeação da base de dados — faça isto antes da importação se possível)
  • Instale o Wordfence ou o Solid Security para firewall e proteção de login
  • Defina permissões de ficheiros: diretórios 755, ficheiros 644, wp-config.php 600
  • find /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.php

    Passo 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 Location corretos
    • 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-cutover

    Monitorizaçã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.log

    Resubmissão a Motores de Pesquisa

    Submeta o seu sitemap atualizado no Google Search Console:

    1. Vá a Search Console > Sitemaps
    2. Introduza sitemap.xml (ou sitemap_index.xml para sites de grande dimensão)
    3. 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árioAbordagem RecomendadaFerramenta Principal
    Drupal 7, site pequeno (<500 nós)Versão gratuita do plugin FG, mesmo servidorFG Drupal to WordPress (gratuito)
    Drupal 9/10, conteúdo com muitos parágrafosPlugin FG Premium, servidor de stagingFG Drupal to WordPress Premium
    Drupal Commerce → WooCommerceFG Premium + add-on WooCommerceFG + módulo de migração WooCommerce
    Site Drupal multilíngueFG Premium + WPMLFG + plugin WPML
    Drupal com Views complexasReconstrução manual necessáriaWP_Query + CPT UI
    Migração para servidor diferenteTúnel SSH para acesso à base de dadosEncaminhamento de porta SSH
    Requisito de zero tempo de inatividadeImplementação blue-greenReduçã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 SELECT em 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_postmeta para 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.

    15%

    Poupe 15% em todos os serviços

    Teste as suas habilidades e obtenha Desconto em qualquer plano

    Utilizar o código:

    Skills
    Começar a trabalhar