My Experience Migrating a Wiki Archive to a New Server

Moving a wiki archive sounds simple until you realize the pages are the easy part.

The awkward bits are hiding underneath: uploaded files, revision histories, database character sets, PHP extensions, cron jobs, search indexes, permissions, and the DNS record you forgot existed because nobody has touched it in three years.

That was the shape of my migration.

For a site built around preserving and organizing information, a sloppy server move is especially frustrating. You are not just relocating a website. You are relocating an archive, with all the historical baggage that makes an archive useful in the first place.

The process described here is the practical route I would take again for a MediaWiki-based archive: stage the new server, copy the data in layers, test it under a temporary hostname, freeze edits for the final synchronization, then switch traffic only after the boring checks pass.

Boring is good here.

MediaWiki's current installation documentation lists MediaWiki 1.46.0 as the current stable release and recommends using supported production versions. Its requirements also call for PHP 8.3.0 or later for the latest stable release, with MariaDB/MySQL recommended among the supported database options.

Why I didn't just copy the old server

My first instinct was the classic shortcut: archive /var/www, dump the database, restore everything on the new machine, change the DNS, and call it finished.

That can work.

It can also preserve every old mistake.

The previous server had accumulated configuration leftovers, abandoned PHP packages, manually edited web-server rules, and a couple of scripts that only made sense to the person who originally installed them. Copying the whole operating environment would have moved the clutter along with the archive.

So I treated the migration as a rebuild rather than a clone.

The target stack was a clean Linux server running:

Ubuntu Server
Nginx with PHP-FPM
PHP 8.3
MariaDB
MediaWiki from a supported release branch
OpenSSH for encrypted file transfer
TLS certificates managed separately from the content migration

That separation mattered. A server migration is easier to troubleshoot when "the database works," "the web server works," and "the wiki data works" are three different questions.

MediaWiki supports major web servers capable of invoking a compatible PHP version, including Apache HTTPD and Nginx. The official documentation also notes that shell access is effectively necessary for running maintenance scripts and makes upgrades considerably easier.

The inventory took longer than the copy

Before moving a single byte, I made a list.

Not a glamorous list. A complete one.

I checked the MediaWiki version, installed extensions, skins, PHP modules, database engine and version, upload directory size, cron jobs, DNS records, email configuration, and any custom changes inside LocalSettings.php.

I also wrote down the actual paths.

That sounds trivial until one server stores uploads under /var/www/wiki/images while another deployment uses a symlink, an object-storage mount, or a custom $wgUploadDirectory. Guessing is how files disappear.

The official MediaWiki requirements page also distinguishes between the core software and optional dependencies. Image thumbnailing, for example, may depend on ImageMagick or GD, while features and extensions can introduce additional PHP requirements.

One small snag caught me during the audit: the wiki itself looked healthy, but an extension depended on a PHP capability that wasn't part of my first server build.

The homepage loaded.

A maintenance task didn't.

That's the danger of declaring victory after testing only the homepage.

I built the destination before touching production

The new server was configured as a separate environment first.

I installed the operating system, applied updates, configured the firewall, created the database and database user, installed the required PHP extensions, and deployed the MediaWiki code before importing the production archive.

For Debian- or Ubuntu-based systems, the MediaWiki documentation specifically calls out packages and extensions such as php-intl, php-mbstring, php-apcu, php-curl, php-mysql, and php-xml as part of a typical setup. The exact package names vary by distribution and PHP version, so I checked the actual runtime with php -m rather than assuming everything was enabled.

Then came the first real checkpoint:

Can the new server run a clean MediaWiki installation before production data enters the picture?

If the answer is no, importing a large archive only makes the problem harder to isolate.

The hardware lesson: minimum isn't a target

MediaWiki's published minimum of 256 MB RAM and 85 MB storage may be enough for a very small single-machine installation, but the documentation explicitly warns that it is not sufficient for a busy public site or a wiki with uploads.

My rule was simpler: size the server around the archive, not the installer.

A wiki with 20 GB of uploads, a 6 GB database dump, thumbnails, backups, logs, and temporary working files should not be placed on a 30 GB disk and called "efficient." Imports and backups need breathing room.

I wanted enough free storage to hold the existing data, a fresh backup, temporary export files, and normal growth without immediately running into a disk-full incident.

That extra headroom is cheap compared with recovering a broken import.

Moving the database was the easy-looking part

For the first synchronization, I exported the production database and restored it into the new MariaDB instance.

Then I checked:

Did the import finish without SQL errors?
Does the expected database contain the expected tables?
Are table prefixes and character encoding correct?
Can MediaWiki connect using the new credentials?

Only after those checks did I move on.

A raw database migration is often preferable when preserving a full MediaWiki installation because it keeps far more than the visible page text. Users, revision histories, templates, categories, permissions, and other application data remain connected through the existing schema.

