Changing hosts is frightening, and reasonably so: you are moving a site that works to a place where you do not yet know whether it will work. But it is a well-known procedure with an established order, and if you respect that order you lose nothing. Migration disasters are almost always sequencing problems, not technical difficulty.
Assisted migration: what support does
The simplest approach is to ask for it. You open a ticket with the access details for the previous host and the team copies the files, the database and the mailboxes into the new account.
What you need to hand:
- Login details for the previous provider's control panel, or a full backup if you have already left.
- The list of domains and subdomains that have to come across.
- The mailboxes that exist, if you want to keep them.
It is noticeably simpler when the previous provider also ran cPanel, because the backup format matches and the transfer is practically automatic. If you are coming from a proprietary panel it is more hands-on, and it is worth flagging that from the start.
One detail that prevents misunderstandings: migration copies what was there. If your site was slow or had a broken plugin, it will be exactly the same on the other side. Migrating repairs nothing, and it is reasonable that it does not.
The correct order, which is the only thing that matters
Here is the heart of it. The correct sequence is this, and it does not get rearranged:
1. Buy the new hosting. Without touching the old one. The two services coexist for a few days; that overlap is deliberate and cheap compared with what it prevents.
2. Everything is copied to the new server. Files, database, mailboxes.
3. Test the site on the new server before it exists publicly. This is the step separating a tidy migration from a disaster. You do it using the temporary address the host provides, or by editing the hosts file on your computer so only you see the new version while the rest of the world stays on the old one.
What to check during that test: the homepage and several inner pages, that images load, a contact form actually submitted, the full checkout process if it is a shop, admin panel access, and any pages that read from the database.
4. Only now, point the domain. You change the name servers to the new host. From that moment propagation begins, which can take from a few hours to a full day.
5. Wait without touching anything. During propagation, some visitors reach the old server and some the new one. That is normal and temporary.
6. Keep the old hosting active for a few more days. At least a week. It is your safety net and it costs little.
The mistake that ruins shop migrations
This deserves its own section because it is the most expensive and the most common: pointing the domain first and migrating afterwards.
It sounds logical ("connect first, then upload"), and it is exactly backwards. During the propagation hours there are two servers answering for the same domain. On an informational site that is annoying but recoverable. On a shop, or any site that receives data, it is a serious problem: half the orders land in the old database and half in the new one. There is no clean way to merge them afterwards, and you will find out from a customer chasing an order that does not exist.
The rule, then: the domain is pointed last, once the new site is tested and working.
For shops there is one extra step worth taking: put the shop into maintenance during the transfer window, at your quietest hours. A few hours without selling is infinitely better than lost orders.
Email, the part everyone forgets
Moving email causes the most problems and gets the least planning.
Old messages do not travel by themselves. If your accounts are configured in a program that downloads and deletes from the server, the messages are on your computer and there is nothing to migrate. If they live on the server, they have to be copied, and that takes time when years have accumulated.
During propagation, mail is split. Some messages will reach the old server and some the new one. That is why you keep the previous hosting active: so you can log in and rescue whatever landed on the other side.
Make a copy before you start. If email matters to you, download everything before moving anything. It is the irreversible part of the operation.
After migrating, check the configuration on your devices. The incoming and outgoing server names change, so they need updating on your phone and in your desktop mail program.
What to do the day after
Check the security certificate. It is the first thing that breaks in a move: the site ends up without the padlock. Activate it on the new host as soon as the domain propagates.
Review internal links and images. Sometimes absolute addresses are left pointing at the old server. Browsing a few pages reveals it immediately.
Set up backups at the new provider. Do not assume they are running; go in and confirm.
Check forms and outgoing mail. Forms commonly stop sending after a migration because of a sending configuration detail.
Look at your search tools a week later. If the transfer was clean and the addresses did not change, you should see no drop. If errors appear, they are almost always pages that were never copied.
Do you lose search rankings by migrating?
No, provided the page addresses do not change. Google indexes addresses, not servers; as long as each page keeps answering at the same address with the same content, there is no reason for anything to happen.
What does hurt is having the site down for many hours, changing the address structure in the same move, or losing pages in transit. That is why you should not use a migration as an opportunity to redesign: they are two separate projects, and if you do them together and something goes wrong, you will not know which one caused it.