Moving hosts is usually where downtime sneaks in, the trick is to never take the old site offline until the new one is fully live and verified. Here's how we handle it, plus the manual path if you'd rather do it yourself.

The managed way: request a free migration

1

Open a migration request

From your account, request a migration and hand over read-only access to your current host, or just the domain name if it's a common platform like WordPress or a standard cPanel account.

2

We copy your site to a staging address

Your files, database, and email are pulled across while your current host keeps serving live traffic. Nothing changes for your visitors during this step.

3

You verify the copy

We hand you a temporary URL that points at the new copy so you can click through the site and confirm everything looks right before anything goes live.

4

You update DNS when ready

Only once you've approved the copy do you point your domain at Anomica. Because DNS caching means the old server keeps answering for existing visitors until their resolver catches up, the cutover is gradual rather than an abrupt switch.

The DIY way, if you'd rather drive

If you have SSH access on both ends, you can pull your files directly and skip the request queue entirely:

zsh · anomica
$ rsync -avz -e ssh youruser@old-host.example.com:~/public_html/ ./public_html/
sending incremental file list
public_html/wp-config.php
public_html/wp-content/ ...

Export your database with mysqldump on the old host and import it on Anomica the same way, then update wp-config.php (or your framework's equivalent) with the new database credentials before you flip DNS.

Lower your TTL beforehand

If you know a migration is coming, drop your DNS record's TTL to 300 seconds a day or two ahead of time. It makes the eventual cutover propagate in minutes instead of hours.