What the migration includes
A migration is a complete move of your site to a new host, preserving everything that was there. The work covers:
- Audit of the current setup. We review the stack, hosting, access credentials, and DNS records.
- Data transfer. Code, content, database, media, and configuration - everything, with no losses.
- Copy deployment. We stand up the site on the new host and verify that everything works.
- Domain, DNS, SSL. We bind the domain, configure records, and set up the certificate for HTTPS.
- Zero-downtime cutover. We switch DNS only after the copy is verified - the site stays accessible.
Why there is no downtime
The site never goes offline, because the switch happens at the end rather than the beginning. First we stand up a full copy on the new host and test it at a real address - forms, payment, catalog, customer accounts. The old site keeps running throughout.
Only once the copy is verified do we change DNS. Records propagate at different speeds across providers, and during that window some visitors still reach the old server - so we do not switch it off immediately, but keep it running until the traffic has fully moved. If something does go wrong, rolling back is another record change rather than a restore from an archive.
What we check after the switch
- Certificate and HTTPS - so browsers do not warn visitors away.
- Email. The classic loss in a migration: the domain moves and the mail records are forgotten - and messages stop arriving.
- Forms and payment. We send a test enquiry and confirm it landed exactly where it should.
- Redirects and addresses. That the site opens in one canonical form - with or without www, over HTTPS - and does not breed duplicates.
- Backups - configured afresh in the new place, not left behind on the old host.
Where we migrate to
| Host | Best for |
|---|---|
| Cloudflare Pages | Static sites and clean-code projects - fast, affordable, global CDN |
| Vercel | frontend applications with server-side logic |
| Railway | Applications with a backend and database |
We pick the host based on the site type and budget. The goal is to leave slow, expensive hosting for a modern platform with proper support and SSL out of the box.
How the migration works
We deploy a full copy of the site on the new host and test it without touching the live version. Once the copy is verified against the original and everything works, we switch DNS to the new address. We keep a rollback path via a backup of the old host if needed. The quote is fixed after a brief, once we know the stack and data volume.
What comes next
After the migration you can put the site on a maintenance retainer to keep it in shape, or immediately optimize for speed on the new infrastructure. If the site itself is outdated and a hosting move will not save it, the right answer may not be a migration but a rebuild on a modern platform.
FAQ
Will there be any downtime during the migration?
No. We migrate without downtime: first we deploy and verify a full copy on the new host, and only switch DNS once everything is confirmed working. Visitors experience no interruption - the site stays accessible throughout.
Will you transfer the site without data loss?
Yes. We move everything - code, content, database, media, configuration, and DNS mail records. Before switching we verify the copy against the original so nothing is missed. When needed we keep a backup of the old host as a rollback path.
Which hosting do you recommend?
It depends on the site type. For static sites and clean-code projects - Cloudflare Pages or Vercel. For apps with a backend and database - Railway or Vercel. For projects with special requirements we pick the right fit. The goal is always to leave a slow, expensive host for a modern one with proper support and SSL out of the box.
Do you set up SSL and the domain?
Yes. The migration includes domain binding, DNS record configuration, and SSL certificate setup so the site works over HTTPS without browser warnings. If the domain is at a different registrar we help connect it to the new host and verify all records are correct.