We extract one subsite from your multisite network into its own standalone WordPress installation, separating its content, media, and settings from the shared network tables and rebuilding it as an independent site — a genuinely more involved job than a normal migration, since multisite’s database structure interleaves shared and site-specific data.
Subsite extraction to standalone site
One subsite carefully extracted from the network into its own standalone install.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Admin access to the network and the specific subsite being extracted
- Your target hosting environment for the new, standalone site
- Confirmation of which plugins and media are genuinely specific to this subsite, versus shared network-wide
This or something else?
| You want one specific subsite pulled out of your network into its own standalone installation | This fix covers it |
| You’re moving a standalone site to a new host, not extracting from multisite | Host-to-host migration – single site, in the Backups, Staging & Migration Ops category |
| You want the whole network moved, not one subsite extracted from it | A different, larger project — worth discussing directly |
| You want a staging copy of the subsite, not an actual extraction | Staging environment creation & sync, in the Backups, Staging & Migration Ops category |
What we do
- Identify exactly what content, media, and settings belong specifically to the subsite being extracted
- Separate that subsite’s data from the shared multisite database tables
- Reconstruct it as a standalone WordPress installation on the target hosting
- Reinstall and reconfigure any plugins that were previously network-activated
- Verify all content, media, and functionality transferred correctly
- Test the standalone site thoroughly before final DNS cutover
What is included
- A complete, standalone WordPress installation extracted from the network
- All subsite-specific content, media, and settings preserved
- Plugins reinstalled and reconfigured for standalone use
- Thorough testing before cutover, with the pre-extraction network state left untouched
Not included
- Changes to the remaining network itself, beyond removing the extracted subsite if requested
- Purchasing new hosting for the standalone site, unless already arranged
- Ongoing management of either the standalone site or the remaining network after extraction
- Recovering shared content that genuinely can’t be attributed to a single subsite
Questions about this fix
Will extracting my subsite affect the rest of the network?
We aim to leave the remaining network untouched, extracting only the specified subsite's data — removing it from the network afterward, if you want that done too, is a distinct, additional step worth confirming.
What happens to content that was shared across the whole network, not specific to my subsite?
Genuinely shared, network-wide content doesn't belong to any one subsite by definition, so it isn't something that transfers with the extraction — we'll flag anything ambiguous for your decision.
What actually makes this harder than pulling a normal WordPress site off a shared server?
The interleaving of shared and subsite-specific data in the same tables is the core difficulty — a standalone site's database is already self-contained, while a subsite's isn't, which is the extra separation work this fix does before the extraction can even begin.
Do I need to reconfigure plugins myself after this is done, or is that handled?
We handle reinstalling and reconfiguring anything that was network-activated so it works correctly as a standalone plugin, though we'd flag any specific behaviour that genuinely depended on the multisite context for you to weigh in on.
Why would I want to extract a subsite instead of just keeping it on the network?
Common reasons include selling or transferring ownership of just that one site, needing hosting resources dedicated to it specifically, or the subsite having outgrown the shared network's original purpose.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.