What gets lost in a migration without anyone noticing

The site has moved. You open it, and it looks right. Home page there, images there, menu there, footer there.

That is exactly the problem.

A migration rarely fails visibly. It fails on five or six things that produce no error message and that nobody misses until weeks later someone asks why an old link leads nowhere or why a plugin no longer gets updates.

This article lists those things. Not as a list of horrors, but as a checklist for the day after.

Why this happens at all

Most migrations today run through a tool that packs the website into a single archive and unpacks that archive at the destination. That works well, and it saves you a lot of manual work — above all, it adjusts the addresses in the database automatically, including those buried deep in nested settings. By hand, that is exactly the most error-prone point of the whole process.

But such an archive does not contain the whole installation. At its core it contains your content directories and the database. Explicitly not contained are the WordPress core itself, the central configuration file and the web server's control file.

That is no oversight, it is right: these three belong to the environment, not to the website. At the destination there is already a WordPress with its own configuration.

It is just that almost nobody draws the conclusion from it. And it is: Everything you wrote into these files on the staging site is not there at the destination.

The web server's control file does not travel along

This is the most expensive point on the list, because the redirects hang on it.

If you redirect your old addresses to the new ones, and you wrote these redirects directly into the control file, they are gone after the migration. The file at the destination is a new, empty one. WordPress puts its own basic rules in there, nothing else.

The tricky part: the website still works perfectly. Anyone who opens the new address notices nothing. Only someone arriving through an old link — from a search engine, from a bookmark, from someone else's site — lands in nothing. And that is exactly the visitor you wanted to protect with the migration.

The same goes for the password protection you used to shield the staging site from prying eyes. That is gone afterwards too. In this direction it is practical — you do not have to remove it any more. But you should know it.

That is why you have to save the address structure once again

This is directly connected and often passed on as a superstition of its own: “After the migration, save the permalinks once.”

The reason behind it is no magic. WordPress writes its rules for building addresses into exactly the control file that was just created anew. So it only contains what WordPress wrote into it at installation — not what your actual address structure needs.

A single save in the settings writes the rules anew. Without it, subpages return error messages while the home page looks flawless.

The configuration file does not travel along either

It is less noticeable, because rarely does anyone write anything visible into it. But when they do, it is usually important:

Error logging you had switched on for development — gone. And the other way round: security settings you made there, such as locking the built-in file editor, are not active at the destination.

The second case is the more dangerous one, because it looks like security and is not.

You log in with the staging site's credentials

The moment most people get a brief fright.

Before the import, a fresh WordPress with a freshly created account stood at the destination. After the import this account is gone — because the user table came along from the archive. From now on, the credentials from the development environment are valid.

That is logical once you know it, and an unpleasant moment if you do not. Especially when the staging site ran with a throwaway password nobody wrote down.

Before the import, check that you still have the staging site's credentials. Not afterwards.

Whatever lies outside the content directories stays behind

Anything you put directly into the server's main directory is not contained in the archive.

The most common case is a custom error page as a static file — for example the page shown to visitors when content was deliberately deleted. If you built such a page, it is still on the old server. And the version you built still refers internally to the staging site's addresses.

So it does not just have to be uploaded again, it has to be regenerated first.

The same goes for verification files some services expect in the main directory, and for anything else you put there.

Licences still point to the staging site

Paid extensions usually bind their licence to an address. They were activated on the development environment — that is, on an address that is about to stop existing.

After the migration everything keeps running, because the extension is installed. What no longer runs are the updates. And you do not notice that the next day, but in the month a security hole becomes known and the update does not come.

Open every paid extension once after the migration and set the licence to the new address. It is plain work and takes ten minutes.

Some builders have to regenerate their caches

If your site is built with a builder that generates finished output files from its settings, those files may still point to the old paths after the migration.

The result looks broken without being broken: the page loads, but spacing is off or a section is missing. Regenerating once in the builder's settings fixes it.

The only important thing is not to mistake it for a real error and start searching through the content.

Two properties of the archive worth knowing

