This article was last updated 287 days ago. The information within may have evolved or changed; if anything is outdated or broken, please feel free to leave a message in the comments section.

Article Abstract

To achieve WordPress multisite deployment and data migration, the author redeployed a new site and enabled multisite mode to migrate the original site data to the new environment. During the migration process, it was found that directly enabling multisite has subdirectory deployment limitations and subdomain resolution anomalies. Ultimately, the method of completely migrating the wp-admin, wp-includes, and wp-content directories was adopted to transfer program data, and article content was migrated by importing XML files. Practice shows that multisite mode poses challenges in plugin compatibility, theme management, and O&M complexity. It is recommended to plan the multisite architecture from a new site to avoid migration costs, while paying attention to the impact of subdomain resolution strategies on subsequent expansion.

Qwen3-14B · 2026-06-18

Preface

WordPress supports multi-site functionality, but I have always felt that there was no urgent need for multi-site, and I didn't want to experiment with devices running active sites, so I have never bothered to mess with it.

A few days ago, in order to write a solution for WordPress multisite (see article:Home Data Center Series: Flexibly utilizing Cloudflare Tunnel to achieve automatic takeover by disaster recovery site when the main WordPress site fails), I got another Alibaba Cloud ECS for 99 RMB. Now that the solution is written and the cloud server is idle, I thought I might as well take this opportunity to get familiar with the WordPress multisite feature so that I can use it immediately when needed in the future.

However, after messing around with various online tutorials for a long time, I found that for sites that have been running for a long time, directly enabling the multisite feature has too many inconveniences:
Cannot use the subdirectory deployment method

