Server Migration Complete

update20260520

Note: This article describes a case with a Japanese hosting provider. If you’re working through a similar migration, please check the specifics with your own hosting company and confirm what applies in your region.

On May 11, 2026, Xserver — a major Japanese hosting provider — officially announced a server upgrade.

The plan I’m on, Business Standard, is included in the upgrade.

The existing plan uses MariaDB 10.5.x as its database. The new servers move to MariaDB 10.11.x.

This site is built on WordPress. I’m running the latest 6.9.x branch, and the official requirements published on the WordPress site are these:

WordPress requirements

  • PHP 8.3 or higher
  • MariaDB version 10.6 or greater OR MySQL version 8.0 or greater
  • Nginx, or Apache with mod_rewrite
  • HTTPS support

The current server doesn’t meet the database requirement, so to satisfy what WordPress now expects, the server has to be upgraded.

According to Xserver’s announcement, all new sign-ups go straight to the new servers, but for existing contracts the handling depends on when the server was issued:

  • New sign-ups on or after May 11, 2026: new servers.
  • Shared servers issued on or after June 12, 2024, 11:00: Xserver will roll out the MariaDB 10.11 update from June 2026 onward.
  • Managed dedicated servers issued on or after June 26, 2024, 11:00: same — MariaDB 10.11 update from June 2026 onward.

I signed up in 2023, so none of the above applies to my server.

  • Shared servers issued before June 12, 2024: if you want to use a MariaDB 10.11 environment, you can move via the “New Server Easy Migration” feature (新サーバー簡単移行).

So the user does the migration themselves to move onto the new server.

I looked into the “New Server Easy Migration” feature and started the process.

The Actual Migration

I’ve written up the actual steps on my sister site, which is built with Drupal.

The articles cover running Xserver’s “New Server Easy Migration” and updating from MariaDB 10.6.x → MariaDB 10.11.x and Drupal 10.6.8 → Drupal 11.3.9 in the same pass.

