The best export format is the one your destination CMS can import cleanly. A CMS migration, the move of content and structure from one content management system to another, works best with a native SQL dump for same-stack moves and with structured content files for cross-platform moves. Same-stack means MySQL to MySQL or PostgreSQL to PostgreSQL. Cross-platform means WordPress to Drupal, Drupal to Contentful, or any move into headless and Strapi.
Official resources:
- Generate a WordPress WXR export with WP-CLI — Verify what WXR files include and which options control the export.
- Create a PostgreSQL SQL dump with pg_dump — Verify how pg_dump output recreates the database on another server.
Table of Contents
- When Should You Keep the Native Database Dump?
- When Does WordPress WXR Make Sense?
- What Do Drupal and Headless Targets Want?
- How Do You Keep Hierarchy and Characters Intact?
When Should You Keep the Native Database Dump?
Stay with a database-native dump when source and target use the same database stack. The Oracle MySQL Reference Manual describes mysqldump logical backups as SQL statements that reproduce object definitions and table data for transfer to another server. That approach carries users, settings, and content together.
It avoids rebuilding posts, links, and permissions by hand. PostgreSQL has a parallel path for the same situation. The PostgreSQL Documentation describes pg_dump database recreation as SQL commands that recreate the database in the same state, including moves across machine architectures such as 32-bit to 64-bit.
When Does WordPress WXR Make Sense?
Use WXR for WordPress-to-WordPress content transfer. WP-CLI and Developer.WordPress.org describe WXR, WordPress eXtended RSS, as XML containing authors, terms, posts, comments, and attachments. WXR has a hard limit.
The same source notes that WXR files do not include site configuration or the attachment files themselves. That makes WXR a content-only move. Plan separately for themes, plugins, settings, and media binaries.
What Do Drupal and Headless Targets Want?
Choose CSV, JSON, XML, or a live source when Drupal is the destination. The Drupal Association migration API treats migration as ETL, with source rows from a database, CSV, JSON, or XML files, or RSS and REST services, as described in the Drupal migration source guide. That flexibility lets a team export in whatever structured form preserves the source best. Transform the rows during migration, then load them into Drupal destinations.
Headless targets are stricter about shape. Contentful FAQ Best Practices requires exported source data formatted to JSON accepted by the content model, then imported through its import tool or Content Management API. Strapi keeps its own bundle for instance moves. Strapi 5 Documentation describes `strapi export`, `import`, and `transfer`, defaulting to gzip-compressed, AES-128-ECB-encrypted `.tar` archives holding configuration, entities, links, and schemas as JSON-lines files.
How Do You Keep Hierarchy and Characters Intact?
Prefer XML or JSON over flat CSV when parent-child links matter. The Archives Hosting UK migration guide explains that XML preserves hierarchy and record relationships, while flat CSV collapses them into rows and columns, losing nesting and requiring reconstructed IDs. That difference affects menus, sections, collections, and attached files.
A nested export keeps the parent with the child. Lock character encoding to UTF-8, specifically `utf8mb4`, before import. WordPress VIP Documentation warns that accented characters, emoji, and 4-byte Unicode corrupt without it, as explained in the WordPress VIP charset requirements.
- Use SQL for same-database moves that must keep full state.
- Use WXR for WordPress content-only moves, plus a separate media plan.
- Use XML or JSON for hierarchical content bound for Drupal or Contentful.
- Export and import everything as `utf8mb4` to protect names, copy, and emoji.
