How to Migrate a WordPress Site to Kubernetes

Most WordPress sites were never built to be moved. They sit on shared hosting or a single server, with everything - the content, the images, the themes, the settings - piled onto one disk. Moving that to Kubernetes means pulling it apart into pieces that each need handling correctly.

None of it is exotic, but it's the kind of multi-step job that's easy to get wrong by hand. This article covers what a real WordPress-to-Kubernetes migration involves and what NebuaCloud does for you.

Why WordPress is hard to move

A WordPress site is really three things bundled together:

• A database holding all the posts, pages, and settings
• A files folder holding uploaded images, themes, and plugins
• The site's web address, baked into hundreds of places in the database

On one server, none of that matters. The moment you move the site, all three become separate problems:

• The database has to be exported and rebuilt on the new side without corruption
• The files have to end up somewhere the new environment can serve them from
• Every place the old web address appears has to be updated, or the site comes up with broken images and links pointing back to the old host

Miss any one and the migration either fails outright or "succeeds" with a visibly broken site.

What a migration that works needs

• A way to reach the existing site to pull its data and files
• A real database on the new side - a proper managed one, not a temporary component that vanishes
• Automatic web-address rewriting across the whole database, not a manual find-and-replace
• A result that preserves the original site - same admin login, same content - not a blank install to reconfigure from scratch
• Somewhere durable for the files to live

How NebuaCloud does it

NebuaCloud has a dedicated WordPress migration flow, started from the Migrations tab in the dashboard.

There are two ways to connect to your existing site:

• Direct server access - point it at the server with the login details and the path to WordPress
• A companion plugin - install a small plugin on the existing site and connect with the site address and a token, for when direct server access isn't available

Either way feeds the same automated process:

1. Copy the database and files folder from the existing site
2. Create a NebuaCloud managed database for the new site
3. Load the data into it
4. Automatically rewrite the old web address to the new one throughout the content
5. Bring up WordPress against the migrated database as the original site - same admin account, same content - not a fresh install

The database is the part most likely to be botched by hand, so that's the part that's fully automated end to end.

The step that still needs a person

The database and address rewriting are automatic. The files folder - images, themes, plugins - is currently copied to a staging area rather than moved into the new site automatically. Getting those files into the running site today means an operator copying them across as a follow-up step.

This is the honest gap in the current flow, and it's why durable, easy file storage on the platform matters - it's the natural place for that media to land without a one-off script. NebuaCloud's file storage product, Drive, fits exactly this - see How to Manage Files on Kubernetes with NebuaCloud Drive. It isn't wired into the migration yet, so the handoff is still a manual copy.

Where this is going

The Migrations area is built to be a landing page for more than one kind of source - WordPress is the first, not the only one intended. The direction is a general "bring your existing site into NebuaCloud" experience, with other platforms and plain database imports added over time.

A concrete example

A team moving a WordPress blog off traditional hosting:

1. Start the migration from the dashboard and connect via direct server access (or the companion plugin).
2. NebuaCloud copies the database and files, creates a managed database, and loads the data.
3. Web addresses across the content are rewritten to the new address automatically.
4. WordPress comes up on the migrated database - the team logs in with the same admin credentials as before.
5. The team copies the exported files folder into place to finish.

The takeaway

A WordPress-to-Kubernetes migration is really three migrations at once: the database, the web addresses, and the files. NebuaCloud automates the first two - export, managed database setup, and address rewriting happen without manual work - while the file copy is still a step the team closes out by hand.

Try it with NebuaCloud -> deploy in minutes

Current Availability

Note: WordPress migration in NebuaCloud is live today via direct-server or companion-plugin export, with automatic managed database setup, data import, and web-address rewriting, followed by deployment of the migrated site. Database and settings migration are fully automated; the files folder (media, themes, plugins) is exported to staging but must currently be copied into place manually.

The Migrations area is designed to support multiple source types, but WordPress is the only one implemented today. More sources, and an automatic handoff of migrated files into Drive, are roadmap direction rather than current functionality.