Choosing a web host before migrating a website

What to Ask Your Host Before You Move a Site

Moving a website to a new host is usually presented as a technical task, and it mostly is. But the part that decides whether it goes smoothly happens before anything moves, in a conversation with the host you are considering.

The questions below are the ones that separate hosts whose plans look similar on a pricing page. Most can be answered by support in a few minutes, and the answers tell you more than any review.

Ask What the Plan Is Actually Sized For

Hosting plans advertise storage and visits, and neither tells you much. The question that matters is how much processing power and memory your site can use, and what happens when it needs more.

Ask directly: what are the limits, and what happens when I hit them? Some hosts slow the site, some queue requests, some return errors, some charge for the overage. All of those are workable if you know which one applies. None are workable as a surprise.

Also ask whether those resources are shared. A cheap plan is cheap because many sites share a server, and a busy neighbor can affect you. That is an acceptable trade for a small brochure site and a poor one for a store.

Ask How Backups Work, and How Restores Work

Nearly every host advertises backups. Fewer make it easy to restore one, and the second part is what you actually need.

Ask how often backups run, how long they are kept, whether they are stored somewhere other than the same server, and whether you can restore a single file or only the entire site. Ask whether you can trigger a restore yourself or must open a ticket and wait.

A backup on the same machine as the site protects against your mistakes but not against the machine failing. That distinction only matters once, and by then it is too late to change hosts.

Ask What Access You Get

This one is easy to skip and expensive to discover later. Ask whether you get SFTP and command line access, whether you can reach the database directly, and whether there is a staging environment included.

Staging matters more than most people expect. Without somewhere to test changes safely, every update becomes a small gamble on the live site, and the pressure to skip testing grows over time.

Ask about server logs too. When something breaks, the error log is where the answer is, and a host that does not give you access to it is a host you will be waiting on for every diagnosis. That difference is part of what a deeper site audit can reach and a surface review cannot.

Ask What They Update, and What You Update

Managed hosting means different things at different companies, and the word alone tells you nothing.

Ask specifically: do you update the server software, the platform, plugins, or none of those? If plugins are updated automatically, what happens when an update breaks the site, and who fixes it? Automatic updates are a genuine benefit and also a common cause of unexpected breakage, so the answer to the second half matters.

Ask how quickly they apply security patches at the server level, and whether you are told when they do. Silence during an urgent patch is worse than an inconvenient maintenance window.

Ask Where Your Email Lives

Email is the most commonly forgotten part of a move, and the most disruptive when it goes wrong. Some hosts provide mailboxes with the hosting plan, some expect you to use a separate provider, and the difference decides how careful the move has to be.

Ask whether email is included, and if it is, what happens to those mailboxes when the site moves. If your email lives with your current host, plan to move it separately and first, because pointing a domain at a new server without handling email can stop mail arriving with no obvious warning.

If you are unsure where it lives today, find out before anything else. It is a five minute check now and a bad afternoon later.

Ask About Uptime and What Happens When It Drops

Every host advertises high availability. The useful questions are what they publish, and what they do when it is not met.

Ask whether there is a public status page, how customers are notified during an incident, and whether the uptime commitment carries any remedy. A host that posts incidents openly is usually more reliable in practice than one whose status page has never shown a problem.

Ask what monitoring exists on their side. Knowing whether they will notice an outage before you do, and whether anyone acts on it outside office hours, tells you how a bad night will actually go.

Ask What Support Actually Covers

Support is where hosts differ most, and where marketing language hides the most.

Ask what hours real humans are available, what the typical first response time is, and whether support will look at an application level problem or only at server issues. A host that says a slow site is your developer’s problem may be technically right and still leave you stuck.

Ask whether they will help with the migration itself, and what that includes. Many hosts migrate sites for free as a sales incentive, which is worth having, though it is worth asking who checks that everything works afterward.

Test the Support Before You Commit

Support quality is the hardest thing to judge from a website and the easiest to test directly. Before buying anything, send a real question through their pre-sales channel and another through their technical support if it is open to prospects.

Time the reply, and read it carefully. Did a person answer the question you asked, or paste a link to a help article that covers something adjacent? Pre-sales replies are usually the fastest a company ever moves, so treat that response time as the best case rather than the average.

