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
| Item | Typical format |
|---|---|
| Code and theme | Repository or archive |
| Database | Database dump |
| Uploaded files and media | Archive |
| Form submissions | CSV export from the form tool |
| Analytics history | Kept 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
| When | What happens |
|---|---|
| Six to eight weeks before | Decide the date; list domains, integrations, email, and records requirements; tell partners |
| Four weeks before | Request exports; build the redirect map or the new site; lower DNS TTLs closer to the date |
| Cutover day | Switch DNS or redirects; test forms, email, and key pages |
| The following weeks | Watch 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
Feedback sent
We appreciate your effort and will try to fix the article