Faq | Innoraft Skip to main content

Search

Frequently asked questions

FAQ

Frequently asked questions

There is no single "magic button" tool; the industry standard is Drupal's native Migrate API paired with Drush (the command-line shell).

  1. For Drupal 6/7 upgrades: Use migrate_upgrade via Drush (drush migrate:upgrade) to scaffold migrations, then fine-tune via YAML.
  2. For custom/external data: Use custom YAML migration plugins executed via Drush (drush migrate:import --tag=...).
  3. For small, recurring non-technical imports: Modules like feeds work for simple periodic ingestion, but Migrate API + Drush remains the most performant, scale-tested solution.

Depending on the source format and complexity:

Core Modules:

  • migrate: The foundational ETL framework and plugin system.
  • migrate_drupal & migrate_drupal_ui: Core tools for migrating legacy Drupal 6/7 sites into modern Drupal.

Essential Contributed Modules:

  • migrate_plus: Adds JSON/XML/REST endpoints, migration groups, and extra process plugins.
  • migrate_tools: Adds migration management tools, web UI dashboards, and command line utilities.
  • migrate_upgrade: Generates migration templates/configurations from an existing Drupal 6/7 database.

Format & Architecture Specific:

  • migrate_source_csv / migrate_spreadsheet: For ingesting CSV, XLS, and XLSX files.
  • migrate_file_to_media: Converts legacy file and image fields into Drupal Media entities.
  • migrate_html_to_paragraphs: Splices monolithic WYSIWYG HTML into structured Paragraphs components.
     

The Drupal Migrate API is Drupal core’s built-in ETL (Extract, Transform, Load) framework. It provides a standardized, plugin-based architecture to import, reshape, and synchronize structured data, whether coming from legacy Drupal sites (Drupal 6/7), external CMSs, REST APIs, databases, or flat files, directly into modern Drupal entities.

Run repeated staging migrations, reconcile records using migration map and message tables, check taxonomy and author mappings, and confirm redirects before going live.

It can improve performance, but that's not guaranteed. Outcomes depend on hosting, caching, database and query behavior, and front-end implementation. Benchmark representative pages and key user journeys before and after migration rather than assuming the platform switch alone will improve performance.

Yes, for URLs with a genuine new equivalent. Avoid mass-redirecting unrelated pages to the homepage; Google can treat that as a soft 404.

Build a URL mapping sheet first. Use Pathauto for the new alias structure and the Redirect module to map old paths to their destinations.

Weigh business value, SEO value, compliance, and content dependencies together. Exclude dormant accounts unless there's a legal or business reason to retain them.

Map every URL to a genuine equivalent, set up redirects, and carry over metadata, canonical tags, robots directives, and the sitemap deliberately.

Skipping the content audit, recreating the WordPress content model as-is, mishandling entity references, and neglecting SEO after launch- these are some of the most common WordPress to Drupal migration mistakes.