Today I will explain how you can move WordPress to hosting a truly so very comfortable thanks to the magnificent plugin free of Duplicator.
If you do it the “traditional” way, over a WordPress blog from one hosting service to another, although it is not a tremendously complicated task either, it does involve a series of steps that for a not very technical person can become somewhat complicated.
However, with Duplicator, the thing is to create a blog backup in the source hosting (a click of a button in Duplicator), restore it in the destination hosting and do a series of operations to adapt the copy to specific configurations. Of the new hosting.
We are simply talking about changing the name and user of the database that you use in the new hosting or, in the case of a domain change, make the necessary changes in the WordPress configuration so that the blog works correctly under this domain (two parameters).
That is basically the whole process, but let’s see it better step by step, with the specific screens you are going to go through.
What does using Duplicator bring you?
But for a person who does not have knowledge in the technologies that WordPress uses (especially in PHP and the MySQL database) the reconfiguration part is no longer so trivial and, above all, it can be complicated by factors such as plugins concrete that use the blog to migrate. For a concrete example, take a look at this comment.
The value of the Duplicator plugin is that it does all these things for you, isolating you from the cumbersome complications of technical details, especially the most difficult part I mentioned before.
In addition, they have had an idea as simple as it is great that it is to generate a custom installer, that is, the idea of the plugin is that it generates two files that you copy in your new hosting and accessing one of them via the web starts a process of installation with the typical step-by-step wizard which makes the process of installing or creating a clone of your blog somewhere else (for example, to have a test version) really comfortable.
Moving a WordPress web hosting blog with Duplicator
Let’s see then how the process works:
1. Hire your new hosting
First of all, you need to logically have the new hosting you want to migrate to.
A very important tip that many people screw up: do not unsubscribe your current hosting until the migration has not concluded 100%, that is, that you have verified that everything is fine.
I have met more than once with people who have made the backup (with Duplicator or other tools) to later find themselves with a problem not being able to restore it and with the previous hosting unsubscribed and, therefore, without being able to recreate one new copy.
On the other hand, hire quality hosting. They are affordable and the price difference with a disastrous hosting is 3 or 4 euros a month, at most. Therefore, it is ridiculous to hire a crap for money if you are with a serious project.
My recommendation is that you hire either Ionos (the hosting of this blog) or Hostgator.
2. Install the plugin on the blog you want to migrate
The first thing is to install the Duplicator plugin on the blog you want to migrate, you can install it from WordPress (add new plugins screen and search for “Duplicator”). Also make sure it is the plugin from the company LifeInTheGrid.
3. Create an installation package
Once the plugin is operational, you have to create an installation “package” (the two files mentioned above). One very useful thing, by the way, is that, if you want, you can create several packages on different dates and / or with different configurations, which allows you, for example, to keep different “photos” (snapshots) of your blog.
As Duplicator can consume a lot of resources during the creation of the package, with bad hosting it is easy that you have a memory error.
To avoid this, deactivate all the plugins you can and optimize your database with a plugin like Optimize Database after Deleting Revisions, and if you have any type of garbage among the files of your WordPress installation (obsolete download files, etc.), clean it too.
If all this does not work either, you will have no choice but to do without Duplicator and use the option to migrate with backup copies (see index of this series).
These files, once the package is created, you download them to your computer.
4. Create the database in your new hosting
Before you can do the installation process, you have to 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 all 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 information below.
5. Upload the files of the installation package to the server of your new web hosting
Now it’s time to place the files of the installation package that you have downloaded before in the root directory of your new server, normally this will be a directory like “public_ html” or “www”.
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 recommended to do a test to make sure that everything is going well.
Here you are going to get a lot out of Duplicator because it eliminates a complicated problem that you have when you want to test a “clone” of your blog on another server.
The problem consists of the following:
Let’s say that your blog has the domain “www.blogABC.com”. If you want to test a copy or “clone” of the blog on your new server, you will encounter the problem that the blog is configured for that domain and therefore only works under a server that uses that domain.
At first, the server of your new hosting 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 that you can work, they usually assign you some type of temporary domain or directly an IP address. Your new blog could typically have a web address as “ugly” as this:
http: // 220.127.116.11/~ABC
On the other hand, if you change your domain to this new server (later we see how it is done), then you would already be working 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.
How then to calmly test before making the change and make sure that everything is fine in the new installation?
Well, for this you would have to “get your hands” on the WordPress copy in several sites so that WordPress uses the temporary address (the “ugly” address from before) which, if you do not already have some practice with the technical part (manipulate the database data etc.) is a good mess.
However, when 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 installing the clone on the new server. To do this you just have to access the file “installer.php” via 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: // 18.104.22.168/~ABC/installer.php
This starts the Duplicator installation wizard and it has 3 steps. Remember that, to be able to do a test, as a blog domain we are going to use the temporary domain that you have been given in your new hosting.
Follow the instructions in the following screenshots, the domain that:
Step 1: configure access to the database
Step 2: adjust the domain name
Step 3: configure database access
Now, if you access the temporary address of your new hosting, that is, in our example, http: // 22.214.171.124/~ABC, you will see the main page of your blog and you will be able to browse the clone as if it were the original.
7. Test that the installation is correct
Normally, the process you have seen here is done without major incidents. A “normal” blog, that is, simple, without many plugins or custom code, should not give any problem and work the first time.
But the more complex a blog (dozens of plugins, custom developments, etc.) increases the probability that you have a problem. So let’s see the most typical things that could happen to you in this case.
7.1. Find broken URLs
The first measure 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 turn browsing the posts and pages, edit posts and publish them some test texts, make a comment to yourself, etc.
In other words, make sure that, at least, the basic functions are correct and during the process always check that the URLs are what they have to be (that you are not jumping, for example, to the “good” domain of the original blog).
A very good trick to have a first vision is to use the Web Page Test service, on this page you can do a quick speed test of your blog, but it also provides you with a very detailed results graph where you see exactly each of the requests to the server that is made for each page (they are usually tens, sometimes hundreds).
This allows you not only to see the time of each and detect a bottleneck, but also to detect very fine problems such as, for example, certain image or auxiliary files such as CSS style sheets do not load (error 404) and therefore indicate some type of error on your blog.
If you do this test a little thoroughly and you do not see anything strange, it is very likely that there were no incidents. In any case, the errors derived from using a temporary URL usually disappear when you configure the blog with the good domain.
7.2. Problems with plugins, themes and widgets
If you have many plugins it can make some of them fail.
For example, in our case, we used about 25 and in the test migrations that I did with this same blog, I discovered that our cache plugin (WP Super Cache) gives problems.
It is an excellent plugin that gives us very good performance results, but they have fallen into the bad practice of introducing a dependency on the hosting username, which is described in more detail here and which caused the error you can see in the cloned blog. Continuation.
This definitely means that if your user “ABC” in the old hosting and, for whatever reason, now it has to be “so-and-so” in the new hosting, this plugin will give you problems.
In these cases my recommendation would be to do the following:
- You go to your original blog and disable the plugin or plugins in question and create a new installation package.
- You repeat the installation again under the temporary domain.
- If now you can easily enter the administration of your blog, delete the problematic plugins and install a plugin for cleaning “orphan” options (plugin configuration options that no longer exist, but are still in the WordPress database). A plugin that does this automatically would be, for example, Plugins Garbage Collector.
If you still have problems, then the time has come to ask for professional help…
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 erasing the test installation (including the database). It is only 10 minutes of work and you will have everything clean. In the event that there have been problems with URLs or plugins, remember to also 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 from step 2).
But beware, now your blog will not work on the new one until the server until the nameservers are not changed, which we see now.
9. Change the name servers
With the blog ready to go, we only have to see it on the Internet.
Name servers (or DNS servers) come into play here. They are in charge of associating a domain with a specific server , simplifying a little, it could be said, to what they “point” the domain to a server or in other words: they associate a domain with an IP address.
Here are three topics that you must be clear about to understand well how this part works:
- From your domain hosting service(where you have purchased the domain) you have to configure which DNS servers that domain should use (it may be your old hosting provider or a specialized service in domains like Namecheap or GoDaddy).
- The DNS servers that your domain must use now will be those of your new hosting provider. You have to ask your new hosting provider what your DNS servers are and in the domain provider (which, as we have seen, may be the same) configure the domain to use those new DNS servers (normally this information is already provided to you provided in a welcome email to the service or something similar)
- A change of DNS servers takes a delay of several hours. That is, if you change the server pointed to by your domain, this change will take a few hours to take effect.
Made these changes, you will have your domain “hooked” to your new server and everything is ready to work, but remember that due to the delay for a few hours some users will see your old blog and others will see the new one, until the propagation has been completed and everyone see the new one.
If it bothers you to continue having an account in your old hosting provider since that is where the domain continues, consider the possibility of transferring your domain.
Actually, nothing happens because they are identical copies, the only thing is minor complications typical of a migration, for example, that a user comments on your old blog (you could temporarily disable comments on both blogs until the propagation has finished).
Therefore, do not close your old blog until this process has concluded.
10. Checking the new blog and final advice
If you want to do a thorough check (it is a job, but highly recommended), apart from doing the previous check with Web Page Test, I recommend that you use a link checking tool. There are many, but one that seems most practical to me in this case is LinkChecker, a free software application. The difference is that a tool, unlike the Web Page Test, checks you on your entire blog, not just on 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 to confusion, making you think that they are broken due to a problem with migration when, in Actually, they were already broken beforehand.
What’s more, unless your blog has little content or you have rigorously maintained this topic (for example, with a plugin like Broken Link Checker), I guarantee that you will have broken links of this type, especially in outgoing links.
All these things that you have been able to see here, in fact, are quite 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 , for example, Ionos is essential, not only for having a good service later, but also to give you a hand in the migration process and when your blog is up and running, always have A good backup to solve technical incidents (which there will be).
In addition, with good hosting, the migration is done by them if you want, although I recommend trying it yourself first to acquire that experience and because in the adjustments of the details it is always better to be involved yourself in the first person.
Then they will help you with the configuration part of the change of DNS servers and also with other details related to the configuration of the hosting so that everything is ready and configured optimally.
What to do if you have problems with Duplicator?
In the event that you have any problem with Duplicator, which may happen depending on the type of hosting you use, you can go to Duplicator support for help.
And if things get ugly and can’t solve your problem, you can alternatively choose to use XCloner, a plugin very similar to Duplicator. With one of the two you should always get ahead.