This can be somewhat tedious, but hopefully this helps. The less that changes from one environment to the next, the less painful this process will be. Particularly, if the domain, site id, file paths remain the same, the less painful this process will be.
This post assumes some knowledge of database management. It is not a complete step by step because you should search the forums and possibly create a thread specific to whichever step you are having trouble with, e.g., if you need help with exporting a database table.
The most important thing to do is backup your entire database and files for both the local dev site and the new location in case something goes wrong. Expect something to go wrong. Be pleasantly surprised if it doesn’t.
Moving your theme files should be pretty straightforward. Upload your theme files to the wp-content/themes directory and activate it as usual. I’m assuming this is a shared theme that all blogs have access to.
Upload plugin files to wp-content/plugins at the new location. Don’t activate them yet.
Note that any content exclusive to the blog you are migrating will be located in a directory that looks like wp-content/blogs.dir/2/files where 2 is the site id. If it is possible to maintain this site ID at the new location, it should help to minimize conflicts in the database after migrating to the new location. Otherwise, you will have to update your database to reflect the new path.
You will need to export the multisite tables related to the blog you are trying to migrate and import them to the new location. You will have to edit the tables which store data related to the blog you are migrating. Make sure that the prefix of these tables is the same at the new location.
For example, the wp_blogs table for your blog contains the blog id, site id, domain and path that allows WordPress multisite to recognize and work with your blog. Edit any of these that are no longer correct to reflect the new location, but please read the rest of this post before attempting to do so.
To migrate your WordPress and plugin settings for the blog to be transfered, you will need to deactivate all plugins locally, then export your site specific tables (codex reference), including those for your plugins. Import these tables to the new location’s database.
Make sure the new location uses the same database prefix as the tables you are importing. The prefix will contain the site id for your blog and look something like wp_2_options, wp_2_posts, wp_2_postmeta.
See Exploring WordPress Multisite by Lisa Sabin-Wilson
I’m assuming you know how to import/export via phpmyAdmin or with the mysqldump command in your terminal. That’s a bit beyond the scope of this post, but here is an export example that should help.
From How do you mysqldump specific table(s)? (Syntax edited slightly to be more clear.):
If you are dumping tables t1, t2, and t3 from database named mydb
mysqldump -u <username> -p <password> mydb t1 t2 t3 >
mydb_tables.sql
Before activating plugins on the new site, go to your permalink settings in admin cp and save the settings to update the database files to the new site url. Activate your plugins and see if there are any issues.
One issue you may run into is with data serialization in your tables.
“[…]References to the old domain name or location will remain in the database, and that can cause issues with links or theme display.
If you do a search and replace on your entire database to change the URLs, you can cause issues with data serialization, due to the fact that some themes and widgets store values with the length of your URL marked.” When Your Domain Name or URLs Change
Keep in mind that data serialization may cause a conflict in database tables relating to your plugins as well. Rather than performing a manual search and replace on the url stored in the database, use the database search and replace script recommended in the previous codex link. If there are only a few instances of serialization in the database, you can just edit them manually via phpMyAdmin or whatever your preference is for managing your database.
One more issue that you may encounter is that any incorrect file paths stored in database tables will need to be updated to reflect the new location. This could be the case for media directories or directories used by plugins depending on how the plugin was designed. Again, you will want to use the search and replace script to ensure there are no serialization conflicts while updating the file paths. Alternatively, you can go through your tables and update them manually.