From MultiSite to MultiSite by SQL editing

Last night I moved a website from a WordPress multisite on old server to a new domain multisite on new server without being able to access the old dashboard or website, aka from backups.
Firstly I’d like to thank those hard at work on WordPress for making so many improvements since I set up my network waaaay back when. (Sitting in truck in a field of snow with an iPad today.)
I’ve run a WPMU, now WordPress Multisite, since its inception. A carpenter by trade I like ‘building’ and find web development compelling. Finally finished my house and have more time, bought new server space and started a migration of one longstanding Wordpress install running 26 child sites….
Problem is, I have two decades of project sites, several generate a monthly revenue and are considered valuable, that I haven’t added a single post to for almost three years. (Yes, they still spit out $$) but many are extraneous so I’m cleaning house. Trashing useless sites, rebuilding profitable ones, restoring my company portfolio and getting my personal site which crashed a year ago back online. Hey, that’s this website, which I haven’t yet restored but will (after I get the revenue sites back in action…lol who cares about what I do for fun) ..and I have a pulpit once again! I don’t even care what it looks like for now…cheers.
New server. New ‘main domain’. Clean WP 4.x.x install at root (public_html) (different from my olddomain config.)
I don’t mind doing things my own way.
Two sites on the old server were inaccessible. That means no ‘export’ function from the dashboard.
Here’s how I stripped child sites and assigned them new homes in my fresh multisite from backups. (I realize this process necessitates further site reconstruction but I’m rebuilding and relaunching my sites so…)
In some semblance of order:
1.    Install and set up new WPMU – new server, new db, new domain. (, domain mapping plugin. Making server side/registrar adjustments, DNS, etc.
2.    Create the first child site. ( In tables it is (wp_2_)
3.    Edit old WPMU SQL. I didnt want want to mess with anything other than the one sub-site so I looked at the multisite SQL and took only the subsite’s tables (wp_10) and copied to a blank SQL to work on. [There are several find and replace changes to be made. They are common sense locational references to file structure and domain paths. Both of mine changed.] 1) Change site # (from wp_10 to wp_2), Change URL references first then file location references, cumulatively effecting ( to ( (separate steps to avoid too general of a statement and use longer strings than just wp_2. Meaning, know what and why you are changing it don’t just willy-nilly blanket change) and..there was one more I learned after importing due to using NextGen gallery plugin, my photos folder used a different title than the current (fresh) default.
4.    Import SQL tables to new server db. My new SQL script contained only vital tables referencing thousands of posts and photos via nggallery. I found that replacing all fresh wp_2 tables with old (wp_10 converted to wp_2) overwrote something important so I selectively imported tables by creating a new SQL, using the new wp_2 tables from a backup of the new server db and inserting my ‘find and replaced’ tables then uploading the new wp_2 combined tables SQL. Just think about it a little, since I don’t know much about the code I just know what I’ve added (my content) so that is what I address in the find and replace. It took three tries and about 30 minutes to import this site. It’s clean, all posts and comments and all thumbnails, galleries and links are good!
5.    Step 5 would be to move the files from to their new location if you hadn’t.
This obviously isn’t a guide but I moved from a full multisite db SQL to along with a frest NextGen Gallery install that correctly references thousands of photos. It’s all there and it all works. Not bad for someone without an ISP.
Thank you WordPress Team for making this so easy.

Update: I did it again today. …from a (crashed) subsite to the main domain or root-level site by SQL. sweet.

Published by

Network Admin

responsible for network administration

Leave a Reply

Your email address will not be published. Required fields are marked *