How to Move a WORDPRESS Web Hosting Blog With Duplicator

Today I’m going to explain how you can move WordPress hosting in a really comfortable way thanks to the great free plugin of Duplicator.

If you do it by the “traditional” way, over a WordPress blog from one hosting service to another, although it is not a tremendously complicated task, it does involve a series of steps that for a not very technical person can be made somewhat complicated.

However, with Duplicator the thing is limited to create a backup of the blog in the source hosting (a click on a button in Duplicator), restore it in the destination hosting and do a series of operations to adapt the copy to the specific configurations of the new hosting.

We’re talking about simply changing the name and user of the database you use on the new hosting or, in the case of a change of domain, making the necessary changes in the WordPress settings for the blog to work properly under this domain (two parameters).

That’s basically the whole process, but let’s see it better step by step, with the specific screens you’ll go through.

What do you get out of using Duplicator?

But for a person who has no knowledge of the technologies that WordPress uses (especially in PHP and MySQL database) the reconfiguration part is not so trivial anymore and, above all, it can be complicated by factors such as the specific plugins that the blog to be migrated uses. To see a concrete example, take a look at this comment.

The value of the Duplicator plugin is that it does all these things for you by isolating you from the cumbersome complications of technical details, especially the more difficult part I mentioned earlier.

In addition, they have had an idea as simple as great that is to generate a custom installer, ie the idea of the plugin is that it generates two files that copy in your new hosting and accessing via web to one of them starts an installation process with the typical step-by-step wizard which makes the process of installation or creating a clone of your blog in another site (for example, to have a test version) in something really comfortable.

Moving a WordPress web hosting blog with Duplicator

So let’s see how the process works:

1. Hire your new hosting

First of all, you need to have logically hired the new hosting to which you want to migrate.

A very important piece of advice that many people put their foot in it: don’t cancel your current hosting until the migration is 100% complete, that is to say until you have checked that everything is fine.

I have met more than once with people who have made the backup (with Duplicator or other tools) to find themselves with problems not being able to restore it and with the previous hosting canceled and, therefore, without being able to create a new copy.

On the other hand, hire a quality hosting. They are affordable and the difference in price with a disastrous hosting is 3 or 4 euros per month at most. Therefore, it’s ridiculous to hire a crappy hosting for this money if you are with a serious project.

2. Install the plugin in the blog you want to migrate

The first thing is to install the Duplicator plugin in the blog you want to migrate, you can install it from WordPress (screen to add new plugins and search for “Duplicator”). Also make sure that it is the plugin of the company LifeInTheGrid.

The other option is to download it from this link and install it using the “Upload” option on the same screen.

3. Create an installation package

Once the plugin is operational, you have to create an installation “package” (the two files I mentioned above). One very useful thing is that, if you want, you can create several packages on different dates and/or different configurations which allows you, for example, to keep different “photos” (snapshots) of your blog.

A trick:

As Duplicator can consume a lot of resources during the creation of the package, with a bad hosting it’s easy to have a memory error.

To avoid it, disable all the plugins you can and optimize your database with a plugin like Optimize Database after Deleting Revisions, and if you have any kind of garbage among the files of your WordPress installation (obsolete download files, etc.), clean it too.

If all this doesn’t work either, you will have no choice but to do without Duplicator and use the option to migrate with backups (see index of this series).

These files, once created, are downloaded to your computer.

4. Create the database on your new hosting

Before you can do the installation process, you must have a MySQL database for WordPress operational. Create it with your hosting tools, then create a database user and assign it to the database with full permissions.

Once this is done, write down the name of the database, the username and the password of the user because you will need this data next.

5. Upload the installation package files to your new web hosting server

Now it’s time to place the installation package files you downloaded earlier in the root directory of your new server, usually, this will be a directory like “public_html” or “www”. Below you can see an example for our hosting.

Note: I’m assuming the usual case of an installation in the root directory of the hosting, in case you want to use your own directory for WordPress, check these instructions.

6. Install the “clone” of your blog

