Server management.
Overview
Cheap shared hosting is fine until it is not. The site slows down at the worst possible moment, support cannot say why, and upgrading PHP feels like a risk nobody wants to own.
The awkward truth is that most “the website is slow” problems are not the website. They are one layer underneath it, and the reason they go unfixed for years is that the layers are invisible from the dashboard. Somebody installs a caching plugin, the real bottleneck is the database, and everyone concludes that WordPress is just slow.
We set up and look after hosting that fits the site, from a well-configured managed host to a dedicated Linux server, and we work on all the layers rather than the one you can see.
What is actually under a website
Click through it. Each layer has a job, a handful of things worth tuning, and a way it typically goes wrong.
That is the whole argument for managing the server rather than just the site. Five of those six layers are invisible from the WordPress dashboard, and four of the six are where the interesting problems live.
The checklist we follow when moving hostsChoosing the hosting, honestly
We are not a host and we do not resell one, which means we have no reason to talk you into anything. The choice comes down to traffic, budget and how much control the site actually needs.
Managed WordPress hosting suits a site that wants to be left alone, where paying somebody else to hold the pager is worth the monthly premium. A cloud server suits a site that has outgrown that, or one paying managed prices for traffic that a modest box would shrug off. The honest test is usually whether anyone has ever needed the things the managed plan charges for.
Setting it up
- Sized against real traffic, not the peak you had once in 2021
- HTTP/2 or HTTP/3, TLS renewing automatically and checked that it did
- Page and object caching configured, then verified as actually working
- Firewall closed by default, SSH by key, no password logins
- DNS, SPF, DKIM and DMARC set so your mail arrives in inboxes
- Everything written down, so the setup is not a person
Keeping it up
- Operating system and package patching on a schedule, with reboots planned
- PHP upgraded deliberately, tested on staging, not left on an unsupported version
- Off-site backups, versioned, with a restore performed and timed
- Monitoring on uptime, disk, memory, load and certificate expiry
- Alerts that reach a person, not a dashboard nobody opens
- A monthly note of what was patched and what is worth watching
Migrations
A migration is the one piece of server work where the failure mode is public. Done properly nobody notices, which is why it is worth describing what properly means.
- 01
Inventory first
Days 1–2Everything the site depends on gets written down before anything moves: cron jobs, mail, API keys tied to an IP address, that one script somebody set up in 2019. Migrations rarely fail on the database. They fail on the thing nobody remembered.
A written list of everything that must follow - 02
Build and test in parallel
Days 2–4The new server is built and the site is copied across while the old one carries on serving. We test on the new server by address, before any DNS changes, so problems are found with no traffic watching.
A working copy, tested before anyone sees it - 03
Lower the TTL and wait
Day 4DNS time-to-live drops to a few minutes, a day ahead. This is the step that turns a bad migration from an afternoon into five minutes, and it is the step most often skipped.
A rollback that takes minutes - 04
Final sync and switch
Day 5, quiet hourContent is frozen briefly, the last changes are synced, and DNS is pointed at the new server. The old server stays running and reachable, because a migration is not finished the moment DNS changes.
Live on the new server, old one still up - 05
Watch, then retire
Days 5–12Logs on both servers are watched while DNS propagates, mail delivery is checked, and the TTL goes back up once it is settled. The old server is only decommissioned after a week of quiet.
Old server retired, not just abandoned
A straightforward WordPress migration. Anything with custom services or a live checkout is scoped on its own.
What you get
- Hosting chosen for your traffic and budget, by somebody who does not sell hosting
- The server or managed host set up, secured, tuned and documented
- Operating system and software patching on a regular schedule
- PHP, caching and the database tuned for your site’s actual traffic
- DNS, SSL and email authentication configured and verified
- Monitoring and alerts that reach a person
- Migrations run to a written checklist, with a rollback that takes minutes
- Someone who answers when something goes wrong at an unreasonable hour
Questions we get asked
Our host says the site is slow because of WordPress. Is it?
Sometimes, and often not. It is a convenient answer because it is somebody else’s problem. The way to settle it is to measure: server response time separately from page render, slow queries separately from PHP time. That takes an afternoon and ends the argument with a number rather than an opinion.
Do we need a dedicated server?
Probably not. Most sites that think they do actually need their current hosting configured properly, and most that genuinely do have outgrown it quietly over years. We will tell you which one you are, and the answer is more often "your managed host is fine, the database needs an index".
Will a migration cost us traffic?
Not if the URLs do not change and the DNS is handled properly. Search engines do not mind a site moving servers; they mind pages disappearing. The risk in a migration is the redirect map, not the hardware.
Who owns the server?
You do. It is in your account, on your card, with your name on the domain. We work in it. If you stop working with us you keep the server, the documentation and the access, and nothing needs to be handed over because it was never ours.
What happens at 3am?
Monitoring alerts a person, not a dashboard. We will be straight with you: we are a small team, not a 24/7 operations centre, and we do not sell a guaranteed overnight response we could not honour. What we do offer is that alerts reach somebody and that the rollback paths exist so most incidents are short.
Can you work with our existing host?
Usually, yes. Managed hosts vary in how much access they allow, and on some of them a few of the tunings above are simply not available. We will tell you what can and cannot be done there before you pay for anything.