Every CMS migration tool does the same core job: it reads content out of one system and writes it into another. What separates them is not quality but reach, and every one of them stops at the same boundary. A migration tool can move what your CMS stores as data. It cannot move what your CMS produces as behavior. Your post text, titles, dates, authors and taxonomy terms are data and they travel. Your shortcodes, page-builder layouts, plugin-generated sections and theme features are instructions that only mean something on the platform that understands them, and no importer can carry those across. Whether a tool is "enough" depends entirely on how much of your archive sits on each side of that line, which is a fact about your content rather than about the tool.
Before running any migration tool, take a full backup of the source site and verify that you can restore it, and run the tool into an empty destination you can afford to reset, never into a live site that already holds content. Tools are the part of a migration most likely to be run casually, because they present as a single button. See the backup and rollback plan.
This article is written in July 2026 and describes tool categories and their structural limits rather than the current feature list of any product. Migration tooling changes constantly, and a specific claim about a specific plugin's current behavior would be stale within months. Nothing here is a recommendation, a ranking or an endorsement, and this site takes no referral fee from any tool vendor. Check any tool's own documentation, changelog and stated version support before you rely on it.
The four categories
Almost everything on the market is one of these four shapes. Knowing which shape you are looking at predicts its limits better than reading its feature list.
| Category | How it works | Reaches | Typically stops at |
|---|---|---|---|
| Native export and import | The platform's own export file, read by the destination's own importer | Posts, pages, taxonomies, basic metadata | Media as files, custom fields, anything plugin-generated |
| Source-specific importers | Built to read one named platform's format | Whatever that pair was designed to handle, often well | Anything the pair's author did not anticipate, including your customizations |
| API-to-API and scripted transfer | Reads from one system's API, writes to another's | Anything either API exposes, with full control over mapping | What the APIs do not expose, and it needs someone to write and maintain it |
| Full-site clone or duplicator | Copies the entire site, database and files | Everything, exactly | Only works platform to platform, which makes it a hosting move, not a CMS change |
The last row is worth separating out because it is a frequent source of confusion. Tools that clone a whole site are excellent at what they do and are not CMS migration tools at all. They move a site from one server to another while keeping the same platform. If you are changing CMS, they are not in the conversation.
Where all of them stop, and why it is structural
This is the part that turns a tool question into a content question.
Content in a CMS lives in two different states. Some of it is stored: the words, the title, the publication date, the author name, the list of tags. Some of it is produced: a related-posts block generated at page load, a gallery assembled by a plugin from a stored list of image IDs, a layout described by a page builder in its own private format, a call-to-action inserted into every post by the theme.
A migration tool sees the first state. The second state is not in the content, it is in the code that renders it, and there is nothing to copy. This is why a tool that moves nine hundred posts perfectly can still leave you with nine hundred broken-looking pages: it moved everything that existed, and the missing part never existed as content in the first place.
Three consequences follow, and they hold across every tool in every category:
- Platform-specific markup arrives as literal text. Square brackets, custom tags and builder markup come across intact and meaningless. This is the whole subject of shortcodes, blocks and embeds after a migration.
- Media usually needs a separate pass. Export files commonly reference images by URL rather than containing them, which is covered in what happens to your images when you move platforms.
- Fields with no destination are dropped, and often quietly. The destination's content model decides what can be received at all, which is why the model has to be designed before the tool is run rather than after. See why your old posts do not fit the new structure.
None of these is a bug report. They are the shape of the category.
The question to ask about any tool
Feature lists all say the same things. This is the question that actually distinguishes tools, and it is rarely on the marketing page:
What does it do with an item it cannot convert?
There are three possible answers and they are not equivalent:
- It drops the item silently. The migration reports success and your archive is quietly incomplete. This is the worst outcome, because you find it months later and by then the source may be gone.
- It flags the item and continues. You get a list of what needs manual attention. This is the best available answer and it is worth choosing a tool for.
- It carries the item across raw and unconverted. Nothing is lost, and it is now visible as garbled output that you can find and fix. Ugly, honest, recoverable.
Look for the answer in the tool's documentation, in its error and log output, and in its issue tracker if it has a public one. A tool that produces a detailed report of what it could not handle is more valuable than one that claims a wider feature set, because the report is what converts an unknown into a task list.
How to find your own coverage gap before you commit
You do not need to evaluate tools in the abstract. Your archive tells you which tool category you need.
- Sample your own content honestly. Pick twenty posts that represent your worst cases rather than your best: the oldest, the longest, one with a gallery, one with an embed, one built with a page builder, one with custom fields, one with a table.
- Categorize each element as stored or produced. Anything you can see in the raw editor or the export file is stored. Anything that only appears on the rendered page is produced.
- Count the produced elements. That count, not the post count, is the real size of your migration.
- Run the tool on those twenty posts into an empty destination. A test migration on a deliberate sample is the only reliable comparison, because it tests the tool against your content rather than against a demo site.
- Diff the result against the source. Not by glancing at the homepage. Post by post, for those twenty.
If the twenty come across cleanly, a native or source-specific importer is very likely enough for the whole archive. If they do not, the gap you found is the specification for whatever manual or scripted work has to fill it, and that specification is worth more than any tool comparison you can read.
What "is a plugin enough?" really means
The honest answer is that it usually is enough for the transfer and never enough for the migration.
The transfer is the easy half: getting the words, dates and titles into the new system. Tools are good at this and have been for years. The migration is the whole job: reconciling the structure, repairing the formatting, moving the media, fixing the internal links, checking the result and deciding what to do with the content that does not fit. Tools do not touch most of that, and a tool that promised to would be making a claim about your editorial judgment that it cannot support.
Budget accordingly. The tool selection is a small decision inside a much larger piece of work, and it is worth much less attention than the sample migration that tells you what the tool will leave behind. The broader sequence is in the CMS migration guide.
FAQ
Is a migration plugin enough to move my whole site?
Usually enough for the text, titles, dates and taxonomies, and rarely enough for platform-specific formatting, media files or custom fields. The gap depends on how much of your content is stored as data versus produced by your theme and plugins.
Why did my posts import but look broken?
Because the parts that were generated by the old platform's theme or plugins had no equivalent to copy. The text arrived; the instructions that used to turn that text into a finished page did not, and they never existed as content.
Should I use a tool or write a script?
Use the simplest thing that passes a twenty-post test on your own worst content. A script is worth the effort when your content model needs real mapping work or when the platform pair has no maintained importer between it.
How do I compare two migration tools fairly?
Run both against the same deliberately awkward sample into empty destinations, then compare what each one reported it could not handle. Reporting quality separates tools more usefully than feature lists do.
Do migration tools handle redirects?
Generally not, and where they claim to, verify it against your own URLs. Preserving your existing links is normally a separate artifact you build yourself, and it is worth treating as its own task rather than a tool setting.
Written July 2026 from published tool documentation and general category behavior, not from tests conducted for this article. Migration tooling changes frequently; this page is due for review every 90 days.
