Moving between hosting providers feels risky because the common story is bad: a site disappears for a day, email stops for a week, and the incomplete backup cannot be restored. The move itself is not the dangerous part; the order of steps is. This guide runs the migration with almost no downtime and a rollback point if something goes wrong.

First: know what you have

Open the current panel and write down: the PHP version you need, the databases and their names, the site folders, the mail accounts, and any scheduled jobs. Then keep a full copy of the files and a SQL dump of the database. That copy is not only a backup, it is the working copy you will upload to the new server. How to take it and verify it is sound is in the backup plan.

A timeline that removes surprises

  • Day one: create the new hosting, upload files, import the database, and create the user and mailboxes. Do not touch the domain yet.
  • Day one too: test the site on the temporary link the host gives you, or through a hosts file on your machine. Test the homepage, one inner page, the contact form, and the dashboard.
  • Day two: lower the TTL on domain records to 300, then change only the A and www records. The waiting behaviour is explained in DNS propagation and TTL.
  • Day two: issue the SSL certificate and confirm https and www together.
  • Day three: watch: do forms arrive, does mail work, are there 500 errors in the log?
  • After stability: raise TTL again, and close the old hosting after a week, once traffic and mail logs confirm the move.

A checklist before you switch

Before touching the domain record, confirm five items: the site opens on the temporary link, the contact form sends and arrives, the database works after the config change, mail works or a mail plan is ready, and the certificate is installed on the new name. If any item fails, postpone the switch; postponing an hour is cheaper than rolling back a day. Keeping this list in one file turns the migration into execution rather than memory.

What about search rankings?

Moving the site itself does not hurt rankings when the address stays the same: the domain is unchanged, the paths are unchanged, the content is unchanged. The real risks are leaving two copies live with no clear signal, or serving 500 errors right after the switch, which erodes the crawler's trust. After the move, check the sitemap, confirm internal links resolve, and keep server errors at zero for the first day.

What does not move by itself

Three things are always forgotten: databases tied to a different username, scheduled jobs that ran on the old server, and mail records. Files upload, but the database needs the config file adjusted in the new folder, and jobs must be recreated by hand. After the move, test: contact form, user registration, outbound mail, and any scheduled task.

What to do if things go wrong

The whole reassurance of a migration fits in one word: rollback. Do not close the old host before a week, and do not change nameservers if a record change is enough. If an error appears that you cannot explain, point the A record back to the old address, wait out the TTL, then study the problem calmly. The only precondition is a valid, tested copy of files and database before the switch, not after.

Email: the most fragile part

If your mail lives on the same host, move it before the site, or keep mail on an independent provider. Change MX records at a low-traffic hour, and test sending and receiving to an outside address. Enable SPF and DKIM on the new server as described in the email authentication guide, because a migration re-tests everything almost from scratch.

How to know the move is really done

Not when the page opens on your machine, but when three things settle: an external checker shows answers from the new server in several locations, the new server logs show real visitors rather than your tests, and mail flows in both directions. Only then raise TTL and stop the old host. A site that works for you alone is not a migrated site.