Is my host making my store slow? Moving without downtime

The store is slow and the host says it's your site

Your store is slow on a quiet Tuesday morning, not just during sales. The admin takes seconds to open each order. You've installed a caching plugin and compressed the images, and it's still slow. When you contact the host, the answer arrives two days later and says your plugins use too many resources, with an offer to upgrade.

Maybe they're right. Sometimes the site really is the problem. But sometimes a store has simply outgrown a cheap shared plan, and no amount of plugin tuning will fix that. You need to know which, because the fixes are completely different.

What keeps most owners on a bad host is fear of the move itself: downtime, broken checkout, lost orders, email that stops working. Those risks are real, and they are all manageable with a plan.

Why it happens

Shared and oversold hosting

On shared hosting, your store shares a server with many other sites. Plans limit CPU, memory, PHP workers and database connections, and some hosts throttle accounts that use more. When a neighbor gets busy, your store slows down too. Entry plans are built for brochure sites, not for a store that runs PHP and database queries for every cart and checkout.

Signs the host is the bottleneck

I look for a pattern before blaming anyone:

• Slow server response on simple requests. If a tiny static file or a minimal PHP test page is slow, the problem is below WordPress.
• Response times that change with the time of day while your own traffic is steady.
• Resource limit errors in the hosting panel: entry process limits, CPU throttling, memory caps.
• An old PHP or database version you can't change.
• No object cache available, or no way to run a real server cron.

Signs the site is the bottleneck

• A profile shows one plugin, hook or query taking most of the request time.
• Huge autoloaded options in the database.
• The same slowness on a staging copy on a fast server.

Often it's both: a heavy site on a weak host. Then I fix the worst of the site first, so we don't move the problem to a new server.

Why moves go wrong

• Orders placed during the switch land on the old server after the database was copied, and get lost.
• DNS takes time to change for some visitors, so both servers receive traffic for a while.
• Email records are forgotten, and mail stops.
• Cron jobs, SSL certificates and file permissions don't come across, so subscriptions stop renewing or pages show errors.
• There's no way back if something breaks.

What fixing it involves

1. Measure first

I measure server response time on simple and heavy requests, profile the slowest pages, and check the hosting limits. You get a short written answer: host, site or both, with the evidence. If the site is the main cause, I fix that before moving anything. See why WooCommerce slows down at scale.

2. Choose where to go

The choice depends on traffic, peaks, the team and who will run the server:

• Managed WordPress hosting for stores that want updates, backups and security handled by the host, within its limits.
• A VPS, for example on Hetzner or AWS, with a panel or a hand-built stack, for stores that need more capacity and control, with someone responsible for running it.

Either way I check: current PHP and database versions, enough PHP workers, an object cache, real cron, off-site backups, and a location close to most customers. Cloudflare goes in front for DNS, caching and the firewall.

3. Build and test a staging copy

I build the new server and copy the site to it on a temporary address. Then I test everything as a customer and as staff: browsing, search, cart, checkout with a test payment, account pages, emails, subscription renewals, admin screens, scheduled tasks. Payment gateway webhooks get pointed at the right place. Measurements on the new server confirm it's actually faster before anything changes for customers.

4. Prepare DNS

A day or two before the move, I lower the TTL on the records that will change, so the switch takes effect in minutes instead of hours. I copy every DNS record to the new setup, including MX, SPF, DKIM and DMARC for email, and any verification records for Google, Meta or the payment provider.

5. Cut over without losing orders

For most stores, I pick a quiet hour and use one of two approaches:

• A short checkout freeze. The old store shows a brief maintenance notice on checkout, the final database copy runs, DNS switches, and checkout reopens on the new server.
• A delta sync. The store stays open, and orders, customers and stock changes placed on the old server during the switch get copied across afterwards.

SSL certificates are issued on the new server before the switch, so visitors never see a warning.

6. Check, then keep the way back open

Right after cutover I place a real test order, check emails, renewals, cron and webhooks, and watch error logs and response times. The old server stays untouched for a set period. If something serious appears, DNS points back in minutes.

7. Hand over

You get the new server's details, the backup and restore setup, monitoring with alerts, and a short note on what changed. If backups are part of the move, read backups that actually restore. Running and protecting the server afterwards is part of my security, infrastructure and site care service.