APUS Content Migration Strategy

Preface: Why not just use the wordpress import/export plugin?

Tasked with the experience of moving several large wordpress installations into a single multisite installation, this was my path during my first attempt. While not having the ability to tweak php/server timeout settings, the servers were completely choking when doing an export of 1,000+ posts, so the process needed to be broken down into exporting a fraction of the posts at a time, which was unbearably slow to the point it just wasn’t feasible. I figured rather than relying on the wordpress import/export plugin & php it would probably be orders of magnitude faster to do it manually by grabbing a snapshot of the dbs and using some SQL queries to get everything moved over.


This document describes the steps taken to migrate content from a wordpress standalone site into a multisite installation. In this document the multisite installation will be referred to as site A and the standalone site will be referred to as site B. This assumes that themes and plugins have been manually copied from the source server to their destination, a password reset of your user account is going to be ok and that your environment is such that you’re able to use ftp to move files from site A to site B.

Multisite = Site A

Standalone = Site B

Create a new site in the multisite installation

Name it accordingly, this is mainly to get a site ID, this id # can be found by going to sites > all sites and hovering over your site and looking at the id that appears in the address bar at the bottom of the screen

Copy all media assets from source server to destination server

[insert file structure references]

Create a new database to be used for staging

We will use this database to stage the data so we don’t have to mess with the multisite or standalone environments in the case that they are currently being used in a live production environment

Import tables into staging database from site B and update prefix with blog ID i.e. wp_##_

At minimum you’ll want to bring the following tables into your staging DB, there may be more i.e. you want to bring data over from comments, gravity forms or another plugin, but these should be the minimum.

  • wp_postmeta
  • wp_posts
  • wp_terms
  • wp_term_relationships
  • wp_term_taxonomy
  • wp_users
  • wp_options

After the tables are imported into your staging environment rename them using your site ID in place of the ## below

  • wp_##_postmeta
  • wp_##_posts
  • wp_##_terms
  • wp_##_term_relationships
  • wp_##_term_taxonomy
  • wp_##_users
  • wp_##_options

Update urls within posts and postmeta with the new wp-content/uploads path

UPDATE wp_##_posts SET post_content = REPLACE (

UPDATE wp_##_postmeta SET meta_value = REPLACE (


Last, but not least, you’ll need to update the User roles, in the wp_##_options table:

Find the wp_user_roles and update it to: wp_##_user_roles. This allows the users to have the same permissions on the multisite subdomain that they had on the stand-alone installation.

UPDATE wp_##_options
 SET option_name = REPLACE( option_name, 'wp_user_roles', 'wp_##_user_roles' );

At this point, everything should be moved over, now onto the tricky part: dealing with the user database. User accounts from the standalone installation need to be merged into the multisite’s user repository if they don’t already exist there and then the posts table needs to have it’s author IDs updated since the user merge we will perform will most likely result in the user accounts having new IDs assigned to them.

Onto the user migration: APUSMS Migration Strategy