Classify
Every available update is categorised: security, fix, new feature or major change. Security ones do not wait for the monthly cycle and are applied immediately.
Upkeep module
Tested updates, backups actually verified
The boring part, done with discipline. Nothing reaches production untested, nothing changes without being recorded, and a backup is not considered working until it has been restored.
The real problem
Either nothing is updated, or everything is updated blindly
A site left unpatched for months accumulates published vulnerabilities that automated scanners look for daily. A site with automatic updates on everything eventually breaks itself, and nobody notices until a customer calls to say they cannot place an order.
Both situations come from the same place: the absence of a process. Updating is not a matter of pressing a button. It is a matter of knowing what changes, checking beforehand, being able to revert instantly, and having proof that everything still works afterwards.
The update process
What happens before anything reaches your site
Read what changes
Not only the version number. Release notes say whether a feature is being removed, whether the database structure changes, or whether PHP requirements change. This is where problems are caught, before they exist.
Restore point
A complete restore point, files and database, immediately before any intervention. This is not the theory of the daily backup, it is the exact state of five minutes ago.
Apply on staging
On an identical copy of production. There we verify the flows that matter: forms submit, the basket completes, login works, search returns, payments go through.
Compare visually
Before and after captures, on the main pages, on mobile and desktop. A theme update can break a layout with no error in the logs, so the eye stays part of the process.
Publish and verify
The change moves to production, then is verified there again. Error logs are watched over the following hours. If anything appears, reverting is immediate rather than an emergency operation.
Backup
An untested backup is an assumption, not insurance
| Element | How we treat it | Why this way |
|---|---|---|
| Frequency | Daily for database and files, plus a point before every intervention | It limits maximum loss to one day of content, and to zero around updates |
| Location | On different infrastructure from the site, never only on the same server | A backup sitting next to the site disappears with it, and the same applies to ransomware |
| Retention | Thirty days of daily copies, plus monthly copies kept longer | A compromise or data corruption is often discovered weeks later |
| Verification | Actual restoration in an isolated environment, confirming the site really starts | Most failed backups look perfect in the list until the day you try them |
| Recovery time | Measured and communicated, not estimated | You need to know beforehand how long recovery takes, not find out during the incident |
| Access | The copies are yours and you can download them at any time | You are not held captive. If you leave, you leave with everything |
Continuous monitoring
Availability checked from several locations at short intervals, so a real outage is not confused with a local network problem. We also track response time, because slow degradation almost always precedes an outage.
Alongside that: certificate expiry, domain expiry, remaining disk space, errors in the logs, scheduled tasks that have stopped running and stuck queues. The alert reaches us, not you, and you find out what happened only after it is resolved.
Change records
Every intervention is recorded: what changed, who did it, when, why and how to revert. Not for bureaucracy, but because four months later, when something behaves oddly, the question "what changed" has to have an exact answer.
It is also what an auditor asks for if your organisation goes through an ISO 27001 process. We are not a certification body and we do not certify your site, but the evidence an auditor would want already exists: access control, change records, verified backups, logs and a documented recovery procedure.
Included working hours
Content changes, visual adjustments, corrections, new pages, plugin configuration, simple integrations. The normal requests of a normal month, without opening a budget discussion every time.
Anything exceeding the included hours is estimated beforehand, in writing, at a firm price. You do not get a surprise invoice for work you have not approved.
Database hygiene
A WordPress site left to itself accumulates: unlimited revisions for every page, expired transients that never get deleted, tables left behind by plugins uninstalled two years ago, options loaded on every request that nobody needs any more, and stuck task queues.
We clean periodically, with a backup before and verification after. The result is a smaller database, faster queries and a backup that no longer takes a quarter of an hour.
What you get every month
- The list of applied updates, with the old and new version for every component
- Updates deliberately deferred, with the reason and the plan for them
- Backup confirmation, including the result of the tested restoration
- The month's availability, with every interruption, its duration and its cause
- Errors from the logs, grouped and explained, not exported raw
- Content and configuration changes made at your request
- Hours consumed from those included and what remains
- What we recommend for next month, ordered by real priority
Frequently asked questions
Why not simply turn on automatic updates?
Because automatic updates have no way of knowing whether your site still works afterwards. A plugin update can change the structure of the checkout form at three in the morning and you will find out four days later, when you wonder why no orders are coming in. Security updates are applied immediately. Everything else is tested.
How often do you back up?
Daily for the database, daily for files, retained for thirty days, plus a monthly copy kept longer. Copies are held somewhere other than the site, because a backup on the same server disappears along with the server. Restoration is actually tested, not assumed to work.
What is included in the hours?
Content changes, layout adjustments, corrections, plugin configuration, adding pages, simple integrations. Practically, what you would normally ask a developer for in an ordinary month. Building a new feature is estimated separately, and you decide beforehand rather than afterwards.
Do you have a staging environment?
Yes, for every site under management. An identical copy of production, isolated and non-indexable, on which every change is applied and verified before it reaches your visitors.
What if the site goes down at two in the morning?
Monitoring alerts us within minutes. If it is something we can fix, we fix it. If it is at the hosting provider, we open the case ourselves and follow it. In both situations you get a notification with what happened and when it was resolved, without having to chase us.
Stop thinking about this
We take over the updates, the backups, the monitoring and the day to day requests. You get a monthly report and quiet.
From the same section