[ #D39 Drupal Core 11.3.9 #1: Environment Setup ] (in Japanese)

[ #D40 Updating from Drupal 10.6.8 to Drupal 11.3.9 #2 ] (in Japanese)

Reading the articles, it might look like a lot of work, but the actual hands-on time was short.

Xserver automates the migration end-to-end — copying the data from the old server to the new one, all the way through the DNS switchover — so it really is straightforward.

What takes time is the data copy and the DNS propagation, both of which run a few hours each (about two hours in practice). When each step finishes, you get an email notification, so as long as you can come back to it when you have a moment, the workload isn’t heavy.

One thing to watch: the server hostname and IP address change, so any software on your local machine that points at them needs its settings updated. In my case, the only change was the incoming/outgoing server settings in my mail client.

The migration steps look like this:

1. Request the migration.

2. The migration runs. “This step takes several hours.”

3. Verify the site on the new server. “If anything’s wrong, you can roll back to the old server here.”

4. If everything checks out, commit the migration.

5. Switch over DNS.

6. Wait for DNS to propagate. “DNS propagation takes several hours regardless of this migration.”

That’s the flow. If something looks off at step 3, you can cancel the migration and keep running on the old server. (You can roll back to the old server for 14 days after the migration completes.)

In my case, I’d changed the system-level PHP version to run Drupal, and there was an issue with that symlink, so I had to repair it. I also did a major Drupal update at the same time, which added some work.

For a WordPress-only setup, the migration process is all you need to do.

Performance Improvements

With the newer database, things run faster across the board. The admin panel feels snappier and so does the front end, so there’s a clear case for migrating beyond just meeting requirements.

LTS

LTS stands for “Long Term Support” — a model where bug fixes and security updates continue to ship for a given version over an extended period.

MariaDB 10.11.x, the version this upgrade lands on, is supported through February 16, 2028.

[ MariaDB Maintenance Policy ]

WordPress will go through 6.9.x → 7.0 → 7.1 → 7.2 over the course of this year, and after this server upgrade the requirements are met for all of them.

* While writing this article, this site’s WordPress was updated from 6.9.4 to 7.0.

Roadmap

I couldn’t find a published roadmap from WordPress with concrete requirements for upcoming versions, so I’ll reference Drupal’s roadmap instead — Drupal lists requirements alongside its release plan.

WordPress hasn’t officially announced what 7.0.x will require, but with the current PHP 8.3.x and MariaDB 10.11.x in place, things should run without issue. PHP 8.4.x or 8.5.x may end up being required down the line, but the new server supports those too, so there’s no concern.

On the Drupal side, upgrading PHP from the current 8.3.x to 8.4.x covers the upcoming Drupal 11.4.x and 11.5.x releases, which keeps support running through December 2028.

For reference: the next Drupal major release, Drupal 12.x, ships in December 2026 and requires MariaDB 10.11.x. The major bump also raises the PHP requirement to 8.5.x or higher, so a PHP version upgrade comes with it.

I’ll wait to see how Civic Theme (the Drupal theme I’m running) handles the major upgrade before moving to it, so there will be some lag between Drupal 12.x’s release and when I actually switch over.

Extending the Support Window

Both WordPress and Drupal are developed with MariaDB 10.11.x’s EOL (End of Life) in mind, so by moving to the new server now, I have security support through February 16, 2028.

Xserver also supports PHP 8.4.x and 8.5.x, so a PHP version bump later isn’t an issue either.

Xserver Business Standard

This site runs on Xserver’s shared hosting plan, Xserver Business Standard. I don’t write operations or technical articles on this site, but I’ve covered some of this on the Drupal site I run for learning purposes.

[ Xserver Business Standard article ] (in Japanese)

That article is written from a Drupal angle, but one of the real strengths of Xserver Business Standard is how well it pairs with WordPress. It was originally built to host corporate sites, so it covers everything a business needs. (The feature set is more generous than the personal-use plans.)

Even without a dedicated tech person on staff, you can build a company site, register and manage the domain, set up SSL, and create staff email addresses — all from the admin panel.

What’s good about WordPress is that the server-side requirements — PHP, the database, Apache, SSL — are well-defined, and as long as the host meets them, the user can build and publish a site with WordPress without thinking much about the stack underneath.

Xserver wraps the functions you need to build and run a site into the admin panel, and the controls are simple to operate. With just Xserver’s admin panel and WordPress’s admin panel, you can build and manage a site end-to-end.

Easy to Operate, Flexible Enough to Extend

The Xserver + WordPress combination works really well in practice. Since almost everything is handled through the GUI, users without much technical background can take a site from setup through ongoing operation.

Worth noting too: there’s also reasonable flexibility for uses beyond WordPress.

Customization via the console isn’t officially supported and has to be done at the user’s own risk, but the same is true for other hosts — and even AWS or GCP — so it’s not really an issue.

Addendum

As an aside: on Xserver Business Standard, the PHP used by CMSs like WordPress and the PHP version that shows up when you run php -v in the terminal are different. I’d wondered why, so here’s my take.

Different PHP versions?

WordPress and Drupal are web-facing systems — in stack terms, they run in the web tier.

On Xserver, both WordPress and Drupal are installed under public_html, which is the web tier.

WordPress installation path:
$ home/../../hooked-on01.com/public_html/wp-content
— installed under the web tier.

Drupal is installed on a subdomain, so the path looks like:
$ home/../../hooked-on01.com/public_html/drupal.hooked-on01.com/[project name]/vendor (Drupal directory)
— same as WordPress, installed under the web tier.

Web tier PHP version
WordPress admin:
Site Health > Info > Server > PHP version 8.3.30 (Supports 64-bit values)
Matches the PHP version set in the Xserver admin panel.

System tier PHP version
$ php -v
PHP 8.0.3
Copyright (c) The PHP Group
Zend Engine v4.3.30, Copyright (c) Zend Technologies
Different from the version set in the Xserver admin panel.

The PHP version you select in the Xserver admin panel is the one called by the web tier.

The system-tier PHP runs the Xserver admin panel itself, processes cron jobs, and handles other server-side tasks. If users could change it freely, it would risk breaking the admin panel or other system processes, so general users are locked out of touching it.

The web tier PHP version isn’t dictated by the server side — it follows whatever the user’s application (WordPress, etc.) needs — which is why Xserver lets you set the PHP version from the admin panel.

If you need to raise the PHP version used outside the web tier (which Drupal does need), you can do it by creating a symlink to the PHP version Drupal requires, from among the versions installed on the server. (WordPress probably doesn’t need this.)

For details, see the Drupal articles linked at the top of this page.

WordPress and Xserver

What Xserver does well, if you’re building and running a WordPress site, is this:

  1. It comes prepared to meet WordPress’s requirements from the start.
  2. If WordPress’s requirements shift over time as new versions ship, you can bump the PHP version from the admin panel — no console knowledge required.
  3. Common tasks come with simple templates.
  4. Database setup can also be done from the admin panel.
  5. Domain registration is straightforward, and the path from buying a domain to having a site online is almost entirely admin-panel work.
  6. Security tools — WAF and CDN — can be turned on with a single click.

— all of which makes the platform very approachable.

What the GUI Gives You

If you’re running WordPress on Xserver, everything happens inside two admin panels — Xserver’s and WordPress’s. That’s a real benefit. WordPress powers about 43% of websites worldwide, and the infrastructure for running it has matured along with that adoption — Xserver’s infrastructure reflects that maturity and passes it on to its users.

In Closing

With Xserver Business Standard’s database upgraded, the EOL concerns I had about WordPress and Drupal are resolved.

The migration from the old server to the new one is straightforward, so if you’re running a WordPress site — personally or for a business — it’s worth considering.

This round of server updates is fundamentally a MariaDB upgrade, but beyond resolving EOL it also brings processing speed gains from the newer version.

As I touched on in the article, Xserver and WordPress pair together exceptionally well. Even first-time WordPress users can build and run a site without hitting a wall, thanks to a genuinely well-designed interface.

The Business Standard plan I’m on is comfortable not just for corporate use but for personal use as well, and it strikes a solid balance between cost and performance.

[ Xserver Business ] (in Japanese)