A WordPress XML export is a content-transfer file, not a complete recoverable copy of your website. Keep it for the content it carries, but do not cancel hosting or erase the source site until you have backed up files, the database, and any external storage the site depends on.
What Tools Export is designed to do
WordPress Tools Export creates a WXR XML file containing selected content and related records. The export screen lets you choose all content or filters such as post type, date, author, and status. A filtered export can therefore omit material even before considering files or settings.
The XML can describe attachments and their source URLs without bundling the original image or document bytes. During an import, downloading those files depends on the importer's behavior and the source remaining reachable. A list of media records is not proof that every file was copied.
Build a separate recovery inventory
Before migration, list what makes the business site work:
| Component |
Evidence to retain |
| Posts, pages, terms, and authors |
Export scope and representative record checks |
| Media and generated files |
File copy or object-storage backup |
| Theme and plugin code |
Exact versions and customization locations |
| Settings and custom tables |
Database backup and application-specific exports |
| External services |
Configuration inventory and authorized reconnection plan |
Do not place credentials in an ordinary content export or public handoff document. Transfer secrets through your approved secure process.
Export scope: Record filters and included content. Independent media: Do not rely on the old hostname. Application records: Test custom tables and integrations. Restore rehearsal: Keep the source until verification passes. Explanatory checklist, not a customer test result.
Test an import before retiring the old host
Use an isolated destination with outgoing email, payments, and webhooks safely controlled. Import a representative sample first. Include a post with images, a page using the builder, a custom post type, and a document download. Confirm the plugins that define those structures are installed where required.
Check author mapping, dates, terms, links, and media. A visually correct page may still load its images from the old hostname. Inspect actual resource requests so you know whether the destination owns its files or merely borrows them from the source.
If documents fail, use PDF response diagnostics. For missing image files, follow the media restore guide.
Treat commerce and forms as separate migration work
Do not assume a generic content import recreates orders, subscriptions, form entries, plugin settings, or integration state. Their storage and supported migration paths vary by application and version. Check the relevant vendor's migration guidance and reconcile counts and relationships in a test environment.
For an active business, define a cutoff and final synchronization plan. Otherwise a successful test import can still miss the orders or submissions created before the final switch. Keep a rollback plan that accounts for new records rather than blindly restoring an old full database.
When can the old environment be retired?
Only after the new site's important workflows pass, required media is independently available, redirects are mapped, and a separate backup has been restored successfully. Keep the source protected during the agreed retention window, not publicly exposed as a forgotten clone.
Use the small-business backup strategy to separate routine exports from recovery objectives. HandL WP can review a migration handoff when the export file is the only copy you currently have.
Reference: WordPress Tools Export screen.
References reviewed October 2, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.