Now it’s time to install the blog in the new hosting. Before doing the final installation, it is advisable to do a test to make sure everything is going well.

Here you will get a lot out of Duplicator because it eliminates a complicated problem you have when you want to try a “clone” of your blog in another server.

The problem is as follows:

Let’s say your blog has the domain “www.blogpepito.com”. If you want to test a copy or “clone” of the blog on your new server you’ll find the problem that the blog is configured for that domain and therefore only works under a server that uses that domain.

At first, your new hosting server will not have that domain available until you have changed the domain so that it stops “pointing” to the old server and points to the new one.

In fact, when you hire a new hosting, so you can work, they usually assign you some kind of temporary domain or directly an IP address. Your new blog could typically have a web address as “ugly” as this one:

http:// 50.104.193.93/~pepito

On the other hand, if you change your domain to this new server (we’ll see how it’s done later), then you’d already be running in real with the new blog installation. That is, the blog that would be seen on the Internet would already be the copy that you have installed on the new server.

So how do you go about testing before you make the change and making sure everything is fine with the new installation?

For this, you would have to “dip” into the WordPress copy in several places so that WordPress uses the temporary address (the “ugly” address from before) which, if you don’t already have some practice with the technical part (manipulating the database, etc.) is a good mess.

However, by using Duplicator, this plugin knows how to do these things for you and you forget about the problem.

So knowing this, we can already start with the installation of the clone in the new server. To do this you just have to access via web to the file “installer.php” the temporary domain of your new server.

That is, if it were the domain, the previous example would be, it would be accessed like this:

http:// 50.104.193.93/~pepito/installer.php

This starts the Duplicator installation wizard, which has 3 steps. Remember that, to be able to do a test, as domain of the blog we will use the temporary domain that you have been given in your new hosting.

Follow the instructions that you can see in the following screenshots, the domain that:

Step 1: Set up database access

Step 2: Adjust the domain name

Step 3: Configure database access

Now, if you access the temporary address of your new hosting, i.e. in our example, http:// 50.104.193.93/~pepito, you will see the main page of your blog and will be able to browse the clone as if it were the original.

7. Test that the installation is correct

The process you’ve seen here is usually done without major incidents. A “normal” blog, that is, simple, without many plugins or custom code, should not give any problem and work at first.

But the more complex a blog is (dozens of plugins, custom developments, etc.) the more likely it is that you will have a problem. So let’s look at the most typical things that could happen to you in this case.

7.1. Finding broken URLs

The first step to check if the migration has gone well is to see if you have broken URLs or some kind of malfunction. To do this, take a first look at the posts and pages, edit posts and publish some test texts, make some comments to yourself, etc.

That is, make sure that, at least, the basic functions are OK and during the process always check that the URLs are what they should be (that you are not jumping, for example, to the “good” domain of the original blog).

A very good trick to have the first view is to use the Web Page Test service, in this page you can do a quick speed test of your blog, but also it provides you a very detailed result graph where you see exactly each of the requests to the server that are made for each page (usually tens, sometimes hundreds).

This allows you not only to see the time of each and detect bottlenecks, but also to detect very fine problems like, for example, that certain image or auxiliary files like CSS style sheets don’t load (error 404) and therefore indicate some kind of error in your blog.

If you do this test a little bit thoroughly and you don’t see anything strange, it’s very likely that there have been no incidents. In any case, errors resulting from using a temporary URL usually disappear when you set up the blog with a good domain.

7.2 Problems with plugins, themes, and widgets

If you have a lot of plugins, you can make some of them fail.

For example, in our case, we use about 25 and in the test migrations I did with this same blog I found that our cache plugin (WP Super Cache) gives problems.

It’s an excellent plugin that gives us very good performance results, but they have fallen into the bad practice of introducing a dependency on the username of the hosting that is described herein more detail and that in the cloned blog caused the error that you can see below.

This means that if your user “nugget” in the old hosting and, for whatever reason, now has to be “nugget” in the new hosting, this plugin is going to give you problems.

