How to Migrate Your Website to Devoster: Step by Step

A website migration goes wrong in one of three places, and none of them is the file copy. It goes wrong at DNS, because a cached record sends visitors to a server you have already emptied. It goes wrong at email, because mail follows the MX record and nobody checked it. And it goes wrong at the database connection string, because the site came up looking perfect and then died the moment someone logged in.

Do it in this order and none of that happens: lower your DNS time-to-live a day early, copy everything while the old site stays live, test the copy on a temporary address, decide what email is doing, then switch DNS and watch. That is the whole method. Below is each step in detail, the commands if you are doing it yourself, and an honest section on when moving to Devoster is not the right call.

Key Takeaways

• Lower the DNS TTL to 300 seconds at least 24 hours before cutover. This single step is the difference between a five-minute switch and a two-day tail of visitors hitting the old server.
• Nothing is deleted from your old host until you have run on the new one for two weeks. Keep paying for it, it is the cheapest insurance in this process.
• Migration is free at Devoster, so if you are not comfortable with the command line, open a ticket and hand it over rather than improvising at midnight.
• Email is a separate migration from the website. Decide early whether mail moves, stays where it is, or goes to a third-party provider, because MX, SPF, DKIM and DMARC all need attention.
• Test on a temporary address or through your local hosts file before DNS moves. A test that passes after cutover is not a test, it is a discovery.
• There are cases where we are the wrong destination, mainly regulated data, a need for a European or Asian location, or a team that wants a managed server. Those are in a section near the end.

First, the Thirty-Minute Inventory

Almost every migration horror story is really an inventory failure. Something existed that nobody knew about, and it stopped existing. Spend half an hour filling this in before you touch anything.

Item	Where to find it	Why it bites
Every domain and subdomain	Old control panel, DNS zone export	A forgotten subdomain for a booking system disappears on cutover
Full DNS zone, not just A records	Export the zone file from your current DNS host	TXT records for domain verification and mail authentication are easy to lose
PHP version and extensions	A phpinfo page, or the panel	An old plugin that needs an older PHP branch will fatal-error on a newer one
Cron jobs and scheduled tasks	Cron section of the old panel	Invoicing, backups and imports silently stop for weeks
Email accounts and their sizes	Mail section of the old panel	Copying twelve gigabytes of mail takes far longer than the website
SSL certificates and their type	Panel, or check the padlock in a browser	A paid certificate is not portable in the way people assume
Third-party allowlists	Payment gateway, API providers, mail relay	Services keyed to your old server IP stop working the instant you move
Who controls the registrar login	Ask early, before cutover day	A developer who left in 2019 owns the domain and does not answer email

That last row derails more migrations than any technical problem. Confirm registrar access exists and works before you schedule anything.

Step 1: Pick the Plan That Matches the Site

Size for what the site is, not what you hope it becomes. You can move up a tier later in minutes; overbuying on day one just costs money you could have spent on backups.

If your site is	Buy	Starting price	Why
A brochure site, portfolio or small blog	Shared hosting, Lite	$2.90 per month	cPanel, no server administration, enough for cached pages
A busier WordPress site or small store	Shared hosting, Standard	$5.90 per month	More memory and IO headroom for logged-in traffic
A WordPress site you would rather not administer	Managed WordPress	See plan page	The platform side is handled for you
A Node.js application	Node.js hosting	See plan page	Runtime support without building a server
Anything needing root, custom software or several sites	KVM VPS, Nano upward	$3.49 per month	Full root, choice of OS, one IPv4, unmetered transfer on a 1 Gbps link
Client hosting you resell	Reseller hosting	See plan page	Separate accounts per client

Two things worth knowing before you choose. Yearly billing is cheaper per month than monthly across the shared plans, so if you are confident, the annual term is the better buy. And our VPS plans are unmanaged: full root access on KVM with Intel Xeon Gold 6138 processors and NVMe storage, but updates, firewall and web server configuration are yours. If that sentence made you uneasy, take shared hosting instead. There is no prize for running your own server.

Step 2: Lower the DNS TTL a Day Early

This is the step that separates a clean migration from a messy one, and almost every guide puts it last. Do it first.

Your DNS records carry a time-to-live value telling resolvers around the world how long they may cache the answer. If it is set to 86400, a resolver that looked up your domain an hour before you cut over will keep sending visitors to the old server for the next twenty-three hours. Drop it to 300 seconds and the same resolver forgets within five minutes.

