Separating a Subsite from WordPress Multisite into a Standalone Site

Separating an individual subsite from a Multisite network into its own standalone WordPress installation becomes relevant when a site is sold, outgrows shared network resources, or requires its own dedicated server and plugin configurations.

Because a Multisite network shares a single database and file structure, migrating a subsite requires isolating its specific database tables, renaming table prefixes, and adjusting media file paths.

Preparations Before Migration

Before taking any technical steps, ensure the following prerequisites are met:

Identify the Subsite's ID Number:
Connect to your Multisite server via SSH and list the network's sites:
```
wp site list
```
Check the output for the blog_id of the site you intend to migrate (in this guide, we use ID 3 as our example).
Create a Fresh Backup of the Multisite Network:
```
wp-backup
```
Prepare the New Standalone Site:
Ensure you have a new, empty Seravo hosting environment ready (such as WP Pro or WP Business) to which the site will be migrated. If you have not yet purchased the new hosting plan, you can order it directly via Seravo's order form. The initial migration will be conducted using the new environment's temporary development domain (e.g., newsitename.fi-c.seravo.com).

Alternative Method: All-in-One WP Migration (Paid)

If you prefer not to perform the migration via the command line, the process can also be handled within the WordPress admin dashboard using the All-in-One WP Migration plugin alongside its paid Multisite Extension. This extension allows you to export an individual subsite directly into a .wpress file, which can then be restored onto the new standalone site using the standard free version of the plugin.

Please note that for exceptionally large sites (several gigabytes), command-line migration is considerably faster, more dependable, and avoids PHP memory and execution timeout limits.

Step 1: Exporting Subsite Tables and Renaming Prefixes

The subsite's content (posts, pages, options) resides in tables identified by the site's ID prefix (e.g., wp_3_*). In a standalone WordPress installation, the default table prefix is wp_*.

Export only the specific subsite's tables into an SQL file:

wp db export subsite_dump.sql --tables=$(wp db tables 'wp_3_*' --format=csv)

Rename Table and Setting Prefixes:
Replace the prefix wp_3_ with wp_ across the dump file. This also automatically updates the user roles capability key wp_3_user_roles inside the options table to wp_user_roles:
```
sed -i 's/wp_3_/wp_/g' subsite_dump.sql
```

Step 2: Handling User Accounts

In Multisite, user accounts are stored centrally across the network in the shared wp_users and wp_usermeta tables. There are two recommended approaches for handling users:

The site only has a few administrators (Recommended):
Manually recreate the necessary administrator accounts on the new standalone site via the WordPress dashboard or using WP-CLI (wp user create). If you want to preserve author attribution on existing posts, make sure the user IDs match, or simply reassign the posts after migration.
The site has a large user base (e.g., WooCommerce customers):
Export the global user tables and filter them down to include only users associated with this specific subsite. Note that in wp_usermeta, subsite permissions are stored under the meta key wp_3_capabilities, which must be renamed to wp_capabilities for the standalone site.

Step 3: Migrating Media Files

In Multisite, images and attachments for each subsite are organized in subdirectories under /wp-content/uploads/sites/<ID>/. In a standalone WordPress site, media files are stored directly in /wp-content/uploads/.

Transfer media files into the root uploads directory of the new site:
Copy the files from the Multisite directory .../uploads/sites/3/ to the new standalone site's /data/wordpress/htdocs/wp-content/uploads/ directory (for instance, using rsync or scp):
```
rsync -avz /data/wordpress/htdocs/wp-content/uploads/sites/3/ [email protected]:/data/wordpress/htdocs/wp-content/uploads/
```

Step 4: Migrating Themes and Plugins

Check which theme and plugins were active on the specific subsite:

# Check active theme
wp theme list --url=https://example.com/subsite --status=active

# Check active plugins
wp plugin list --url=https://example.com/subsite --status=active

Install and activate the corresponding theme and plugins on the new standalone site using WP-CLI, or transfer custom theme and plugin folders from server to server into wp-content/themes/ and wp-content/plugins/.

Step 5: Importing the Database and Updating URLs

Import the modified database into the new installation:
```
wp db import subsite_dump.sql
```
Correct Media File Paths in the Database:
Since media files were moved out of the sites/3/ subdirectory, update the internal image paths across the database:
```
wp search-replace '/uploads/sites/3/' '/uploads/' --all-tables
```
Update the Site Address (URL):
Replace the old Multisite URL with the new site's address:
```
wp search-replace 'https://example.com/subsite' 'https://newsite.com' --all-tables
```
Purge the Cache:
```
wp-purge-cache
```

Step 6: Testing and Deleting the Old Subsite

Review the New Site:
Log in to the new site's WordPress dashboard. Confirm that:
- All pages and posts are present.
- Images display properly in the media library and content.
- Plugin and theme configurations have remained intact.
Update DNS Records:
Once the site has been verified, update the domain's DNS records (A and AAAA) to point to the new site's IP address. Make sure the www subdomain is routed via a CNAME record as well.
Archive or Delete the Old Subsite from Multisite:
After DNS propagation is complete and traffic routes cleanly to the new standalone site, you can safely archive or delete the old subsite from the Network Admin (Network Admin > Sites).

Troubleshooting and Exceptions

"Sorry, you are not allowed to access this page" after logging in:
User roles or permissions are broken in the database. Ensure that the wp_options table contains the option name wp_user_roles (and not the old wp_3_user_roles). Also ensure your user has the proper capabilities assigned in wp_usermeta under wp_capabilities. You can create a clean administrator account via CLI:
wp user create newadmin [email protected] --role=administrator
Images are missing or broken across pages:
The search-replace command for media paths was either skipped or failed. Re-run step 5: wp search-replace '/uploads/sites/3/' '/uploads/' --all-tables and clear the cache using wp-purge-cache.