Moving a Cascade site to new hosting sounds risky because the website is so visible. In practice it is one of the safer migrations in web operations, because your content never has to move. It lives in Cascade. What moves is the destination Cascade publishes to, plus the server configuration around it. With the right sequence, visitors never notice, editors keep publishing, and the old environment stays ready as a fallback until you are confident.
Why Cascade migrations can be zero-downtime
Cascade can publish the same site to more than one destination. That single feature makes the whole approach work. You build the new environment, add it as a second destination, and publish to both. For a period, the old and new environments hold identical content. Switching visitors from one to the other is then a DNS change, and switching back is the same DNS change in reverse.
The phases
| Phase | What happens | Done when |
|---|---|---|
| Discovery | Inventory destinations, transports, domains, certificates, redirects, server-side rules, forms, search, and anything else the current server does beyond serving files | A written inventory with no unknowns |
| Build | New environment built from infrastructure as code, with CDN, certificates, and monitoring in place | Environment reachable on a temporary hostname |
| Parallel publish | New destination added in Cascade; full publish to the new environment | Publish report clean, file counts match |
| Validation | Site tested on the temporary hostname against the checklist below | All checks pass |
| Cutover rehearsal | DNS time-to-live lowered; switch and rollback rehearsed | Both directions proven |
| Cutover | DNS switched in a low-traffic window | Traffic on the new environment, monitoring green |
| Hypercare | Close watch, old environment kept warm | Stable operation; old destination retired |
The validation checklist
Most migration surprises come from things the old server did quietly. Check each of these on the new environment before cutover:
- Redirects and rewrite rules. Years of vanity URLs and retired-page redirects often live in server configuration, not in Cascade. Export them and test a sample.
- Server-side includes and scripts. Some Cascade sites rely on server-side includes, PHP snippets, or handlers for forms.
- Custom error pages,
robots.txt, sitemaps, and verification files for search engines. - Files published outside Cascade. Other systems sometimes drop files straight onto the web server. Those will not arrive through publishing.
- Protected folders and any sign-in in front of them.
- Dynamic services: search, forms, calendars, and feeds that call other systems, including any firewall allow lists that need the new environment's addresses.
- Certificates for every domain and subdomain the site answers on.
Getting the DNS switch right
DNS records carry a time-to-live (TTL) that tells resolvers how long to cache the answer. If your record has a one-day TTL, some visitors will keep going to the old environment for a day after you switch. Lower the TTL to a few minutes at least a day or two before cutover, so the change, and any rollback, takes effect quickly. Raise it again once things are stable.
During the switch, keep publishing to both destinations. That way, whichever environment a visitor reaches, they see current content.
Choosing the window
Cut over in a quiet period: early in the week, early in the morning, and well away from application deadlines, registration, and the start of term. Avoid Fridays. You want people available the next day in case anything needs attention.
Rollback is the safety net
The old environment is not touched until you have accepted the new one. If something unexpected appears after cutover, you point DNS back and the site is serving from the old environment within minutes. Because both environments received every publish, no content is lost in either direction. That is what makes "zero downtime" a plan rather than a hope.
After cutover
Keep publishing to both destinations for a few days, watch error rates and 404s on the new environment, and compare analytics to make sure traffic has fully moved. Once you are confident, remove the old destination from Cascade so nobody publishes to it by mistake, then decommission the old server.
How eWay runs Cascade migrations
eWay handles the full migration: discovery, building the environment on AWS or Azure to fit your existing agreements, CDN and caching setup, migrating server configuration, validating publish behavior, and the cutover itself. Migrations are planned for zero unplanned downtime and typically take two to four weeks depending on complexity. Qualifying engagements include the migration at no charge. After go-live, eWay monitors closely through a hypercare period before handing over to steady-state operations.
What to include in a migration request
- The sites and domains involved, and roughly how many assets each publishes
- Your current host and how Cascade publishes to it today
- Any dates to avoid, such as deadlines, events, or registration periods
eWay customers can open a ticket in the support portal or email support@ewaycorp.com to start planning. See how to request support for all the options. Related reading: how Cascade publishing reaches your live website and SSL certificates and domain management for Cascade sites. More at Cascade Website Hosting.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article