On this page
Changing where a website is hosted sounds like moving files from one server to another. In practice, hosting is woven into domain records, email delivery, certificates, scheduled jobs and the knowledge of whoever set it up. These twelve questions help surface the dependencies before anything moves.
Ownership and access
1. Who owns the hosting account? The account should belong to the business, not to an individual who might leave or an agency that might close. Confirm who can log in and who receives billing notices.
2. Who controls the domain registration? The registrar account is separate from hosting. If you cannot log in to it, resolve that first, because DNS changes depend on it.
3. Where is DNS actually managed? Nameservers may point to the registrar, the host, a CDN or a separate DNS provider. Changes must be made where DNS is authoritative.
What else lives on the server
4. Is email hosted on the same account? Mailboxes, forwarding rules and MX records are commonly tied to web hosting. Moving the website without planning email is a frequent cause of lost messages.
5. Are there other sites or subdomains? Staging copies, landing pages and old microsites often share an account. List every hostname that resolves to the current server.
6. Are there scheduled tasks? Cron jobs may send reminders, generate reports or clear caches. Each one needs an equivalent or a decision to retire it.
7. Are files stored outside the web root? Uploaded documents, exports or logs may live in places a simple copy will miss.
Security and continuity
8. How are SSL certificates issued and renewed? Know whether certificates are automatic, purchased, or managed by a CDN, and how renewal will work after the move.
9. What does the backup routine look like? Document frequency, retention, storage location and, crucially, whether anyone has tested a restore.
10. Which environments exist? Development, staging and production should be distinct. If changes are currently made directly on the live site, a move is a good time to introduce a staging step.
People and process
11. Who supports the site after the move? Clarify who applies updates, monitors uptime, responds to errors and renews services. Hosting changes responsibilities as much as infrastructure.
12. What is the rollback plan? Before switching DNS, keep the old environment available and decide what conditions would trigger switching back.
Lowering DNS risk
Before the switch, reduce the time-to-live on records you plan to change so updates propagate faster. Make the change at a quiet time for your audience, verify the new site over its final hostname, then raise the TTL again once things are stable.
Writing it down
Collect the answers in a short hosting runbook: accounts and owners, DNS records, email configuration, certificate approach, backup schedule, environments and contacts. That document is useful long after the move, especially when someone new joins the team.
When hosting is part of a bigger change
If a hosting move coincides with a rebuild or platform migration, sequence the work so you are not debugging a new application and a new server at the same moment. A staging environment on the new host lets you test the application thoroughly before any public traffic arrives.
Turn this topic into a project plan
Use these supporting guides to prepare the details for your hosting discussion.
Put this into practice
Planning a move like this?
See how a scoped hosting migration project handles content, URLs, integrations and launch.