Web Hosting with Free Website Migration

When you buy a web hosting or WordPress hosting plan, our support team moves your existing site for you at no charge. That covers the three things that make up a website:

• Files: the document root, uploads, themes, plugins and any custom code.
• Databases: exported from the old host and imported on the new account, with the site's configuration updated to the new credentials.
• Email: mailboxes recreated on Devoster and their messages copied across, if you want mail to move with the site.

It is not limited to WordPress. PHP sites, static sites and other CMSs move the same way. You can move as many sites as your plan holds: 5 on Lite, 10 on Standard, 20 on Pro.

Some things are not files and need a decision rather than a copy. SSL certificates are reissued on the new server (Let's Encrypt is free and automatic here). Cron jobs, DNS records such as TXT verification entries, and anything a third party has allowlisted by your old server's IP address all need checking. We list them in the inventory below so nothing gets lost.

• 1. Pick a plan. Size it for the site you have, not the one you hope for. Moving up a tier later is quick.
• 2. Lower your DNS TTL. A day before cutover, set the TTL on the records you will change to 300 seconds. This is what turns the switch into minutes instead of a day of visitors hitting the old server.
• 3. Open a migration ticket. From your dashboard, go to Support and open a ticket titled "Website Migration Request" with the details listed in the next section. Put credentials in the ticket, never in plain email.
• 4. We copy the site. Files, databases and email are copied to your new account while the original keeps serving visitors. Nothing on your live site changes.
• 5. You test. Check the copy before the world sees it, by pointing your own computer at the new server through your hosts file. Log in to the admin, submit a form, run a test checkout.
• 6. Switch DNS. Change the A record or the nameservers. With a short TTL, most visitors reach the new server within minutes.
• 7. Keep the old host for two weeks. If anything is wrong, pointing DNS back is your rollback. Cancel only after a full cycle on Devoster.

For a typical small site the copy itself takes hours rather than days, and depends mostly on database size, media and the volume of email. The TTL wait before and the overlap after take longer than the transfer. Our step-by-step migration guide has the commands if you prefer to do it yourself.

Half an hour of preparation removes most of the risk. Include this in your ticket:

• The name of your current host and the domains involved, including subdomains.
• Access to the old account: control panel login or SFTP/SSH credentials. A full backup file works too if you no longer have panel access.
• Whether email should move, stay where it is, or go to a separate mail provider.
• Anything unusual: cron schedules, a non-standard PHP extension, an old PHP version a plugin depends on, a staging copy.
• Who controls the domain at the registrar. You will need that login on cutover day to change DNS. A missing registrar login derails more migrations than any technical problem.

Also export your full DNS zone from the current DNS provider. TXT records for domain verification and mail authentication are the easiest thing to lose and the most annoying to rediscover.

The migration is designed for zero downtime: the old site keeps running until DNS moves, and during propagation both servers serve the same site because nothing has been deleted. Downtime in real migrations almost always comes from one of three mistakes, and each has a simple fix.

• A long TTL. If the TTL is still 86400, some resolvers keep sending visitors to the old server for a day. Lower it a day ahead.
• Cancelling the old host too early. Keep it until the new server has run for two weeks.
• Forgetting email. Mail follows the MX record, not the website. If you change nameservers, every record moves at once, MX included. If your mail is elsewhere and should stay there, change only the A record.

Shops and sites that take user content have one more consideration: during the few minutes of propagation, an order could land on the old server. Cut over in your quietest hour, or put the store in maintenance mode for ten minutes.

After the switch, check that SPF lists whatever now sends your mail and that DKIM is set up for the new server, since DKIM keys are generated per server and do not travel with the site.

Most people searching for a new host are leaving cPanel. Devoster runs the Enhance control panel instead, and Enhance includes an importer built for exactly this move: it reads a full cPanel account backup and recreates the account. According to Enhance's documentation, that brings across:

• Website files and all MySQL databases
• Email accounts with their passwords and messages, plus forwarders
• The existing SSL certificate, cron jobs and FTP accounts
• MX and SPF records; addon, sub and parked domains become mapped domains

Not imported, and worth noting before you start: PostgreSQL databases, wildcard subdomains, catch-all addresses, autoresponders, calendars and contacts, Mailman lists, directory privacy, custom error pages and old statistics. If you rely on any of these, mention it in the ticket so it gets set up by hand.

The easiest thing you can send us from cPanel is a full account backup (Backup, then Download a Full Account Backup) or your cPanel login. Partial backups of only the home directory or only the databases do not carry the email and settings.

Source: Enhance cPanel importer documentation, checked 2026-10-28.

WordPress is the most common site we move, and it fails in predictable places. These are the checks we make, and the ones worth knowing if you migrate WordPress yourself:

• Database connection. The "Error establishing a database connection" screen after a move is almost always the wrong host value in wp-config.php, not a wrong password.
• Domain or protocol changes. If the URL changes (for example from http to https), a plain find-and-replace on the SQL dump corrupts serialised data. Use wp search-replace, which handles serialisation, and dry-run it first.
• PHP version. A white screen usually means an old plugin meeting a newer PHP. New sites here default to PHP 8.3, and the version can be set per site, so a legacy site can stay on the branch it needs while you update it.
• Caching and security plugins. Some store server paths or IP rules. Clear their caches after the move.

Once it is running, you get a staging site for every website slot on your plan, so the next plugin update can be tested on a copy first. The full DIY walkthrough is in how to move a WordPress site to a new host, and the vendor-neutral version is in our guide to changing web hosting.

• Your site lives on a website builder. Wix, Squarespace and similar builders do not export a site you can move as files. You would be rebuilding, not migrating.
• Your stack needs root. Docker, a custom daemon or system packages will not run on shared hosting on any panel. Look at our KVM VPS plans instead, and note they are unmanaged.
• You need cPanel specifically. We run Enhance, not cPanel. If your team or clients depend on cPanel itself, move to a cPanel host.
• Regulated data. We hold no compliance certifications and do not sign business associate agreements.
• Your audience is in one country and latency is critical. Web hosting is in Europe or the US. If your visitors are in Israel, Europe is the closer of the two, but it is not a local datacenter.

If none of those apply, the move is low-risk: the old site stays up until you choose to switch, and hosting is covered by a 30-day money-back guarantee (domain registrations are non-refundable).