In these cases I recommend you to do the following:

  • Go to your original blog and disable the plugin(s) in question and create a new installation package.
  • You repeat the installation under the temporary domain.
  • If you can now log into your blog’s administration without problems, delete the problematic Plugins and install an “orphan” option cleanup Plugin (Plugin configuration options that no longer exist, but remain in the WordPress database). A Plugin that does this automatically would be, for example, Garbage Collector Plugins.

8. Final installation

Once you have debugged the process, instead of adapting the test installation, my recommendation is that you start again from scratch by completely deleting the test installation (including the database). It’s only 10 minutes of work and you’ll have it all cleaned up. In case you had problems with URLs or plugins, remember to repeat what you did before.

Now you repeat the installation process, but with the good domain, this means that you have to edit the domain by hand in step 2 of the Duplicator wizard (see the screenshot of step 2).

But watch out, now your blog will not work in the new one until the server is changed, which we see now.

9. Changing the name servers

With the blog ready to go, the only thing left to do is to see it on the Internet.

This is where name servers (or DNS servers) come into play. They are responsible for associating a domain with a particular server, simplifying a little, you could say, to “point” the domain to a server or in other words: associate a domain with an IP address.

Here are three issues that you must have clear to understand how this part works:

  • From your domain hosting service (where you bought the domain) you have to configure which DNS servers that domain should use (it can be your old hosting provider or service specialized in domains like Namecheap or GoDaddy).
  • The DNS servers that your domain should use now will be those of your new hosting provider. You have to ask your new hosting provider which are your DNS servers and the domain provider (which, as we have seen, maybe the same one) to configure the domain to use those new DNS servers (usually this information is already provided to you in a welcome mail to the service or something similar)
  • A DNS server change takes several hours to complete. That is, if you change the server your domain is pointing to, this change will take a few hours to become effective.

Once these changes are done, you will have your domain “hooked” to your new server and everything is ready to work but remember that due to the delay, some users will see your old blog and others will already see the new one until the propagation is completed and everyone sees the new one.

If you’re not happy with your old hosting provider because that’s where the domain is still, consider transferring your domain.

Actually, it’s okay because they’re identical copies, just minor complications of migration, such as a user commenting on your old blog (you could temporarily disable comments on both blogs until propagation is complete).

10. Checking the new blog and final tips

If you want to do a thorough check (it’s a job, but highly recommended), apart from doing the previous check with the Web Page Test, I recommend you use a link checking tool. There are many, but one of the ones that I find more practical for this case is the LinkChecker, a free software application. The difference is that a tool, unlike Web Page Test, checks your entire blog, not just a specific URL.

It is very important that you test both your original site and the new one since it is more than likely that you already had broken links in the original blog and this could lead you to confusion by making you think that they are broken because of a migration problem when, in fact, they were already broken beforehand.

Furthermore, unless your blog has little content or you have maintained it rigorously (for example, with a plugin like Broken Link Checker), I guarantee that you will have broken links of this type, especially in outgoing links.

Conclusion

All these things you’ve been able to see here, actually, are pretty simple. They are only complicated in exceptional cases, but if you have never done something like this it is normal that at first, they impose a little respect.

Remember that choosing a good hosting provider such as Webempresa is essential, not only to have a good service but to give you a hand in the migration process and when your blog is up and running, always have good support to solve technical issues (which will be).

Besides, with good hosting, the migration is done by them if you want, although I recommend to try it first yourself to acquire that experience and because in the adjustments of the details it is always better to be involved in the first person.

Then they will help you with the configuration part of the DNS server change and also with other details related to the hosting configuration so that everything is ready and configured in an optimal way.

What to do if you have problems with Duplicator?

In case you have any problem with Duplicator, which can happen depending on the type of hosting you use, you can go to Duplicator support for help.

And if things get ugly and you can’t solve your problem, you can also choose to use XCloner, a plugin very similar to Duplicator. With one of the two, you should always be able to get ahead.

Leave a Comment