Ask something specific enough to require thought, such as what happens to scheduled tasks during a server migration, or how they handle a site that exceeds its memory limit. The quality of that answer predicts what you will get on a bad day better than any published guarantee.

Ask the Awkward Questions About Leaving

The time to understand how you leave is before you arrive. It is also a useful test of how a company behaves.

Ask whether you can take a full copy of your site and database at any time without asking permission. Ask whether the control panel or any proprietary tooling would make moving harder. Ask what happens to your data after you leave, and for how long they keep it.

A host that answers those questions plainly is telling you something about how it treats customers. One that becomes vague is telling you something as well.

Check the Price You Will Pay in Year Two

Hosting is often sold at an introductory rate, and the renewal is where the real price lives. Ask what the plan costs at renewal, not what it costs today.

Ask what is extra as well. Backups, staging, a certificate, additional storage, and migration help are included by some hosts and charged by others, and a cheap plan with four paid extras is not a cheap plan.

Ask how many of those answers are written down publicly. A host whose limits, backup policy, and support scope are documented has thought about them and expects to be held to them. One that prefers to answer case by case is harder to hold to anything later.

Match the Answers to Your Actual Site

There is no universally correct host, and the right answers depend on what you are running.

A brochure site that changes twice a year needs reliability and good backups more than raw capacity. A store needs capacity at peak, fast support, and staging, because a broken checkout costs money by the hour. An application with background jobs and scheduled tasks needs control over the server and somewhere proper to run them.

Work out which of those you are before comparing plans, because otherwise you will compare prices, and price is the least informative number on the page. Our hosting and maintenance work starts from that question rather than from a plan tier.

Ask What Happens to Scheduled Tasks

Sites run work in the background: scheduled publishing, reports, subscription renewals, abandoned cart emails, and backups. These break quietly during a move, and nobody notices until something that should have happened did not.

Ask how the host runs scheduled tasks, whether they replace the platform default with a server level schedule, and what the minimum interval is. Then check after the move that each scheduled job has actually run, rather than assuming it came across with the files.

Then Plan the Move Itself

Once you have chosen, the migration has its own risks, and they are well known enough to be planned around: email that stops arriving, forms that quietly fail, redirects that never get recreated, and the gap while the internet learns the new address.

Move a copy first and test it fully on the new host before pointing anything at it. Check forms, payments, logins, and scheduled tasks rather than assuming they came across. Keep the old site available until you are certain, and lower the time to live on your domain records a few days in advance so the switch propagates quickly.

We covered the full list of things that go wrong, and how to avoid each one, in what actually breaks when a site migration goes wrong. The short version is that the moving is straightforward, and the checking is what protects you. Our migration work is built around that order.

Frequently Asked Questions

What happens when my site needs more resources than the plan allows. The answer, whether it is throttling, queuing, errors, or extra charges, tells you how your site will behave on its busiest day, which is the day that matters most.

It depends what is being managed, and that varies widely. Ask exactly what they update and who fixes it when an update breaks something. Managed hosting that includes real support and staging is usually worth it. Managed hosting that only means automatic updates with no support behind them is less compelling.

Restore one. A backup that has never been restored is untested. Ask whether you can restore a single file or only the whole site, whether you can do it yourself, and whether the backup lives somewhere other than the same server.

If you change your site more than occasionally, yes. Without it, every plugin update and design change is tested on the live site in front of customers. Staging is what makes it possible to check first, and its absence is a common reason updates get postponed until something breaks.

Not by itself, provided URLs stay the same, redirects are preserved, and the site is not down for long. Rankings tend to suffer when a migration loses pages or breaks links, not because the server changed. The checking before and after is what protects it.

It is usually worth accepting, since they know their platform. Just be clear about who verifies the result. A migration is complete when forms, payments, logins, scheduled tasks, and email all work, not when the files are copied.

The technical move is often a few hours for a straightforward site. The time to allow is for testing and for the domain change to reach everyone, which can take up to a day or two. Plan for a quiet period rather than a busy one.

A full copy of the site and database, downloaded and stored somewhere of your own, plus access to the old account for at least a month. Email is the usual thing forgotten, so confirm where it is hosted before you cancel anything.

Ready to Start?

Related Posts