Create a Hosting Exit Plan Before You Need One

Keep a record of the files, databases, DNS records and accounts you would need to move to another host. Store it outside the hosting account, alongside a tested backup and a migration sequence.

Keep your domain registration independent#

The single most important decision is where your domain lives. If the domain is registered through your hosting provider, a billing dispute or account suspension can lock you out of DNS management at the exact moment you most need to point the name somewhere else. Registering the domain elsewhere — or at minimum keeping the registrar account separate from the hosting account — preserves your ability to redirect traffic even when the host is unreachable. ICANN's guidance for registrants is worth skimming once, because it describes your rights when moving a name between registrars.

Run backups you control#

Every host offers backups, and the comfortable assumption is that this is enough. An exit plan calls for backups that exist outside the host entirely: database dumps and file archives stored in independent cloud storage, on an external drive, or with another provider. Cybersecurity guidance on protecting data with backups consistently recommends keeping copies separate from the primary system and confirming they can actually be restored. For a content-managed site, that means both the database and the content directory, not one or the other. Automate the schedule rather than relying on memory, and test a restore periodically, because an untested backup is a hope rather than a plan.

Prepare DNS before you move#

DNS changes take time to spread because resolvers cache answers for the period set in each record's TTL. If your records currently have a TTL measured in hours or a day, a migration means some visitors may reach the old server long after you have switched. The standard preparation is to lower the TTL on the records you will change to around 300 seconds — five minutes — a day or two before the move. The old value stays cached until it expires, so this has to happen in advance. Once the migration is complete and stable, raise the value again.

Know the transfer rules for domains#

If your exit involves moving a domain between registrars rather than only changing DNS, there are fixed waiting periods to plan around. ICANN policy locks a domain against transfer for sixty days after initial registration and after certain changes to registrant contact information. Domains are also commonly locked against transfer by default until you explicitly unlock them, and a transfer typically requires an authorization code from the losing registrar. None of this is a barrier, but discovering it mid-migration adds days you did not plan for, so check the status well ahead of time.

Keep a credential and record inventory#

The most useful part of an exit plan is often the least technical: a current written record of what exists. That should include database credentials, a copy of the full DNS zone including MX, TXT, and CNAME records rather than only the web-facing A records, third-party API keys and integrations, and the location of the most recent backup. Store it offline or in a password manager, and update it whenever something changes. During a move, this list is what you work through line by line, and its existence is what makes the migration boring instead of dramatic.

A schedule that keeps the plan honest#

An exit plan decays quietly. Backups stop running, DNS records change, a new integration is added and never written down. A short review twice a year — confirm backups are current, confirm the credential list matches reality, glance at the domain's transfer status and expiry — keeps the document aligned with the site. Pair it with a one-page summary of the migration order: lower the TTL, back up, restore at the new host, test, switch DNS, verify email routing, then decommission.

Keep the document somewhere findable#

An exit plan only works if you can find it during a stressful week. Keep it as a single page alongside your credential inventory, note where the backups are stored, and record the date of the last review. That is the entire discipline: a short, current, off-host record of what you run and how you would move it.