Check what you currently have:

dig +noall +answer example.com
dig +noall +answer www.example.com

The number after the domain name is the TTL in seconds. Go into your DNS provider, set it to 300 for the A, AAAA, CNAME and MX records you plan to change, and then wait at least as long as the old TTL before you cut over. If the old value was a day, you wait a day. This is why the TTL change happens before the file copy, not after.

Step 3: Copy the Site While the Old One Stays Live

Option A: hand it to us

Free migration is included, and for most sites it is the sensible choice. Open a ticket from the dashboard at Support with the subject Website Migration Request, and include the current host, the domains involved, control panel or SFTP credentials for the old account, whether email needs to move, and anything unusual such as a custom cron schedule or a non-standard PHP extension. Do not send credentials over regular email; put them in the ticket.

Nothing on your live site changes while this happens. The copy runs alongside the original, and you approve the result before any DNS moves.

Option B: do it yourself

Perfectly reasonable if you have shell access on both ends. Export the database first, with a consistent snapshot:

mysqldump --single-transaction --quick -u DBUSER -p DBNAME > site.sql
gzip site.sql

Then move the files. If the old host gives you SSH, rsync is faster and resumable:

rsync -avz --progress public_html/ user@new-server:/home/user/public_html/

If it does not, tar the document root, download it, and upload it over SFTP:

tar -czf site.tar.gz public_html

Create the database on the new account, import, and update your configuration file with the new credentials:

mysql -u NEWUSER -p NEWDB < site.sql

For WordPress that configuration file is wp-config.php. For Laravel it is .env. Getting this wrong is the classic error connecting to the database screen, and it is almost always a wrong host value rather than a wrong password: some hosts use localhost, others use a specific hostname.

If the domain or protocol changes, do not run a plain find and replace on the SQL dump. Serialised PHP arrays store string lengths, and a naive replace corrupts them. Use the WP-CLI search-replace command, which handles serialisation properly, and always dry-run first:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run

Step 4: Test Before DNS Moves, Not After

You can see the new server on your own machine without changing anything publicly, by pointing your computer at it directly. Add a line to your hosts file with the new server IP and your domain:

203.0.113.10 example.com www.example.com

On Linux and macOS that file is at /etc/hosts. On Windows it is at C:\Windows\System32\drivers\etc\hosts and needs an administrator editor. Now your browser reaches the new server while the rest of the world still reaches the old one. Work through this list:

• Home page, and three deep pages chosen at random rather than the ones you always check.
• Log into the admin area. A site that renders but will not authenticate has a session or database problem.
• Submit the contact form and confirm the message actually arrives, not just that the thank-you page appeared.
• Complete a test checkout end to end if there is a shop, including the payment provider callback.
• Check images and downloads load, especially anything referenced by absolute URL.
• Confirm the search function works, since search often depends on database features that differ between server versions.
• Open the browser console and look for mixed content warnings and 404s on assets.
• Verify scheduled tasks are configured on the new server. They do not travel with the files.

Remove the hosts file lines when you are done, or you will spend an afternoon confused about why your changes are invisible to everyone else.

Step 5: Cut Over DNS

Nameservers or A record

Changing nameservers hands the whole zone to the new host, which is simpler to manage afterwards but moves every record at once, including MX. Changing just the A record moves only web traffic and leaves email exactly where it is. If your mail is on a third-party service and you do not want to think about it today, change the A record and nothing else.

Whichever route you pick, use the exact nameserver hostnames or IP address given in your account and welcome email rather than any value you found in an old article. Those details are account-specific.

What propagation actually looks like

There is no global switch. Each resolver picks up the change when its cached copy expires, which is why the TTL work in step two matters so much. For a few minutes, some visitors reach the new server and some reach the old one. Both work, because you have not deleted anything. Confirm progress from different resolvers:

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8

One thing to plan for: if visitors can place orders or post content, a small window exists where a write could land on the old server. For a shop, either cut over during your quietest hour or put the store in maintenance mode for the ten minutes it takes.

Email Is a Separate Migration

Treat mail as its own project with its own decision, made before cutover day.

• Mail stays where it is. The safest option. Change only the A record, leave MX untouched, and verify afterwards that the MX record still points where it always did.
• Mail moves with the site. Create every mailbox on the new server before cutover, then copy the messages with an IMAP synchronisation tool while both servers are running. Only then move MX.
• Mail moves to a dedicated provider. Often the right long-term answer. Set it up in parallel, verify, and switch MX independently of the website.