For sites that have been running for more than 1 month, the subdirectory deployment method cannot be selected (although I don't need it), but I believe this is a convenient deployment method for many friends.
Subdomain mode will have some mysterious problems

After enabling the subdomain-based multisite mode, according to the previous domain name access settings of the WordPress site (see article:Tips and Tricks Series: Simple setup tutorial for WordPress supporting multi-domain access), various mysterious problems occurred. In the end, it was resolved by modifying the site url and home in the wp_options table of the WordPress database. However, even after it became accessible, it still didn't feel quite right. In the console, I would occasionally encounter situations where pages wouldn't open and needed to be refreshed. In short, it was not very pleasant.

Ultimately, I decided to redeploy a new site, enable multisite, and then restore other settings. In this article, it is assumed that the WordPress content corresponding to my domain ”blog.tangwudi.com” is migrated to a brand new WordPress site with the domain ”test.tangwudi.com” and multisite enabled.

Redeploy WordPress

I won't say much here, you can refer to previous articles:Docker Series: Using Docker to Set Up a Blog Slave Site Based on WordPress and Implement Regular Backups of Master-Slave Site Configurations。

Enable multisite

Edit the wp-config.php file and find the following description:

/* That's all, stop editing! Happy publishing. */

Then add the code above this line and save:

define( 'WP_ALLOW_MULTISITE', true );

As shown in the figure below:

Then enter the dashboard, and under the Tools menu, there is an additional option for Network Setup:

If the warning in the figure below appears, it is because the wildcard domain resolution for *.test.tangwudi.com has not been configured to point to this site. You can ignore this, as long as you configure the subdomains correctly later:

Correctly configure the site network according to the prompts in the red box in the figure below:

After saving and logging in again, you can see an additional ”My Sites” option, where ”Network Admin” is the key to adding new sites.

I won't go into detail about how to add a new site or how to add an administrator for a specific site. There are many tutorials online, and it's not difficult. This is not the focus of this article.

Migrate old site data to the new site

Actually, many online tutorials on enabling WordPress multisite end at the previous section. This is normal for a brand new site, but since we are enabling multisite for an old site that has been running for a long time and has a lot of content, we still need to migrate data. Of course, this migration is also divided into WordPress program data and database content.

Migrate old site WordPress program data

Prerequisite knowledge: The WordPress program has 3 directories, namely ”wp-admin”, ”wp-includes”, and ”wp-content”.
“wp-admin” directory: contains administrative files that control the WordPress dashboard; ”wp-includes”: contains files that store and manage the appearance of WordPress; ”wp-content”: contains folders for all themes, plugins, upgrades, or uploads used by the website.

In order to minimize the impact on the configuration files of the new site, I directly copied the 3 directories of the old site: ”wp-admin”, ”wp-content”, and ”wp-includes” to the new site, and then encountered the following error when accessing:

Theoretically, the best way at this time should be to find which configuration file specifies the twentytwentyfour theme, and then modify it to point to an existing theme. However, I took a quick look and couldn't find it... Too lazy to bother, I directly changed the name of the existing theme folder ”twentytwentytwo” (shown in the red box in the figure below) to ”twentytwentyfour”,

and then it was accessible:

Usehttps://test.tangwudi.com/wp-admin/my-sites.phpto access, and you can see that the plugins have all come over:

The themes also came over, but the argon theme used by the old site is not the default theme, and it was not enabled:

Change the argon theme to be enabled on all sites:

Note 1: After enabling multisite, directly usinghttps://test.tangwudi.com/wp-adminonly accesses the dashboard of the main site ”test.tangwudi.com” (subsequent other sub-sites are similar). To globally control the plugins, themes, articles, and other content of all sites, you need to accesshttps://test.tangwudi.com/wp-admin/my-sites.php：

Note 2: After messing around for a long time, I finally found that the ”plugins” directory under the ”wp-content” directory is the original installation directory of the plugins. It is best to empty it, because some plugins do not support multisite (or only the paid version supports multisite). Directly copying them over will cause a bunch of problems. It is better to reinstall them on the new site according to the actual situation. This problem wasted at least a day of my time.

Migrate old site articles and other data to the main site of the new site

Originally, I thought this would be very simple: either directly import the WordPress database of the old site to the new site, or use the WPvivid backup plugin to directly restore the database content. However, I found that it didn't work. After directly importing the SQL file exported from the old site, the site might not even open... I think it's because some formats of the single-site and multisite databases are different, and the WPvivid backup plugin simply says that the free version does not support multisite and requires upgrading to pro~~~. So I adopted a more primitive method: export all data as an XML file on the old site, and then import it on the main site of the new site:

WordPress deployed via Docker has a default maximum upload file limit of 1 MB. If the XML file exported from the old site does not exceed 1 MB, it can be imported directly. However, mine is 2.7 MB, which is much larger than 1 MB, so I need to modify the php.ini in the WordPress container.

Because I am used to using vim, I need to install it using apt. However, there is no ”/etc/apt/sources.list” file in the default WordPress container, so apt cannot be used. Therefore, I used the following command to generate sources.list:

cat <<EOF >/etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free-firmware
EOF

Then you can run the following command to install vim:

apt update
apt install vim

Finally, use the following command to edit php.ini:

cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini
vim /usr/local/etc/php/php.ini

vim /usr/local/etc/php/php.ini

upload_max_filesize = 20M #按自己实际需求修改
post_max_size = 30M #按自己实际需求修改，一般这个的数值要大于上面的upload_max_filesize

Import the XML file exported from the old site into the main site:

Then activate the Argon theme in Appearance:

Finally, visit the main site, and by this time the basic framework is already set up:

The rest is to reinstall the plugins, and by the way, see which plugins support the multi-site mode. For those that don't, you'll need to find alternatives and configure the plugins. If you really want to do this, it will take some time, so I won't go into detail here.

Summary

Actually, after going through all this trouble, I found that the multi-site mode is indeed not as convenient as the single-site mode in terms of operation and maintenance. Migrating from a single site to the multi-site mode is also quite a hassle. If one of the sites in the multi-site mode is far more important than the others, I think it's better not to use the multi-site mode. Otherwise, if one of the unimportant sites is attacked and has problems, it will also drag down the important site.

In addition, I think that if you want to use the multi-site mode, it is best to plan it from the very beginning and start setting it up from a brand new site. First, the subdirectory mode is very practical and doesn't require messing with subdomains. If you deploy a site cluster and have a detailed plan, the subdirectory mode will be very suitable. Second, after running for a month, you can only set up the subdomain mode. If it has already been running for so long, the plugins are probably already configured and broken in. Doing a subdomain-based multi-site mode at that point will be very troublesome just for the plugins, feeling like getting half the result with twice the effort.

When using the subdomain mode, if you can use a second-level domain as the main domain, it is best, such as ”tangwudi.com” in my case. This way, when adding other sites in the future, the DNS resolution will be easier to add. According to my article's ”test.tangwudi.com”, if you want to add a subdomain, it would be ”site1.test.tangwudi.com”, which looks a bit ugly. Of course, this can be solved using CNAME, such as ”abc.tangwudi.com cname site1.test.tangwudi.com”. Accessing it this way is also fine, just make sure the host is set up correctly when configuring the reverse proxy.

In summary, the default single-site mode and the multi-site mode each have their own advantages. It is best to make a plan when building the site and choose the most suitable site-building method for yourself. Once the site is up and running, it is best not to mess with it anymore.

📌 Content Structure Prompt:

This content is part of the following knowledge map, where you can view the complete content path: WordPress Learning Roadmap。

Share this article