How to Request a Free Website Migration from Another Provider

Ahosting migrates sites from another provider free of charge. Opening a ticket and providing access is nearly always better than doing it yourself. A cPanel-to-cPanel transfer carries files, databases, email accounts with their messages, forwarders, cron jobs and DNS in one operation, and doing it by hand routinely loses the email and the cron jobs.

What to gather before opening the ticket

Providing these in the first message is the difference between a migration completed today and three days of back-and-forth.

The old host's control panel login: URL, username, password. If it is cPanel, say so; that is the easiest case by a wide margin.

The domains to move, listed explicitly. An account often holds more than the one you are thinking of.

Whether email is included. If mailboxes should move with their existing messages, say so; this changes the approach.

Where the domain is registered, since the nameserver change happens there and it is frequently a different company from the old host.

Anything unusual. A non-standard application, a scheduled task that must keep running, a service connecting to the database from outside.

Change the old host's password to something temporary before sharing it, and change it back afterwards. That is ordinary practice and no reasonable host will mind.

What happens

Support connects to the old host, transfers the account, and restores it here. You are told when it is done.

Timing depends on size and on how cooperative the old host is. A small site is often the same day; a large one or an awkward source takes longer. Ask for an estimate rather than assuming.

Your existing site stays live throughout. The migration copies; it does not move.

Test before changing anything

When support says it is complete, test the copy while the domain still points at the old host.

Add a hosts file entry mapping the domain to the new server's address. Your machine loads the new server; everyone else keeps reaching the old one.

Then browse it properly: homepage, a deep page, an archive, a form, the admin area, and checkout if there is one. Check images load and that the site is not half-styled.

Report anything wrong now, while the live site is untouched. Fixing a migration is straightforward before the switch and stressful afterwards.

Then change the nameservers

Only once the test passes. Change them at your registrar to the two in your welcome email.

Propagation takes up to 24 to 48 hours, and during that window visitors reach one server or the other depending on their own DNS cache.

Keep the old hosting for at least a week. Orders, form submissions and mail arriving during propagation may land on the old server, and this is where things genuinely get lost. Do not cancel the old account the same day.

After the switch

SSL. Certificates do not travel. Once the domain resolves here, run AutoSSL; it could not have succeeded earlier, because the authority could not reach the domain here.

Email. Send a message from outside and confirm it arrives. Then check SPF and DKIM, which referenced the old host and are now wrong. This is why mail from a freshly migrated site so often goes to spam. Understanding SPF, DKIM and DMARC explains regenerating them.

Backups. Whatever the old host was doing does not follow you.

When the old host is not cPanel

Migration is still possible and involves more manual work, because there is no single archive containing everything.

Say so in your first message, and name the platform. Some are straightforward; a few proprietary builders do not allow exporting a site at all, in which case it has to be rebuilt rather than moved, and knowing that early is much better than discovering it midway.

Doing it yourself

Entirely reasonable if you prefer control over the timing. The order is the same: copy files and database, restore here, point the application at the new database, test with a hosts entry, change DNS last.

Moving an existing WordPress site goes over both the plugin route and the manual one, including the database privilege step that causes most failed manual migrations.

Coming from a hosted website builder is a different job, because the design does not transfer. How to Move from a Website Builder to Your Own Hosting goes into it.

What a free migration actually covers is worth establishing in advance, along with five other questions. See What to Ask Before Moving to a New Host.

Make the site copyable before the request

A migration runs on what the old host will release, and a few things prevent an otherwise routine copy.

du -sh ~/public_html ~/mail 2>/dev/null
find ~/public_html -type l 2>/dev/null | head
mysql -e "SHOW DATABASES" 2>/dev/null | wc -l

Very large mail directories, files owned by another user, and databases the account cannot export are the three that stall a transfer. Each is easier to resolve while you still have the old account than during the move.

Clear what does not need to travel first. Old backups, cache directories and log files frequently make up a large share of the total and copying them costs the time the migration is measured in.

Say what must not be interrupted

A migration request that describes the site produces a technically correct copy. One that describes the constraints produces a copy that does not cost you anything.

State plainly which parts cannot be down: a shop taking orders, a form that feeds a business process, mail for a specific domain. State when the quiet hours actually are, since assumptions about that are usually wrong.

And name anything scheduled that must not run twice. A billing job or a mailing that exists on both the old and the new copy will run on both, and that is the migration failure that reaches customers rather than staff. Scheduling jobs with cron and systemd timers deals with finding them.

Check the copy before pointing anything at it

The moment to find a fault is while both sites exist and the domain still points at the old one.

curl -sI --resolve example.com:443:NEW-IP https://example.com/ | head -1
curl -s --resolve example.com:443:NEW-IP https://example.com/ | grep -c '

Resolving the name to the new address for a single request tests the new server as if the domain already pointed there, without changing anything for visitors.

Check a page that uses the database, a page that writes something, and one image. Those three cover the faults that matter, and all of them are cheap to fix before the switch and disruptive to fix after it.