Support
Support, Hosting & Digital Rescue
This is the work that begins after something already exists: keeping a site up, moving it when it has to move, updating it before something else does, and finding the cause when it stops. Some of it is scheduled — an update window, a host-to-host move planned weeks in advance. Some of it starts with a white screen on a Tuesday morning and nobody able to say what changed.
What this fixes
There is no arrangement for it
The site was built, it went live, and nothing was agreed about what happens next. Nothing is monitored, nothing is patched, and there is nobody to ring — so the first sign of trouble is a customer mentioning it.
Whoever built it has gone
No logins, an unknown host, and a domain registered to an email address that stopped working when someone left. Recovering control is a job in its own right before anything can be improved.
You rent the website rather than own it
It cannot be exported, the layout cannot be changed beyond a few colours, and cancelling means losing the lot — sometimes including the address customers already know.
Email stopped arriving and nobody can say when
Quotes that never landed, invoices in spam folders, a supplier insisting they replied twice. When we trace one of these, the cause usually turns out to be in the records behind the domain rather than in the mailbox.
Every attempted fix moves the symptom
A setting is changed on the live site, the error becomes a different error, and nothing is written down. By the third attempt the original fault is buried under two more.
What’s included
- The fault reproduced before it is fixed
- Confirmed against the logs and on a copy of the real environment first, so the change that follows is aimed at a cause rather than at a symptom.
- Access and ownership, recovered
- Domain, registrar, nameservers, hosting, mail and repository traced, put in your name, and recorded.
- A written record of what runs where
- Host, registrar, nameservers, mail provider, platform versions and which account each of them sits under. Without it, an urgent change starts by working out who controls what.
- A named route in
- Somewhere to report a fault that is not a form into a queue, and an agreed order for dealing with things when more than one is wrong at once.
- Backups you can restore from
- Scheduled, held away from the server they protect, and restored at least once to prove they work. An untested backup is a hope, not a safeguard.
- A change routine you can read
- Updates staged, a rollback point taken first, and every change logged — see maintenance, below.
Hosting
Hosting is not a commodity line on an invoice. It decides how a busy morning goes, how quickly a fault can be traced, and who answers when something is wrong. We run WordPress and WooCommerce sites on LiteSpeed and cPanel environments configured for the platform, and Next.js and application work on Vercel, because a PHP stack and a JavaScript application want different homes. What this section does not cover is making an already-slow site fast: that is performance engineering and it sits under optimisation. If your current host is doing the job, we will say so and work with it.
- cPanel and WHM accounts provisioned per site, with their own users, limits and logs
- LiteSpeed or Apache, matched to what the site runs on
- Vercel for Next.js and application work, with the domain and certificates managed alongside it
- SSL issued, renewing automatically, and re-checked after any DNS change
- Error and access logs retained, so a fault from last week can still be looked at
- Uptime and resource monitoring, so a problem is noticed before a customer reports it
- Server hardening and a WAF in front of the sites that need one
Migrations
A migration is a continuity exercise that happens to involve files. The website is usually the straightforward part. What takes the planning is everything attached to it: the order placed while the nameservers were changing, the domain nobody could get the transfer code for, the addresses that quietly stopped resolving, and the mail — which we move as its own piece of work, with its own sequence and its own checks, rather than dragging it along behind the site. Two projects in the portfolio are this work. Cheviot Printers was moved off a restrictive Yell website onto a site the business owns, with the hosting and email infrastructure migrated alongside it. Millennium Refrigeration & Air Conditioning was a Joomla-to-WordPress migration, with the site redesigned and its services restructured as part of the move.
- Joomla and other legacy CMS platforms rebuilt on WordPress
- Exit from rented website packages that cannot be exported, Yell-style contracts included
- Host-to-host moves planned backwards from what the business cannot afford to lose
- Domain transfers, registrar changes and nameserver moves
- Store moves scheduled around trading, with payments and dispatch reconnected on the far side
- Redirect mapping for every URL that already exists somewhere — the ranking side of that is handled under technical SEO
Maintenance
The argument against maintenance is always the same: nothing is broken, so why pay to touch it. The answer is that a website is not a finished object sitting still. The server underneath it gets patched, the language version it runs on reaches end of life, plugin authors stop maintaining their work, and automated attacks spend all day looking for holes that were published months ago. Nothing changes for a year and then everything has to change at once. An update deferred long enough stops being an update and becomes a project; maintenance is the same work done in small pieces, on a schedule, while it is still small. Where the site is one we built, this is where the web development work carries on afterwards. Where somebody else built it, this is usually where we start.
- Core, plugin, theme and dependency updates applied on a staging copy first
- A rollback point taken immediately before every update window
- Unused plugins removed, abandoned ones replaced, and the reason recorded either way
- PHP and database versions kept inside supported ranges
- Security patches treated as urgent and separated from the routine window
- A change log kept with the site, so the next person can follow what happened and when
Troubleshooting and rescue
A white screen where the homepage was. A checkout failing at the payment step. A layout an update took with it, a server throwing errors under load, or a site that has been quietly serving somebody else's injected code for months. The method does not change with the fault: reproduce it, read the logs, isolate the cause on a copy of the site, make the smallest change that fixes it, then write down what it was. The repair is rarely the hard part. The hard part is establishing what actually happened on a system where three people have already tried something, none of it was recorded, and the only witness is a week of server logs nobody has read. A site that has become slow rather than broken is a different job — that is performance work, and it is covered under optimisation.
- White screens, fatal errors and server 500s traced through PHP and server logs
- Plugin and theme conflicts isolated by elimination on a staging copy
- WooCommerce faults across checkout, gateways, stock and order emails
- Compromised sites cleaned, hardened and checked for what was left behind
- Half-finished work put right: a migration abandoned mid-way, an update applied to files but not the database
- Scheduled jobs that silently stopped — order emails, reminders and overnight imports nobody noticed had gone
- Legacy clean-up: dead plugins, orphaned themes, tables nothing reads any more
Email systems
When we trace a mail fault, the cause is usually somewhere other than the mailbox. The records that authorise your senders were never finished. A website is sending from your domain through a web server that no receiving system has any reason to trust. A migration moved the site and left the MX records aimed at a host that no longer exists. Mail is also the part of any move with the least tolerance for being wrong: a website that is down is visibly down, whereas mail being quietly rejected looks exactly like nobody writing to you. So it gets its own plan and its own verification rather than being treated as a folder to copy across. Cheviot Printers is the portfolio example — email problems that had persisted for more than five years, resolved when the email infrastructure was migrated.
- MX, SPF, DKIM and DMARC audited and set for every legitimate sender, including the ones nobody remembers
- Website and application mail separated from staff mail, so a contact form cannot affect how your people's messages are treated
- Transactional and notification mail routed through a mail service instead of being sent by the web server
- Mailbox migration with folders, calendars, aliases and mail flow carried across
- Shared mailboxes, distribution addresses and forwarding rules rebuilt around how the business really works
- Deliverability checks: blacklist listings, alignment and how the domain looks to a receiving filter
- Every DNS record documented, so the next host change does not take mail with it
Infrastructure
Above any individual site sits the arrangement around it: which nameservers are authoritative, where each system lives, whose account it is billed to, how a change reaches production, and what happens when one of those pieces fails. When we take this on, we usually find it has never been written down in one place, because it was assembled in fragments over several years by whoever set up each part. We map it, remove what is no longer earning its place, and document the result so it can be handed to anyone — including a developer who is not us.
- DNS mapped and consolidated, with a note on what each record is for
- Domains, registrars and renewal dates collected onto one list somebody owns
- A staging environment running the same stack and versions as production
- Deployment through Git rather than by uploading files, so any change can be reversed
- A backup strategy covering files, database, mail and the configuration itself
- Accounts, licences and who holds them, recorded in one place and kept current
Built with
- cPanel
- WHM
- LiteSpeed
- Apache
- Cloudflare
- Vercel
- Git
- MySQL
- MariaDB
- Wordfence
- WAF configuration
- Server hardening
- SPF / DKIM / DMARC
Questions
- Do we have to host with you?
- No. If your current hosting is adequate we will work with it, and we will tell you plainly when it is not. What we do need is proper access — the control panel, DNS and the domain registrar. A server's logs cannot be read through somebody else's support queue, and most diagnosis starts in the logs.
- Can you take on a site somebody else built?
- Yes. The first task is establishing what is actually there and getting hold of it: platform and versions, host, DNS, mail provider and which account holds the domain. That is an inventory of what you own and where it lives, so the site can be run and repaired. If what you want instead is an assessment of how well the site is performing and what to fix first, that is an audit, and audits are handled on the optimisation page.
- Will a migration take the site offline?
- It should not. The new environment is built and tested in full, the old one keeps running while that happens, and DNS is the last thing to move rather than the first. The window that matters is the one after the switch, so the new environment is watched through it and the old one stays available until there is no reason to keep it.
- Is this worth maintaining, or is it past that point?
- That is the question to settle before agreeing to look after anything. A site is worth maintaining while it can still be updated safely: a supported platform, a theme and plugins that still have maintainers, and code somebody can read. It is past that point when updates cannot be applied without breaking the layout, or when the platform itself is no longer supported, because from that point maintenance turns into patching around it indefinitely. We will say which of the two we think you have and what we based that on. If the real problem is speed rather than maintainability, that is performance work and it belongs on the optimisation page.