Choose hosting and retain control of your domain

Map the working chain

Record the domain registrant and registrar, DNS provider, email provider, website host and application platform. For each one, note the operational owner, renewal date and support route. A hosting invoice alone does not establish who controls the domain.

Identify dependencies before a migration: a DNS change may affect both the website and email; a certificate or caching layer may belong to another account. Keep a short service map without placing passwords or other secrets in the shared document.

Fictional DNS scenario with ordinary caching and no serving of expired answers: a response arrives at 09:00 with TTL 3 600 seconds. At 09:10, the authoritative server publishes TTL 300 seconds. The existing cached copy may remain usable until 10:00; the new setting does not retroactively make it expire at 09:15. TTL describes a caching duration in seconds, as RFC 1035 explains. Prepare the reduction before cutover and account for the previously published lifetime.

This single-cache calculation does not guarantee a worldwide cutover time: other caches, resolution policies and dependencies can intervene. Separate web A and AAAA records, incoming-mail MX records and authentication records, including SPF and DKIM TXT records where used. If nameservers change, inventory the whole zone before reproducing it with the new operator. Check the website and mail separately; successful website resolution or TTL expiry does not prove working email.

• Domain owner and renewal date recorded.
• DNS, email, hosting and application mapped separately.
• Owner and support route identified for each service.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

Compare offers against an actual scenario

Describe the site, media, traffic, storage and responsibilities before comparing offers. Fictional example: website and email share a domain but use two providers; a web migration should specify what remains unchanged for email. Have backups, recovery, certificates and support explained. An introductory price does not identify who handles failure or which data can be recovered.

Compare the same scope and period, including necessary options, renewal and work left to your team. If data location matters, check the region and contract documents for the precise service selected; one provider may offer several architectures and regions.

• Offers compared over the same period and scope.
• Backup, recovery and support described in writing.
• Recurring and exit costs visible.

Try recovery and departure

Ask how to retrieve files, database, media and the settings needed to run the site elsewhere. Check that an authorised person can reach backups and that restoration can be tested without overwriting production. A backup button alone does not show that the site will restart.

Plan a domain transfer separately from a website migration. Document timing, administrative access to hand over and who approves the cutover. The handover guide extends this list for a completed project.

• Content and data export tried.
• Recovery tested in a suitable environment.
• Separate domain and website transfer plan.

Maintain a usable register

Keep a register of registrants, providers, deadlines and dependencies, with backup ownership. Fictional example: the domain recovery address belongs to someone leaving the team; arrange a replacement before the next deadline and check alert delivery. Keep secrets in a suitable access manager, not in this shared register. Revisit it after each transfer or responsibility change.

The arrangement works when another authorised person can understand where to act during an outage or after a supplier leaves. An annual and renewal-time review helps uncover forgotten services.

• Dated register without secrets.
• Authorised people named.
• Provider replacement procedure understood.