Skip to main content

Upgrades and migrations

Retiring or moving a website: the offboarding checklist

Last updated Tue, Nov 3, 2026

Retiring a website, or moving it to another provider, takes more than switching it off. A site touches domains, email, forms, integrations, analytics, and records you may be required to keep. Done in the wrong order, the last step is a broken link in a printed brochure, a form that silently stops sending, or a cloud bill that keeps arriving for resources nobody uses. Here is the checklist, in the order that avoids those surprises.

1. Decide and record

  • The date the site stops, and who approved it
  • Whether it is retired, merged into another site, or moving to a new provider
  • Who receives exports, and in what format
  • Any records retention rule that applies to its content or form submissions; see hosting backups versus records retention

2. Export what you need

ItemTypical format
Code and themeRepository or archive
DatabaseDatabase dump
Uploaded files and mediaArchive
Form submissionsCSV export from the form tool
Analytics historyKept in the analytics account; make sure your organization owns it

Download exports promptly; links to large files are often available for a limited time. Store them where your organization, not one person, can reach them.

3. Handle the domain

  • Moving: point DNS at the new provider at cutover, after the new site is tested.
  • Merging: redirect every old address to its closest new page; see keeping redirects and search rankings.
  • Retiring: keep the domain registered and redirect it to a relevant page on your main site, at least for a year. Do not let it lapse; see who should own your domain.

4. Check what else depends on the site

  • Email sent from the site or its domain, including forms and notifications
  • Integrations that send data to the site or receive it, such as a CRM or payment provider
  • Certificates, DNS records, and allowlist entries created for the site
  • Links from your other sites, social profiles, and printed materials
  • Email accounts or licenses bought for the site, which may run on annual commitments that cannot be reduced until renewal

5. Shut down and clean up

  • Remove server, VPN, SFTP, and storage access for everyone
  • Remove DNS records that pointed to the old hosting
  • Decommission hosting resources, keeping a final backup for an agreed period
  • Confirm the next bill shows no remaining charges for the site

A typical timeline

WhenWhat happens
Six to eight weeks beforeDecide the date; list domains, integrations, email, and records requirements; tell partners
Four weeks beforeRequest exports; build the redirect map or the new site; lower DNS TTLs closer to the date
Cutover daySwitch DNS or redirects; test forms, email, and key pages
The following weeksWatch for broken links and missed emails; then remove access, DNS records, and hosting resources

Leaving enough time matters most when hosting runs on annual commitments or reserved capacity, which may need notice before renewal to avoid another term.

Things people forget

  • Scheduled emails and reports the site sends, such as newsletters or digests
  • Social media profile links and bios
  • Third-party listings, such as directories, maps, and partner sites
  • QR codes on printed materials and signage
  • Monitoring alerts that will fire once the site is gone

Common questions

How long should we keep a final backup? Long enough to cover a request to restore something, and any retention rule that applies. Agree a date, and then make sure it is actually deleted.

The new provider needs access to the old site. Give them read-only access, or exports, rather than shared credentials.

Can we keep the old site online, read-only, for reference? Yes, but a forgotten site still needs updates and certificates. A static archive copy, or exports kept internally, is usually safer and cheaper.

What about the people who edited the site? Remove their CMS accounts with everything else, and tell them where the content now lives so they stop editing the old copy.

How eWay handles offboarding

When a site leaves an environment eWay manages, eWay provides exports of code, database, and files, coordinates the DNS change with your team or the new provider, and decommissions the hosting resources, keeping a final backup for an agreed period and confirming that no charges remain. The source environment is not altered until the move is accepted, so there is always a way back during the transition.

What to include in a support ticket

  • The site, the target date, and whether it is retiring, merging, or moving
  • Who receives the exports
  • The new provider's contact, if moving

eWay customers can open a ticket in the support portal or email support@ewaycorp.com.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article

Platform Notes

Get practical WebOps and cloud insights in your inbox

We publish articles on managed operations, cloud infrastructure, CMS platforms, government technology, and security, written by engineers who operate these environments every day. No marketing fluff. Unsubscribe any time.

We respect your privacy. No spam, no third-party sharing. Unsubscribe any time.