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

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 (neliosoftware.com) 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 (nelioabtesting.com) 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 (wprincipiante.es) 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 https://neliosoftware.com and the Spanish version under https://neliosoftware.com/es/.

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 neliosoftware.com/es/ 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 neliosoftware.com site on the multi-site.

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 migratetowp.com 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 migratetowp.com 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 migratetowp.com, nelioabtesting.com, and neliosoftware.com) 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
?.

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_posts, so 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:

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 neliosoftware.com/es/ site (with content in Spanish) while the others belong to the neliosoftware.com/ 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

I was very impressed by the quality of this plugin, how easy it was to set up, and the outstanding support Nelio provides. I highly recommend Nelio A/B Testing.

Josette Millar

WordPress.org

View Plans

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.