Cloud migration
Cloud migration without the outage: moved, tested and verified before DNS changes.
Cloud migration without the outage: we move websites, online stores, databases and web apps from shared hosting or an office server to cloud infrastructure. The new environment is built and tested on a private address while the old one keeps serving visitors. DNS is switched only after files, database, SSL and email records are verified, and the old server stays untouched as a rollback.
Since 2021 serving Canadian businesses
Vancouver based, working across Canada
Old server kept as a rollback after cutover
Chosen by
What we migrate
Twelve things that move in a cloud migration, and how each one is handled.
A website is more than its files. These are the parts that have to arrive intact, with the tools and techniques used for each.
WordPress sites
Files, database, uploads and users moved, with every stored URL and path rewritten safely, including serialised data.
rsync over SSH · WP-CLI search-replace · checksum verify
WooCommerce stores
Orders keep arriving while we work. A short checkout freeze covers the final sync of orders and customers.
Order delta sync · payment webhooks · maintenance window
Custom web apps
PHP, Laravel and Node applications moved with their environment settings, queues, workers and scheduled tasks.
Environment parity · queues and workers · scripted deploys
Databases
MySQL, MariaDB and PostgreSQL moved by dump and restore, or by replication when the database is too large to stop.
Logical dumps · replication · version upgrades
Shared hosting to cloud
Off GoDaddy, Bluehost and other cPanel hosts, with rewrite rules translated and the PHP version matched first.
cPanel export · .htaccess to Nginx rules · PHP version match
Office servers to cloud
An ageing server in a back room moved to AWS, Microsoft Azure or Google Cloud, sized for what you actually use.
AWS · Azure · Google Cloud · encrypted transfer
DNS zones
Every record audited and carried over, with the TTL lowered ahead of time so the switch takes minutes.
Zone audit · TTL plan · DNSSEC check
Email records
MX, SPF, DKIM and DMARC copied exactly, so mail keeps flowing through the move and still passes authentication.
MX · SPF · DKIM · DMARC
SSL and secrets
Certificates issued before cutover. Database passwords, API keys and salts rotated once the old server is retired.
TLS certificates · key rotation · least-privilege users
Media libraries
Large upload folders moved in the background ahead of cutover, then served through the CDN.
Background sync · CDN · image optimization
Cron and background jobs
Scheduled tasks found, moved and run from a real system cron, so nothing silently stops after the move.
Crontab audit · WP-Cron to system cron · job logs
Backups and monitoring
Daily off-site backups and uptime checks switched on at the new home before the first visitor arrives.
Off-site backups · uptime checks · error-log alerts
How the cutover works
How a site changes servers without visitors noticing.
Nothing is switched until the new server is proven. The diagram shows the two phases, and the steps explain why the order matters.
Lower the TTL
Days before cutover, the DNS time-to-live is dropped to five minutes. Resolvers then re-check the address often, so the later switch spreads in minutes and not hours.
Copy to the new server
Files go over SSH with rsync and the database as a consistent dump. The site runs on the new server at a private address, reachable only with a hosts-file entry or a temporary URL.
Test what depends on the server
Forms, logins, checkout, payment webhooks, scheduled jobs, outgoing mail and file permissions. PHP and database version differences show up here and not in front of customers.
Final sync
In the agreed window, writes are paused and only what changed since the first copy is transferred: new orders, uploads and form entries. Because the bulk is already there, this takes minutes.
Verify, then switch
File checksums and database row counts are compared. The certificate is already installed. Only then is the DNS record pointed at the new server.
Stand by
Both servers serve the same site while DNS spreads. Logs, forms and orders are watched on the new one. The old server stays untouched for 14 days, then is wiped and retired.
The migration checklist, item by item
| What | How we handle it | Why it matters |
|---|---|---|
| Files | rsync over SSH with checksums, run once in full and again for the difference at cutover. | Nothing is lost between the first copy and the switch. |
| Database | A single-transaction dump restored and compared table by table. Replication for databases too large to pause. | Orders and entries arrive complete and in order. |
| DNS | Zone exported and audited, TTL lowered to 300 seconds ahead of time, A and AAAA records switched, everything else carried over unchanged. | The switch spreads in minutes, and mail and subdomains keep working. |
| SSL and TLS | Certificate issued on the new server before cutover using DNS validation, with HTTP to HTTPS redirects and HSTS kept as they were. | No certificate warning for the first visitor. |
| Runtime versions | PHP and database versions matched to the old host, or upgraded and tested on the staging copy first. | Version changes are found in testing. |
| Rewrite rules | Apache .htaccess rules translated into Nginx configuration and tested against a list of real URLs. | Every existing address still resolves. |
| Scheduled jobs | Crontab and WP-Cron events inventoried and recreated as system cron jobs, with output logged. | Backups, feeds and emails keep running. |
| Caching and CDN | Redis object cache and page cache configured, then the CDN pointed at the new origin and purged. | The speed gain shows from the first request. |
| Rollback | Old server left online and unmodified for 14 days. Reverting is a DNS change that spreads within the same five-minute TTL. | There is always a working version to return to. |
The plan in pictures
A migration timeline, the DNS switch and the stack your site lands on.
Three views of the same job: when each task happens, what visitors experience at the moment of the switch, and what sits under the site afterwards.
A typical two-week migration
Most of the calendar is preparation and testing. The risky part, the amber band, is kept as short as possible because everything before it was rehearsed. Durations are typical for one site and are set per project in your runbook.
What visitors reach after the switch
With the TTL at five minutes, most resolvers pick up the new address within minutes and a few take longer. Both servers serve the same site during that time, so nobody lands on a broken page. The curve is an illustration, not a measurement.
Where a website lands: WebCrafters Cloud
A request passes the CDN and the firewall before it reaches Nginx and PHP-FPM, with Redis in front of the database. Backups leave the server every day.
What every migration includes
Eight things that make a migration boring, which is the goal.
Most migration problems come from something nobody listed: a cron job, a mail record, a hard-coded path. This is the work that finds those before cutover, and it is what your quote covers.
A full inventory of the old host
Sites, databases, cron jobs, DNS records, mailboxes, certificates, redirects and anything else living on the server, written down before a single file moves.
A written runbook with a rollback
Every step of the cutover in order, who does it and how it is undone. You see it and approve the window before we start.
A staging copy on the new server
The whole site running on the new infrastructure at a private address, so you can click through it while the live one is untouched.
Verified data, not assumed
File counts and checksums compared, database row counts matched table by table, and uploads spot-checked, before and after the final sync.
A DNS plan
The zone is audited record by record, the TTL is lowered ahead of time, and mail, verification and subdomain records are carried over exactly.
SSL ready before the switch
The certificate is issued on the new server ahead of cutover, so the first visitor after the DNS change gets a padlock and not a warning.
Cutover in a quiet window
The final sync and DNS switch happen at the hour your traffic is lowest, agreed with you, with someone watching logs and forms through it.
A before and after report
What moved, which versions it now runs on, and the same pages timed on the old and the new server, so the result is measured and not claimed.
Your URLs do not change
Every address on the site stays exactly as it was, so links, bookmarks and search rankings carry over.
Not sure what a move would involve?
Tell Ella what you run and where it lives. Ella will outline the migration.
Six quick questions about the site, the current host and what cannot go offline. You get a plain-words outline of what has to move, the order it should move in and the risks to plan around. Two minutes, no obligation.
Ella is automated and can make mistakes. Your written quote from a project lead is the final word.
How it works
From audit to cutover in four steps.
A single WordPress site is usually moved within one to two weeks of the audit. Stores, several sites or a custom app take longer. Your quote shows the real dates.
01
Audit and runbook
You send us the details: what you run and why you want to move. We inventory the old host with read access, then send the runbook and a fixed price within one business day.
Day 1 to 2
02
Build and copy
The new environment is built to match or improve on the old one: PHP and database versions, caching, firewall. A full copy of files and database is loaded onto it at a private address.
Week 1
03
Test and rehearse
Forms, logins, checkout, scheduled jobs and email sending are tested on the copy. Anything that depended on the old server is fixed. The final sync is rehearsed so its duration is known.
Week 1 to 2
04
Cutover and standby
In the agreed window: a short content freeze, the final sync, verification, then the DNS switch. The old server stays online and unchanged for 14 days, so going back is a DNS change.
Cutover and 14 days after
What it costs
A fixed price per migration, before anything is touched.
We do not publish one price because moving one WordPress site off shared hosting and moving a store, three databases and an office server are different jobs. What we do promise is a written quote after the audit, and the number does not change unless the inventory does.
What moves the price
How many sites and databases, how much data, how tangled DNS and email are, and whether PHP or database versions have to be upgraded on the way.
Payment plans up to 24 months
Pay by milestone, or spread the cost over up to 24 months. Credit and debit cards and bank transfer are both fine.
Hosting priced separately
The migration is a one-time price. Hosting on WebCrafters Cloud, or the bill from your cloud provider, is listed separately so you can compare it with what you pay today.
Questions
What owners ask about cloud migration.
If yours is not here, the full list is one click away, or just pick up the phone.
Still have a question?
Call us on a weekday, or send a note and we will get back to you within one business day.
Will my website go down during a cloud migration?
A cloud migration is planned so that visitors never see an outage. The new server is fully working before DNS changes, and for a while after the switch both servers serve the same site, so it does not matter which one a visitor reaches. Stores and sites that take submissions have a short content freeze during the final sync, usually minutes, in a quiet hour. We do not print a zero-downtime guarantee, because honest engineers do not, but the rollback is one DNS change.
Will a cloud migration affect my Google rankings?
A cloud migration should not affect your Google rankings. Every URL stays the same, the content is identical, and Google sees only that the site now answers from a different address, often faster. We check Search Console for crawl errors in the days after cutover. Rankings are at risk when URLs change without redirects, and that is a redesign problem, not a migration one.
Will our email stop working during a migration?
No, your email keeps working during a migration. Mail is controlled by MX, SPF, DKIM and DMARC records, and those are copied exactly when DNS is moved. If your mailboxes are on a separate provider such as Microsoft 365 or Google Workspace, nothing about them changes. If they live on the old web host, we tell you during the audit and plan their move with your email provider before the old server is retired.
Where will my website be hosted after the migration?
Websites and stores move to WebCrafters Cloud, which runs Nginx with PHP-FPM, Redis caching, an edge CDN, a web application firewall and daily off-site backups, in a Canadian or US data centre. Custom applications and office servers that need their own infrastructure are moved to AWS, Microsoft Azure or Google Cloud, in an account set up for your company.
What happens if something goes wrong after the DNS switch?
If something goes wrong after the switch, we point DNS back at the old server. It has not been touched, so it is exactly as it was before the cutover, and with the TTL at five minutes most visitors are back on it within minutes. Anything written to the new server in the meantime, such as orders or form entries, is copied back. Then we fix the cause on the new server and schedule the switch again.
How long does the DNS change take in a migration?
Because the TTL is lowered to five minutes ahead of time, most visitors reach the new server within minutes of the switch. A small number of networks ignore short TTLs and can take a few hours. That is why both servers keep serving the same site until the old one stops receiving traffic.
Start today
Tell us what you run and where it lives. A project lead replies within one business day.
Two minutes to fill in, no obligation. Give us the address of the site, the current host and what is not working there. After a read-only audit you get a runbook and a fixed price.
- New server tested before DNS changes
- Old server kept for 14 days as a rollback
- Every URL stays the same
"*" indicates required fields