Sky planes

A few weeks ago Ruth explained the reasons why we’ve merged all our blogs into one. If you’re interested in knowing all the required steps for completing the migration we described in that post, you’re lucky! ? I have plenty of experience in migrations, and I’m happy to share this post where we go step by step narrating what I’ve done to merge three different blogs. Bear in mind it’ll be a long and technical post, but I promise I’ll do everything in my power not to be a terrible bore ?.

Before migrating, what do we have?

If you’re planning to migrate your website, it’s obvious you should have a clear picture of what you want to achieve. But it’s also very important you know what you already have—I’ve come across many cases where customers had no idea of what they had or what they wanted!

Luckily for me, we knew exactly our starting point and our goal. Let’s start by summarizing very quickly the structure of the sites we had, so you don’t get lost:

  • Nelio Software ( had two or three pages only, including our company homepage, and a blog with more than 200 posts in English. We’re only interested in migrating the blog.
  • Nelio A/B Testing ( contains all the information about our native A/B testing service for WordPress and a blog with over 160 posts in English. We will only migrate the blog posts from here to the new website. Everything else will remain intact, as you can see if you visit Nelio A/B Testing.
  • WPrincipiante ( was a “community blog” with more than 250 posts in Spanish. This website will disappear and the posts will become part of the new Nelio Software website.

Successful migrations also depend on your source and destination CMS—the more similar their structures are, the easier it’ll be for you to migrate them properly without leaving anything behind. From my experience, people who wanted to migrate their websites to WordPress were usually using other CMS systems such as Drupal, Joomla, or custom CMS. In fact, there even were some cases in which the source site was raw HTML! ? These situations require you to define a narrower and more complex correspondence between the source content and its final location. Our migration, though, has none of these complexities—all source websites were WordPress-based, and so was the destination ? Kudos for us! ?

Now let’s talk about the destination WordPress installation and its structure, which has to accommodate all this.

What we want to achieve after the migration

Our main goal was to have a single blog. This involves taking all the posts from the previous websites and merging them into a single WordPress installation—Nelio Software.

Regarding the pages of those websites, we decided to ignore them all and create them from scratch in the new installation. The only exception was Nelio A/B Testing‘s website, which we’d maintain as a separated domain. This service is the one that generates the revenue that keeps Nelio going, so we preferred to be cautious and avoid changes beyond moving the blog posts to the new Nelio Software website. As I said before, these web pages include information on our A/B testing service and link to the payment platform, so this could not be dropped.

Once we had this clear, the main drawback that emerged in the analysis phase was (naturally) how to manage multi-lingual content. Remember WPrincipiante’s posts were in Spanish and the posts from other websites in English. How would we manage this? As you may already know, multi-language support in WordPress is a pain in the ass ? Sure, there’s plenty of solutions available, but none of them seems to be just fine.

Anyway, we studied all solutions in depth: should we use plugins like WPML or Polylang? What about running different WordPress installations for each language? And a WordPress multi-site installation with two sub-domains? The option chosen was to create a WordPress multi-site installation with two sites, one for the English version and one for the Spanish version. The English version would go under the domain and the Spanish version under

Configuration of Nelio's WorPress Multisite.
Configuration of Nelio’s WordPress Multi-site.

This option fits our needs very well and allows us to do everything we want, so it now works perfectly. Note that I don’t mean to say that using WPML or any other plugin isn’t a good choice ?, but we wanted to keep things as simple as possible.

Accordingly, all WPrincipiante posts in Spanish would go to the site. On the other hand, the combination of blog posts from the Nelio Software blog and Nelio A/B Testing, all in English, would go to the site on the multi-site.

Before and after the Nelio migration.
Before and after the Nelio migration.

The chosen migration process

After the above explanation I think it’s pretty clear that the idea was to merge 3 blogs from 3 individual WordPress installations on a new WordPress multi-site installation with two sites, one for English content and one for Spanish content.

This is where the million dollar question comes in: how do we do it? If you’ve ever had to migrate a website to WordPress, you’ve surely sought some plugin to help you import the content to your installation, or even searched for any company or professional to help you with the task.

Regarding plugins, we haven’t found any that do what we needed with the level of expertise we wanted. Neither did we want to try any of the solutions or the automated migration platforms you can find on the web (as many of our customers of had before coming to us). We know they are cheap, but the result is poor.

So, in the end, we preferred adapting the semi-automatic program that we have to do migrations in to deal with the migration of Nelio Software. What a big surprise, huh? ? Without going into boring detail, it’s a Java program that inputs the MySQL database of an installation (WordPress, Drupal, or other) and transforms it into a MySQL database for a WordPress installation. All we had to do is modify the program to accept as input 3 MySQL databases (from,, and and create a single output MySQL database with the content of all 3 blogs merged.

Once the resulting database is ready, we simply need to load it in the target multi-site installation and thus have the migration ready. Therefore, the process of merging and migrating has been as follows:

  1. Export the MySQL database of the WPrincipiante WordPress installation.
  2. Export the MySQL database of the Nelio A/B Testing WordPress installation.
  3. Export the MySQL database of the Nelio Software WordPress installation.
  4. Clean the three previous databases (remove unnecessary tables).
  5. Change the prefix of previous MySQL databases (wp_ by wprincipiante_, abtesting_ and neliosoftware_).
  6. Export the MySQL database of the target WordPress multi-site installation.
  7. Load all the tables from the 4 databases into a new database that will be used during migration.
  8. Execute the migration code that works on the migration database.
  9. Export the migration database in a .SQL file.
  10. Load the resulting .SQL file in the WordPress multi-site installation destination.
  11. Celebrate effusively ?? if everything works as expected.

Most of the previous steps are as simple as “exporting” or “importing” a database. To export, we used phpMyAdmin, which is provided by our hosting provider to automatically access our website databases. If this isn’t so in your case, you can use the Adminer plugin for WordPress, which is very similar to phpMyAdmin. It’s clear that the most controversial and complex point of the whole process is number 8, as it transforms the content and merges it into the target database. But be patient! I’ll explain this point in more detail a little later ?.

To clean the databases, we basically eliminated all the tables that were not important to us. These include tables created by plugins you no longer use (it’s surprising how many plugins create stuff in your database and never delete them, even if you uninstall the plugin!), as well as any other table that won’t be used in the migration. The latter are tables that have no relevant information for the migration, such as, for example, wp_options.

During our migration, the tables we kept were as follows:

  • wp_posts and wp_postmeta, containing the posts.
  • wp_users and wp_usermeta, containing WordPress users.
  • wp_comments, containing comments on the posts.
  • wp_terms, wp_term_taxonomy and wp_term_relationships, containing tags and categories.

After that, we just had relevant tables. The problem was that if we wanted to load all of them in one database, they would crush each other, as they share the same name. That is, if we loaded wp_posts from WPrincipiante in the database and then loaded wp_posts from Nelio A/B Testing, we would have overwritten the first. We did not want this

Replace table prefix in phpMyAdmin.
Replace table prefix in phpMyAdmin.

To fix this, we changed the wp_ prefix for the tables to the name of each installation. In this way we created wprincipiante_posts and abtesting_postsso nothing would get overwritten when loading tables into the same database. To change the prefix of the tables you can also use phpMyAdmin, which has an option for that.

In our case, after taking all these steps (1 through 5) and having exported the database for the WordPress multi-site (step 6), we could load all the tables into a new auxiliary database that would be used during the migration (step 7).

This database contains tables as shown in the following screen capture:

Tables ready before the migration.
Tables ready before the migration.

You can see the three blocks with the table prefixes changed to correspond to the tables of WPrincipiante, Nelio A/B Testing and the old Nelio Software site. In addition, in exporting the tables of the target WordPress multi-site installation you can see that some are prefixed wp_3_,while others have the wp_ prefix.

The first tables are for the site (with content in Spanish) while the others belong to the site (with content in English). It should also be noted that in a WordPress multi-site installation the wp_usermeta and wp_users tables are shared between all sites of the multi-site, which is why you see neither wp_3_users nor wp_3_usermeta.

Nelio A/B Testing

Native Tests for WordPress

Use your WordPress page editor to create variants and run powerful tests with just a few clicks. No coding skills required.

To be continued…

We’ve come a long way. If I, after writing all this, need a break, I’m sure you do too ?. I congratulate you greatly for having endured to the end of this part. You’re now well aware of the first steps required to complete a successful migration—understanding the sites we first had, the problems we had, the decision we made for overcoming them, and how we outlined the initial outline of the process to follow.

I have also introduced the 10 steps (+1, to celebrate ?) for the merge and migration of content, which in this post has reached step 7. We have all the tables loaded in an auxiliary database and everything is ready for the merge.

In the second part of this post we will continue right where we’ve left off. You’ll see in detail how we moved the data from each table above until everything was merged into the WordPress multi-site installation. In addition, in the third part I will explain the subsequent processing that we’ve had to do afterwards to iron out certain aspects and make it spotless. And, not to be remiss, I’ll tell you about the problems we ran into (yes, there were some ?) and how we solved them.

That said, wait for the second part of this mega post, and if you have questions or think we should have done something differently, don’t hesitate to leave us a comment.

Featured image by delfi de la Rua.

7 responses to “How to Merge Multiple Blogs into One—Nelio’s New Website (1/3)”

  1. Mark Fethney Avatar
    Mark Fethney

    Hi Antonio, I’m already thinking that you could merge the tables from the 3 sites into the new sites wp_posts wp_users etc. Would take some funky SQL to do it though. Look forward to reading how it’s done properly :)

    1. Antonio Villegas Avatar

      Hi Mark. Thanks for your comment. Stay tuned for the second part (we’ll publish it next week). I’ll explain the mapping we used to merge the tables ?

  2. Sam Walsh Avatar
    Sam Walsh

    Just quickly, how many hours did it take to do this migration from planning to complete?

    1. Antonio Villegas Avatar

      Hi Sam,

      I don’t remember the exact amount of hours, but the code we programmed was prepared in a day. Then, we executed it with the database exports of the separated blogs to generate the final SQL file with the content merged (that took just a few minutes). And finally, we loaded that file into the database of our current installation (some minutes more). Of course, the process of checking that everything was right took some hours more.

      Let’s say that the whole migration took a couple of days of work.

      1. Sam Avatar

        Hi Antonio,

        Thanks for taking the time to reply. :) I wish I had seen this blog post before I started writing up a migration script. I have little-to-no experience of WordPress, so trying to create a migration script has been quite a difficult and lengthy task. Was interested to hear how long other people took to get the job done.

        Other than small code snippets mentioned in your blog posts, you don’t happen to have any code in a github gist/repo or anything do you, that I could work from? :)


        1. Antonio Villegas Avatar

          Hi Sam,

          I totally understand you. Writing those scripts can be a nightmare. Fortunately for me, I had experience on the topic because I was on charge of Right now there is no code to share, sorry about that.

          1. Sam Avatar

            Not to worry, I appreciate your help anyway. This blog post has been of good use – and has been nice knowing I’m not alone in the nightmare that is wordpress migrations :)

Leave a Reply

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

I have read and agree to the Nelio Software Privacy Policy

Your personal data will be located on SiteGround and will be treated by Nelio Software with the sole purpose of publishing this comment here. The legitimation is carried out through your express consent. Contact us to access, rectify, limit, or delete your data.