GuidePlatforms & Tools

What to check before renewing or moving your website hosting

Compare the renewal bill, operational limits and recovery plan before a discount turns into a more expensive move.

A website page crossing a bridge between hosting stacks, beside a shield and backup container.
On this page

Before renewing or moving hosting, assemble three things: the real next-term bill, a list of what the site depends on and a tested way to restore it. These tell you more about the decision than an introductory monthly price or an unverified claim that one provider is faster.

A renewal is a reasonable time to review the arrangement. It is not automatically a reason to migrate. The right comparison includes the work and risk of changing providers as well as the cost of staying.

Price the term you will actually buy

Get the renewal amount for the exact plan and billing period. Distinguish an advertised monthly equivalent from the total charged upfront. Record the currency, applicable taxes, renewal date, cancellation deadline and any automatic renewal setting.

List separately priced dependencies: domains, email, backups, storage, migration assistance, security services and paid software licenses. Ask which introductory inclusions expire and what restoring a backup costs. A feature that appears in a plan name may still have limits or optional charges.

Compare the same workload and period at each provider. Avoid a three-year promotional price on one side and a one-year renewal price on the other without making the difference visible. If the terms are unclear, obtain a written answer before relying on the number.

Treat your own migration time as a cost. So are overlap between accounts, specialist help and any reconfiguration of mail or publishing tools. A modest saving can remain worthwhile, but it should survive this fuller calculation.

This checklist does not rank providers or report speed tests. Published offers change, and the useful price is the one available for your plan, location and renewal circumstances when you decide.

Translate limits into the jobs your site does

Identify what consumes resources: article pages, image delivery, search, scheduled tasks, backups, imports, newsletters and administrative work. A mostly static publication has different requirements from a CMS that builds pages and queries a database for each visit.

Ask how the provider defines and enforces storage, traffic, CPU, memory, concurrent processes and file-count limits. Find out what happens at a limit: a warning, a charge, throttling or a stopped service. Do not assume a generous bandwidth allowance removes other constraints.

Check the software versions the site needs and how the provider handles supported versions and updates. If an agency or developer manages the application, ask it to confirm compatibility instead of relying on the host’s marketing category.

Define the support boundary. Who investigates a failed deployment, restores a database, fixes a plugin conflict or responds outside business hours? Ask about response commitments and the distinction between responding to a ticket and resolving the fault.

Use an actual issue from your operating history if you have one. Describe the failure and ask what the plan would cover. Avoid inventing a test incident or claiming a response time you have not measured.

Prove you can recover and retain control

A backup is only useful if it contains what the site needs and someone can restore it. For WordPress, the official backup guidance distinguishes the database from the files; a typical full recovery requires both.

For any platform, list the recovery ingredients: content, media, application or build files, configuration, redirects and any separate databases. Identify secrets that need secure recovery without putting them in a publicly downloadable archive.

Restore a recent backup into a private test environment. Check a current article, an older article with images and the actions the site depends on. Record the backup date, what was restored and anything missing. Merely seeing a successful backup-job message does not answer those questions.

Check account ownership too. The right person should control domain registration, DNS, hosting billing and recovery channels. Keep access available to the organization or owner if a contractor leaves. Use separate accounts and appropriate permissions where the services support them.

The maintenance routine turns these checks into ongoing work, so the next renewal does not become the first time anyone asks where the backups are.

Build a migration plan before changing DNS

Inventory every service attached to the domain. Website hosting and email may be supplied together or separately, so identify the relevant records before replacing anything. Preserve a copy of the existing DNS configuration and agree who will make and verify the changes.

Move a copy first and test it privately. Compare URLs, redirects, images, forms, login, scheduled tasks and the publishing workflow. On a CMS, account for writes made after the initial copy: a newly published article or a form submission can otherwise be left behind.

The WordPress migration handbook explains that the correct procedure depends on what is moving, including whether URLs change. A server move and a domain change are different jobs. Do not add a new URL structure to a hosting migration without a separate reason and plan.

Define the change window, final synchronization, verification steps and rollback trigger. Assign one person to decide whether the new environment is acceptable. Avoid relying on the expectation that somebody will notice a problem.

Cancel only after the dependencies are accounted for

After the switch, verify the live site from ordinary reader and editor paths. Check the intended destination, secure connection, mail if affected and any external services that depend on the old environment. Review logs and monitoring for failures that a homepage visit would miss.

Keep the old service available for the agreed overlap and recovery period. The right duration depends on the setup and business needs; there is no universal cancellation day. Confirm that you have exported necessary data and can access independent backups before the account is closed.

If traffic falls after a move, use a structured traffic-drop investigation, starting with access, tracking and URL changes. Do not immediately attribute it to the new host’s search performance.

Finish with a short handover: who owns each account, where recovery material is kept, what changed and when the next renewal occurs. A hosting decision is complete when the site can be operated and recovered by the people responsible for it.

Primary sources