Migravo WXR Media Migration

Import an export into a new WordPress site and two things break that nothing in the box will fix for you.

ACF Relationship, Post Object and Gallery fields stop working. They store post IDs, and the new site assigns different IDs, so every one of those fields now points at the wrong post or at nothing at all. Nothing reports it. The fields simply look empty, or worse, quietly reference unrelated content — and on a site built around related posts, professionals, case studies or products, that is most of the site.

Every image still lives on the old server. The core importer copies the references, not the files. The content looks fine right up to the day the source site is switched off.

Migravo fixes both, on a site that has already been imported or as part of importing it.

Repairing relationships

Upload the export from the source site on the ID Map tab. Migravo matches each old post to its new one by slug, builds a map of old ID to new ID, then rewrites every relationship, post-object and gallery field on the site in one pass.

It sweeps the whole database rather than one post type, so both sides of a two-way relationship are repaired as long as both are present — the field on the Artist and the field on the Song are just two more fields to fix, and it does not matter which order you imported them in. Import one post type now and the other later, then run the repair again: the map keeps what it already knows and grows as you import.

It only rewrites values it can account for. A flat list of numeric IDs is remapped; an ACF Link field, a repeater row, a phone number that merely starts with digits, and any ID with no entry in the map are all left exactly as they were. An ID whose target has since been deleted is reported rather than written as a dead reference.

And it tells you what it could not fix, as a verdict rather than a guess. An ID it has no mapping for is left alone — correct in itself, but the field still points somewhere wrong and the number still looks like a valid ID, so nothing errors. Migravo checks each one against the field’s own definition: ACF records which post types a Relationship or Post Object field may reference, so a practice_areas field declared as accepting service while holding an ID that is a trade_report here is broken as a matter of fact. Those are reported as broken and listed first, with how many fields hold each ID and what it actually is. Values that match the type the field accepts are marked as almost certainly already repaired, so re-running the tool does not raise false alarms. Import the missing post type and run it again; the map grows as you import, so order does not matter.

Re-hosting media

During import, Migravo finds every media URL in the post content and the featured image, downloads each file from the source site into the Media Library, and rewrites the content to point at the local copy. Files are deduplicated by source URL and filename, so importing the same export twice does not produce a second copy of every image.

What else the export carries, and what arrives with it

A WXR file says more about each post than its title and content, and a field that is read by nothing is a field that goes missing without a word. These now come across:

• Page hierarchy. wp:post_parent holds an ID from the source site, so it means nothing here until it is translated — and an untranslated one is why imported trees arrive flat, every child at the top level. Order in the file does not matter: a child that arrives before its parent is placed when the parent turns up.
• Image alt text. Written on the attachment item in the export, which is not a post that gets imported, so it was being left behind for every image at once. Alt text already on this site is never overwritten.
• Comment and ping status, rather than falling back to whatever this site’s defaults happen to be.
• Post password. A protected post used to arrive public, with nothing to say so.
• Sticky posts, for post — the one type WordPress reads that list for.
• The dates, all four of them. Publish and last-modified, local and UTC. WordPress will fill these in itself if nothing supplies them, and what it fills in is wrong: last-modified becomes the time the import ran, and the UTC columns are recalculated from the destination’s timezone, so moving a site between two zones shifts every one of them. A draft keeps its publish date on a re-import too, which it did not before.

Each is applied only where the export actually states it. An empty tag is a statement — “no password”, “not sticky” — and is honoured on a re-import; a tag that is not in the file at all says nothing, and nothing on this site is overwritten on the strength of it.

One limitation worth knowing. Posts are tied back to the source by the ID the export gives them, and that ID is not qualified by which site it came from. Import two different sites into one destination and a post from each can claim the same source ID; the hierarchy lookup then has two candidates and takes the most recent. This is inherent in what a WXR file records, not something the plugin can detect, and it applies equally to the relationship repair.

The rest of a real migration

• Resumable, non-blocking import — preview what the file contains, then import with a live progress bar and 1–10 concurrent requests. Close the tab or press Stop and the import offers to continue where it left off. Posts lost to a server hiccup are retried automatically, and any that still fail are listed with a button to retry just those.
• Safe re-imports — choose to skip, update in place, or delete and replace posts that already exist. Matching accounts for the fact that WordPress rewrites slugs on insert, so re-running an import does not silently duplicate posts.
• Taxonomy mapping — send a taxonomy from the export into a different taxonomy on this site, or skip it.
• Author mapping — map each author in the export to an existing user, or create one.
• Field renaming — map meta/ACF field keys when the source and destination names differ.
• Featured image from a custom field — for source sites that store it outside the standard thumbnail meta.
• Multisite aware — choose which site in the network to import into, or to build the ID map against.
• Built for large exports — tested against a 52 MB export of 5,179 posts, which it parses in about 44 seconds using around 4 MB of memory.

Security

• Every AJAX action requires a valid nonce and the import capability.
• All database queries are parameterized via $wpdb->prepare().
• Media downloads are guarded against SSRF — loopback, private-network and link-local addresses (including the cloud metadata endpoint at 169.254.169.254) are rejected. Redirects are followed, and every hop is checked by the same rule as the first, so a public URL that redirects to an internal address is refused at the redirect rather than fetched. A source site on a private network can be allowed deliberately, per host, using the wxmi_allow_private_media_host filter — see the FAQ.
• Restoring serialized meta values blocks PHP object injection (unserialize is called with allowed_classes => false).
• The temporary directory used during import is given a random, unguessable name, so the export and the per-post cache written inside it cannot be requested by anyone who does not already know the path. An .htaccess and an index.php are written alongside as a second layer — they help on Apache, but they are not relied on, because nginx, LiteSpeed and IIS do not read .htaccess at all.

Why not just use the core WordPress Importer?

Use it — and then use this. The core importer creates the posts, which is the part that already works. What it has no concept of is what became of everything that referenced those posts by ID, or of the files they pointed at:

• It does not know that ACF Relationship, Post Object and Gallery fields hold post IDs, so it leaves every one of them pointing at whatever now happens to own that ID on the new site.
• It copies image references, not images. The content depends on the old server staying online forever.
• Re-running it creates another copy of everything, so a partial or interrupted import cannot simply be repeated.

Is this a full-site migration tool?

No, and deliberately not. If you can copy an entire site — database, uploads and all — a tool built for that is the right choice and this is not it.

Migravo is for the cases where you cannot: you have a WXR export and a destination that already exists, you are pulling a few post types across rather than cloning a whole site, or you are on the other side of an import that already happened and left broken relationships behind. The ID Map tab works on a site that was imported months ago by something else entirely.

Two things in a WXR file are deliberately not imported, and are not planned:

• Comments. Migravo is about posts, the fields that point between them and the media they use. Comment threads, their authors and their moderation state are a separate body of data with their own spam and approval concerns, and the core WordPress Importer already handles them.
• Navigation menus. A menu is a set of posts referring to other posts by ID, so importing one without also owning the pages it points at produces a menu of dead links. Rebuild menus on the destination once the content is in place.

Run the core importer for either of those, then use this for the parts it leaves behind.