It has no checksum. The archive format contains no mechanism that notices whether the file is complete. An interrupted download or upload produces a file that looks fine at first glance. It only shows when individual pieces of content cannot be read during unpacking — that is, in the middle of the import.

It is unpacked completely before anything is loaded in. During the import, the destination server needs free space the size of the unpacked website, on top of the archive itself. With a large site on a tightly sized package, that is the point where the process aborts.

Neither is an argument against this approach. It is an argument for not starting the migration five minutes before closing time.

The check that finds all of it

There is a single check that makes most of this list visible: let the new site be crawled completely once and look at the response codes.

Not clicking. Let it be crawled, with a tool that fetches every address and records what the server answers.

Ideally the same answer comes back everywhere: all fine. Everything else is a finding:

• A “not found” answer means that somewhere on your own site a link still points to an address that no longer exists.
• A redirect within your own site means that an internal link still points to the old address and only arrives via a detour. That works — and is still wrong. Internal links should point directly.

You do this crawl twice: once on the staging site, before switching over, and once on the finished site afterwards. The second crawl finds exactly the things the migration broke.

And then a third check that works differently: fetch the list of your old addresses. Not the new ones — the old ones. Exactly three answers are allowed: still reachable unchanged, permanently redirected, or deliberately deleted. If anything else comes back, a redirect is missing.

This third check assumes you have a list of your old addresses. If you do not, that is the actual finding — there is an article of its own on that.

The order for the day after

First: be able to log in. Have the staging site's credentials ready before the import starts.

Then: save the address structure once again. One click, and the subpages work.

Then: restore the redirects. That is the point with real consequences for visitors.

Then: let the site be crawled and correct the internal links found.

Then: fetch the old addresses and add missing redirects.

Then: switch the licences over.

Then: regenerate the static files in the main directory and upload them.

Last: look through the configuration file — was something in there that belongs back in?

What is unspectacular about it

Nothing on this list is difficult. No point needs special knowledge, and none takes long.

It still regularly gets skipped, because the migration counts as done the moment the home page looks right. That is the point where most people stop — and where the work begins.

If you have a migration behind you and are not sure whether these points were worked through: the check with the crawl takes a quarter of an hour and answers the question.

Sources

• Atlas, wordpress/plugins/all-in-one-wp-migration/mechanics.md — that the archive bundles the content directories and a single database file; that wp-config.php, the .htaccess in the WordPress root directory, the WordPress core itself and the security keys are explicitly not bundled; that the source addresses are replaced with the destination address during import and that serialised structures are traversed safely in the process, which is what makes manual work at this point so error-prone; that the archive format carries no checksum, so truncation or damage is not noticed at format level but only when individual pieces of content cannot be read; that the import unpacks completely to disk before the database is loaded, so the destination needs free space the size of the unpacked website.
• Udemy, Der perfekte Webseiten-Relaunch, phase 4: going live — the observation that the redirects from the development environment's control file are no longer there after the migration, because the file is created anew, and that the same process also removes the staging site's password protection; that the login credentials after the import are those of the development environment and not those of the freshly set-up destination installation; that the address structure has to be saved once again; that paid extensions have to be registered again, because their licence still points to the development environment and otherwise the updates stay away; that a static error page in the main directory still refers to the development environment and has to be regenerated and uploaded; that a builder has to recreate its generated output files after the migration; and the crawl of the finished site sorted by response code, in which a number of “not found” answers and one unnecessary internal redirect showed up.
• Udemy, Der perfekte Webseiten-Relaunch, phase 2 and phase 4 — that exactly three answers are allowed when fetching the old address list: still reachable unchanged, permanently redirected, or reported as deleted.
• Own practice — the order for the day after, the advice to check the credentials before and not after the import, and the observation that a migration counts as done the moment the home page looks right.
• Not proven and therefore open — whether the statement on wp-config.php and the control file applies to all common migration tools or only to the one it was looked up for here. The article therefore phrases it as a property of this approach, not as a general rule.