Moving Sites Within WordPress Multi-Network

October 29th, 2012 by Curtiss Grymala

Every once in a while, we have the need to move or copy a site from one place within our multi-network WordPress install into another area.

There are three basic ways we regularly move or duplicate sites within our installation. Sometimes, we simply need to replicate a site so that we can start from common ground, then modify the duplicate to include different elements. Other times, we simply need to move a site from one network to another (for instance, when research indicates that a specific area within the university website belongs under a different parent). We also come across the need to take a site that was previously a subsite within a network (a subdirectory under one subdomain) and “promote” it to be its own network (where it gets its own subdomain). It should be noted that, when moving a site from one network to another, you can rarely do so without having to manipulate the database a little bit. The complexity of the move often dictates just how much you’ll have to mess with the data.

Duplicating or Moving

If you’re simply planning to move a site from one network to another, there are a handful of ways to go about doing so. The simplest way, on the surface, would be to go into the database and edit the site ID (in this case, the term “site” refers to what we now call a “network”) for that site, so that it belongs within the new network. However, you will also have to replace a number of occurrences of the old site’s URL within the database.

The next option is to actually duplicate the site.

If you were duplicating a site within the same network (for instance, to create a copy of the site that will be modified), I would recommend using the WP Replicator plugin by Rennick Media*. However, it only allows you to replicate sites within the same network, it doesn’t allow you to copy one site and paste it into another network. At UMW, we actually use this method with our Magazine website. Each issue gets its own site within the magazine network. We set up a private, sample site with all of the structure and settings, and none of the content; then we replicate that site every time we need to create a new issue.

If you want to actually move the site to another network, though, you will need a plugin like BackupBuddy from iThemes*. BackupBuddy allows you to actually export a full backup of a single site within a network, then you can import that site into another network (this works for moving sites from one standalone multisite installation to another standalone multisite installation, as well).

To do so, simply network-activate BackupBuddy on both of the networks on which you’ll be working. Then, visit the dashboard for the site you want to copy/move and click the “Export Site (SA)” menu item. On that page, you’ll see a list of all of the mu-plugins and network-activated plugins that are currently in use on that site. If you’re moving sites within a multi-network installation, there is no need to export the mu-plugins or network-active plugins, as you will be importing the site into the same filebase, so all of those plugins already exist in the file structure. If you are moving from one standalone multisite install to another, you might want to check all of those in order to make sure they carry over.

Once the backup is complete, visit the Network Admin area for the new network into which you want to import the site. Go to BackupBuddy -> Multisite Import within your admin area and choose the appropriate backup file to import. Then, enter a new address for the new site and click the “Next Step” button.

Once that’s done, your new site should be set up and ready to go. There is one caveat, though. When BackupBuddy performs the import, although it will set up the URLs correctly, it actually assigns the new site to your root network (site ID 1), rather than assigning it to the network into which you imported it. This isn’t a big deal, it just means that, when you go to Network Admin -> Sites within that network, you won’t see your new site listed; instead, it will be listed under Network Admin -> Sites within your root network. To correct that minor issue, you’ll probably want to edit your database manually, replacing the site_id entry within the blogs table.

Promoting a Site to a Network

When you want to actually move a subsite and turn it into its own network, that gets a little trickier. Since BackupBuddy can only import a new site into an existing network, you can’t simply follow the same process as listed above.

Instead, you’ll need to create the new network as a placeholder, then import the site as a subsite of that network. In this case, because a lot of database manipulation is going to be required, I usually recommend setting the URL for the imported subsite to something completely unique (I usually use something along the lines of “replacemesubsite”) when importing the site.

Once you’ve performed the initial import, you’ll need to get your hands dirty within your database. It’s highly recommended that you perform a backup of your entire database at this time (BackupBuddy is also capable of doing that without taking down your website).

Now, you’ll want to actually perform a search in your database. You will want to make the following changes/replacements within your database.

  1. Edit your site table, find the row for the new network you created, and replace its ID with the ID of the new site you just imported.
  2. Edit your sitemeta table and run a search/replace to replace all instances of the new network’s ID with the new imported site’s ID. A simple UPDATE statement should do it. For instance, if the ID of the new network is 10, and the ID of the new imported site is 11, you would run something like UPDATE wp_sitemeta SET site_id=11 WHERE site_id=10 (replacing wp_sitemeta with the actual name of your table, and replacing 11 and 10 with the actual IDs of your sites).
  3. Edit your blogs table, find the row for the new site you imported, and delete it. Then, find the row for the new network you created, and replace the blog_id and site_id fields with the ID of the new site you imported.
  4. Drop all of the tables that were created for the new network you created. Again, assuming that 10 is the ID of the new network you created, and that you are using the default wp_ as your table prefix, you would go through and find all tables that start with wp_10_ and delete them. Be very careful during this step so that you only remove the tables for that specific site.
  5. Search the tables for the new site you imported to find any instances of the new URL you created (using the example above, I would search all of those tables for instances of “replacemesubsite”). In the instances in which I’ve performed these updates, I’ve found entries within the commentmeta, options and posts tables mostly. We also have GravityForms* installed and active, so we sometimes find entries in some of its tables. I wouldn’t be overly concerned with the entries inside of the commentmeta table, as those have little bearing on the site itself, and are usually serialized entries (making it much more difficult to replace them).
    1. Within the posts table, you’ll want to make at least two types of replacements. First, you’ll want to replace all instances of the URL within the post_content column (and possibly the post_excerpt column, if you’re on a site that actually uses that). Next, you’ll probably want to update the guid column within that table. For some reason (presumably since the guid, in theory, should never change), BackupBuddy does not update that field when it imports the site, so that column will still include your old URL. For instance, if you exported the site from, you imported it into, and you want to promote it to, you’ll need to search from within the guid column, and replace it with
    2. Within the options table, things are a little more complicated. You’ll probably want to actually update each row manually, as you will find normal data and serialized data within that table. You can safely delete some of the options within that table, so they don’t get in the way of your changes (for instance, it should be safe to delete all options that start with _transient_, as those are either transient options or transient timeouts, and should, by nature, be temporary data that gets replaced when it’s missing, anyway. Then, you can go about replacing instances of the new imported site’s URL with the new network’s URL.**
  6. If you have a way of doing so, you should perform one last search of your entire database (all fields in all tables) to look for any more instances of the incorrect URL and decide how (or whether) to fix them.
  • * BackupBuddy and WP Replicator are both premium plugins (as is GravityForms).
  • ** When replacing serialized data, you cannot simply replace the strings you want to replace. Instead, you will need to count the number of characters you are adding or removing, and then update the s:# portion of that same serialized information to match the changes you made. If you incorrectly update serialized data, you might introduce fatal PHP errors. If the serialized data is simply strings, numbers and arrays (no objects), you can potentially use an online serializer/deserializer to update the information for you.
« | »

Leave a Reply