Before moving your full archive, run the same migration process on a small, deliberately chosen sample first, then read the results side by side against the source. A test migration is not proof that your export file works; it is proof (or disproof) that your specific content survives your specific migration path, and the only way to find that out is to run it and look, not to assume it from a successful-looking import log.
The backup and rollback plan applies here exactly as it does to the full move: verify it is current and restorable before you touch anything, including the sample. A test migration usually writes into a fresh, empty destination rather than a live one, but if your test target is the same destination you intend to use for real, treat it with the same caution as the final migration, because a mistake in a rehearsal can still cost you real data if it lands somewhere that matters.
A convenient sample is not a representative one
The easiest 20 posts to grab for a test are the newest 20, and they are also the least likely to contain what actually breaks.
Recently published content tends to use whatever formatting options are currently in favor, tends to have few or no comments yet, and tends to sit in a category structure that has not been reorganized five times since the post was written. A test migration run only on recent posts can pass cleanly and tell you almost nothing, because it never touched the parts of your archive where the real risk lives.
The risk concentrates in old content, for a simple reason: it was written under different tools, different conventions and a different version of whatever you are running now. A post from several years ago is more likely to carry a shortcode nobody uses anymore, a deeply nested category, an embedded gallery built with a plugin that has since been replaced, or a long comment thread. None of that shows up in a sample chosen for recency.
Choosing your sample deliberately
Pick a small set on purpose, not at random and not by convenience. A useful sample usually includes:
Your oldest post, or one of your oldest. Whatever has accumulated the most format drift over the years is the best early warning you have.
Your most-commented post. Comments have their own dependency chain, separate from the post body, and a heavily commented post exercises that path harder than a quiet one.
Your most heavily formatted post. The one with a comparison table, an embedded gallery, a pull quote, or several images with captions: whatever your site’s most complex format looks like.
A post with nested or unusual categorization. If your taxonomy has any hierarchy or overlap, include a post that sits inside it, not one filed under a single flat tag.
A handful of ordinary posts, for contrast. Not everything in your archive is a hard case, and you need a baseline of what a clean pass looks like so you can tell it apart from a partial one.
Roughly 15 to 25 posts, chosen this way, is usually enough to surface most of what a full migration would hit. The exact count matters less than the deliberateness of the choice. A random sample of 50 recent posts finds less than a deliberate sample of 15 old, difficult ones.
Running the test end to end
Run the actual migration process you intend to use for the full move, using the same export, the same import path, and the same destination platform, on the sample only. A test that uses a shortcut version of the process (a manual copy-paste, a different export format) is not testing what you are about to do; it is testing something else that happens to look similar.
Let the import complete fully before checking anything. A partial or interrupted test tells you about interruption, not about your content.
What “pass” actually means
An import that completes without an error message is not the same as an import that produced what you wanted. Checking only for errors is the most common way a test migration passes and the real migration still fails, because most of the failures in this cluster, such as flattened taxonomy, images that silently vanish, or shortcodes with no interpreter, do not raise an error. They just produce a result that is wrong.
The actual check is a side-by-side read: open each sample post on the source platform and the destination, next to each other, and read both. Not a glance. Confirm the body content matches, the images are present and correctly placed, the category or tag assignments are right, the comments (if you are migrating them) are attached to the correct post, and the author and date are what you expect. Ten posts read properly this way tell you more than a hundred glanced at.
What a failed test tells you, and what to do next
If something in the sample comes across wrong, that is the test working, not the test failing. You have found a problem while it costs almost nothing to fix, on a handful of posts, instead of finding it after moving your whole archive.
Trace the failure to its cause before deciding what to do about it. A single post with a broken embed might mean that content type does not survive the migration path at all, which is a decision to make for your whole archive, not a one-off fix. Re-run the test on the same sample after adjusting your approach, and only move to the full migration once a full read of the sample passes cleanly.
Once your sample passes, the cutover sequence is the next step: the same care you used to verify the sample applies to the full move, at a larger scale. For where this rehearsal fits in the overall sequence, the migration guide sets out the order the whole cluster follows.
FAQ
How many posts should I include in a test migration?
There is no fixed number that works for every archive. What matters is that the sample includes your oldest content, your most complex formatting, your most-commented post, and a nested category if you have one, alongside a few ordinary posts for contrast. Roughly 15 to 25 chosen this way is usually enough to surface most failure modes.
Can I just migrate my most recent posts as the test?
You can, but it tests the easiest part of your archive rather than the hardest, and a clean result tells you very little about what will happen to your older content.
What counts as a passed test?
A side-by-side read of every post in the sample against the source, confirming the body, images, categorization, comments and metadata all match. An import with no error message is not the same thing.
Should the test migration go into the same destination I will use for real, or somewhere separate?
A separate, disposable destination is safer if your platform supports it, because it removes any risk of the test interfering with your real migration later. If you must use the same destination, treat the test with the same care as the final move.
What if the test migration fails?
Trace the failure to what caused it before fixing anything, because a single broken post can indicate a pattern affecting many others. Adjust your approach and re-run the test on the same sample until a full read passes cleanly, before moving the full archive.
Written August 2026. Migration import behavior varies by platform and can change between releases; verify the specifics of your own source and destination platforms before relying on any detail above.
