Why moving WordPress content between sites usually breaks something

A translated page shows the wrong language. An Elementor design folds into a single block of plain text. An ACF image field points at a picture that doesn't exist on the new site. If you've ever copied a WordPress page from staging to production, or from one client site to another, you've probably seen at least one of these.

None of it is a bug in WPML, Elementor, or Advanced Custom Fields. It's what happens, by default, whenever WordPress content moves between two different databases — which is every single time you move it anywhere.

The part nobody thinks about: IDs

WordPress doesn't store a page's image as "this picture." It stores it as attachment ID 482, and trusts that ID 482 means the same thing everywhere. On the site where that page was built, it does — ID 482 really is that picture, in that database.

Copy the page to a different WordPress install, and ID 482 means something else there — a different attachment, or nothing at all, depending on what else that site's database happened to create as its 482nd row. The page still says "show attachment 482." It just isn't the picture you meant anymore.

This is true of far more than featured images. It's how Elementor stores every image and gallery reference inside its page design. It's how Advanced Custom Fields stores image, file, gallery, relationship, and post-object field values. It's how WPML links a translated post to its siblings in the same language group. Every one of these is an internal ID, correct only within the database that created it.

Why the usual ways of moving content don't fix this

WordPress's own export/import (the WXR file under Tools → Export) moves the raw post content and meta values verbatim — including every one of those now-meaningless IDs. A plain database copy does the same thing at a larger scale. Copy-pasting content by hand in the editor sidesteps IDs for plain text, but not for anything a page builder or a custom field stores as a reference rather than inline content.

None of these tools are wrong to do this — they're being asked to move data, and the IDs are part of the data. The problem only becomes visible once the page loads on the other site and some of what it's pointing at doesn't exist there.

What actually has to happen instead

Every reference has to be resolved and rewritten, not just copied — on the receiving site, at the moment of import:

• Media has to be found or uploaded on the destination, and every reference to it repointed at the destination's own attachment ID.
• ACF relationship and post-object fields have to be matched to the corresponding post on the destination (if it's already been migrated there) or left correctly alone if it hasn't.
• Elementor's internal links between pages need the same treatment, not just its media references.
• A WPML translation needs to be linked into the correct translation group on the destination — a group that has its own, different internal numbering than the source site's.

This is real, non-trivial work, specific to each plugin's own data shape — which is exactly why it doesn't happen by default, and why it's easy to assume a migration "worked" the moment the page loads without an obvious error, even when several references quietly didn't come through.

This is the actual job PostDeploy does

PostDeploy connects two WordPress sites directly and does this resolution work on import, not as an afterthought: media is found or uploaded and every reference repointed, ACF relationship/post-object/taxonomy/user fields are matched to their destination equivalents, Elementor's media and internal links are rewritten, and WPML translations are linked into the correct group on the other side. A snapshot is taken before anything gets overwritten, so a bad push or pull can be rolled back to exactly what was there before.

The free version on WordPress.org covers Posts, Pages, and custom post types between unlimited connections. Pro adds the ACF/Elementor/WPML reference resolution described above, plus bulk and scheduled deployment, rollback with full snapshot history, WP-CLI, and REST automation — for teams running more than one WordPress site who need this to just work, repeatedly, without checking every field by hand afterward.

Try it

PostDeploy Free is on WordPress.org today. If you need the ACF/Elementor/WPML fidelity described here, PostDeploy Pro is a standalone plugin — no free version required alongside it.