XML exports still have their place, particularly for content-focused migrations or selective imports. MediaWiki's importDump maintenance process can import XML files produced by Special:Export or dumpBackup.php; on MediaWiki 1.40 and later, the documented command uses the maintenance/run.php wrapper.

For a large archive, though, I would not casually assume an XML import is quick. The MediaWiki documentation warns that importDump can take a long time with very large datasets.

The upload directory was where I almost made a mess

Database imported. Great.

Then the new wiki displayed a page containing an old scanned image, and the file link pointed to nothing useful.

Of course it did.

The database knew the file existed. The actual file hadn't arrived yet.

MediaWiki stores uploaded files separately from the database in a standard installation, so the image directory needs its own migration plan. For a staged transfer, I used rsync over SSH because it can synchronize changed files efficiently after the initial copy.

The pattern was straightforward:

rsync -aHAX --info=progress2 -e ssh \
/path/to/wiki/images/ \
user@new-server:/path/to/wiki/images/

The first pass moved the bulk of the archive while the old server was still live.

Later, during the final cutover window, I ran a second synchronization to capture files added or changed after the first pass.

That second pass was much faster.

Don't forget ownership

Copying the files isn't the finish line.

On the destination server, I checked ownership and permissions against the user running PHP-FPM and the web service. A directory can physically contain every uploaded PDF and image while still returning errors because the application process cannot read or write where it needs to.

I also tested uploads after the migration rather than assuming old permissions were correct for the new environment.

One successful upload told me more than another hour of staring at ls -la.

My testing process was deliberately repetitive

I tested the new server using a temporary hostname and, where appropriate, a hosts-file override before changing public DNS.

Then I went through pages that were chosen for different reasons:

a simple text article
a page using several templates
an old revision
a category page
a page with a large image
a PDF or other non-image upload
a page with non-ASCII characters
a search query
a login/logout cycle
an edit made by a test account

I wasn't trying to prove that every page looked identical.

I was trying to break things.

Search was especially worth checking. A successful database import does not automatically guarantee that every derived index or cached representation behaves exactly as expected. If an import method skips updates, MediaWiki documents follow-up maintenance such as rebuilding links, templates, and categories with rebuildall.php.

That distinction matters: source data can be intact while derived data is incomplete.

Cutover day: I stopped pretending zero risk existed

Eventually, there has to be a final switch.

My preferred sequence was:

Reduce DNS TTL ahead of the migration window, if practical.
Put the wiki into a controlled read-only or maintenance state.
Take a final database backup.
Run the final database synchronization.
Run the final rsync for uploaded files.
Test the destination one more time.
Change DNS and watch the logs.

The old server stayed online.

That was intentional.

I did not cancel it the moment the new server appeared to work. Keeping the old environment available for a rollback period gave me a known-good reference if something subtle surfaced after traffic began reaching the new host.

DNS propagation can also produce a slightly strange period where different users reach different servers depending on cached records. A short transition window is normal. A database that accepts edits on both servers during that window is not.

One writable source of truth. Always.

What I would change next time

I'd automate the inventory earlier.

The migration itself was manageable, but collecting extension versions, file paths, PHP modules, scheduled jobs, and configuration differences manually was tedious. A small shell script could capture most of that information before the project starts.

I'd also perform a full dry run sooner.

Not a partial restore. A complete rehearsal.

That is the single biggest improvement I can recommend for anyone moving a valuable wiki archive. A dry run exposes slow transfers, missing dependencies, permission problems, and unexpected configuration assumptions while the production server is still untouched.

The first migration should be the practice migration.

FAQ

How long does it take to migrate a wiki to a new server?

It depends far more on database size, upload volume, network throughput, and import method than on the number of visible pages. A small archive can move in hours; a large XML import may run far longer, and MediaWiki specifically notes that very large imports can take days.

Should I migrate with a database dump or XML export?

For moving an entire MediaWiki installation with its operational history intact, a database migration is usually the more direct approach. XML exports are useful for content transfers and selective imports, but they are not a drop-in substitute for every part of a complete server migration.

Can I move MediaWiki to a server with less RAM?

Technically, very small installations can run with limited memory, but the published 256 MB minimum is not a sensible sizing target for a busy archive or one with uploads. Leave room for the database, PHP processes, caching, backups, and maintenance work.

Do uploaded images live inside the MediaWiki database?

Not in a standard setup. The database stores metadata and references, while uploaded files need to be migrated separately from the appropriate upload directory or storage backend.

What is the safest moment to cancel the old server?

Not immediately after DNS changes. Keep the old environment available until the new server has survived real traffic, edits, uploads, scheduled tasks, backups, and a reasonable rollback window.

The migration taught me something that applies to archive management well beyond MediaWiki: preservation isn't finished when the files arrive somewhere new. It is finished when you can find them, read them, revise them, back them up, and recover them without relying on the machine you just left behind.

So before shutting down the old server, restore one backup on the new setup.