Whatever you choose, check three text records afterwards. SPF must list whatever now sends your mail, including the web server if your site sends transactional messages. DKIM keys are generated per server and do not transfer; a copied DKIM record signs nothing. DMARC will start reporting failures if you get either of the first two wrong, which is a feature rather than a nuisance.

The Two Weeks After

Within the first hour: confirm the padlock is present and the certificate covers both the bare domain and the www version, check that http requests redirect to https, and load the site on mobile data so you are seeing it through a different resolver.

Within the first day: send and receive a real email in both directions, verify any external service keyed to your server IP still authenticates, and check the server error log rather than assuming silence means success.

Within the first week: confirm each cron job has actually executed, watch search engine crawl statistics for a spike in errors, and run a full backup on the new host so you have a restore point that was created here rather than imported.

Keep the old hosting paid up for at least two weeks. Cancel it only after a full billing and content cycle has passed on the new server, and take a final archive of the old account before you do. If you want a broader view of the process for other providers, our guide to changing web hosting service covers the same ground vendor-neutrally, and moving a WordPress site to a new host goes deeper on the WordPress specifics.

If Something Goes Wrong

Rollback is genuinely easy as long as you kept the old account. Point the A record or nameservers back, and once the short TTL expires you are running on the original server again. This is the whole reason you lowered the TTL and did not cancel anything.

Three problems account for most of what actually goes wrong. A white screen usually means a PHP version mismatch or a missing extension, so check the error log and compare the two PHP configurations. A database connection error is nearly always the wrong host value in the configuration file. Broken images with working pages usually means absolute URLs in the database, which the search and replace step above fixes.

When Devoster Is the Wrong Destination

We would rather you know this now than after the transfer.

• Regulated data. We hold no security certifications, publish no audit report and do not sign business associate agreements. If your workload is bound by health, card or similar rules, buy from a provider that can produce that evidence.
• You need a European or Asian location. We run one US-South location. If most of your visitors are in Europe, or your data must legally stay in a particular country, the physical distance is a real cost you cannot cache away.
• You want someone else to run the server. Our VPS plans are unmanaged. If you want patching, monitoring and tuning handled for you, shared hosting or managed WordPress is the right shelf here, and a fully managed provider may be a better fit than either.
• You depend on a feature we do not sell. If your current setup relies on a bundled content delivery network, an object cache service or a built-in application firewall, confirm you can replace it before you move rather than after.

None of these are hard to check, and checking takes ten minutes.

Frequently Asked Questions

Will my site go down during the migration?

It should not. The copy runs while the old site stays live, and you only change DNS after testing the new server. During the switch some visitors reach the new host and some the old one, and both serve the site because nothing has been deleted. Downtime usually comes from cancelling the old account too early.

How long does a website migration take?

The copy itself is usually hours rather than days for a typical small site, and depends mostly on database size and how much media you have. The longer part is the DNS TTL wait beforehand and the fortnight of overlap afterwards. Plan the calendar around those, not around the file transfer.

Is migration really free at Devoster?

Yes, free migration is included. Open a ticket from the dashboard with your current host, the domains involved, access credentials for the old account and any special requirements. If you prefer to do it yourself, the commands in this guide cover the standard path.

Should I change nameservers or just the A record?

Change only the A record if your email lives elsewhere and you want to leave it undisturbed. Change nameservers if you want the whole zone managed in one place afterwards. The A record route is lower risk on cutover day; the nameserver route is simpler for the next two years.

What happens to my SSL certificate?

Certificates are issued per server, so you request a fresh one on the new host rather than copying files across. Issue it before cutover if the platform allows validation without live traffic, and check afterwards that both the bare domain and the www version are covered and that http redirects to https.

Will migrating hurt my search rankings?

A same-domain move with identical URLs is not a signal search engines penalise. Damage comes from changed URLs without redirects, a slower server, or pages returning errors during cutover. Keep the URL structure, keep the redirects, and watch crawl errors for a fortnight afterwards.

Your Next Step

Do the inventory table first, then lower your TTL. Those two things take under an hour together and remove most of the risk from everything that follows.

When you are ready, pick a plan that matches the site you actually have: shared hosting for a straightforward site, managed WordPress if you would rather not administer the platform, or a KVM VPS if you need root. Then open a migration ticket and hand us the boring part.