WordPress maintenance and support
Launch is the start of the longest phase. We stay on as the development team for the platforms we build: updates, security patching, monitoring, and the new work that keeps arriving. It is handled by the people who wrote the architecture rather than by a support queue reading it for the first time.
- The developers who built it are the ones who maintain it
- Core, plugin and dependency updates applied on staging first
- Monitoring, backups and a tested recovery procedure
- Continuing development, not just keeping the lights on
Deferred maintenance is how platforms die
Almost every site we are asked to rebuild was maintained until it was not. An update broke something, so the next one was deferred. A plugin author stopped publishing, so that plugin was pinned. A year later core cannot be updated without breaking the pinned plugin, and the site is frozen, which is not a maintenance strategy. It is an unmanaged security position with a date on it.
The way out is unglamorous: apply updates on a schedule, on staging first, with someone accountable for the result. That is most of what a maintenance arrangement is actually buying, and it is worth considerably more than the monthly report it usually comes with.
What ongoing support covers
Core, plugin and dependency updates
Applied on staging, checked, then released, not applied blind on production. Where an update cannot be applied safely, the reason is documented and a plan exists to resolve it rather than to defer it again.
Security patching and hardening
Critical patches applied quickly, access and credentials reviewed, and the administrative surface kept to what is actually used. Security in WordPress is largely a governance question, so we document who has what and why.
Monitoring and uptime
Availability and error monitoring, so problems are found by us rather than reported by a user, including scheduled jobs and integrations that fail quietly.
Backups and recovery
Backups that are verified and a recovery procedure that has been rehearsed. An untested backup is a belief, not a safeguard.
Performance over time
Sites get slower as content grows. Queries, caching and Core Web Vitals reviewed periodically rather than only at launch.
Continuing development
New sections, new blocks, new integrations, changes to the content model. Most of our long-running clients spend more here than on maintenance, which is the sign of a platform being used rather than merely kept alive.
Support for the content team
The people using the CMS need answers too. Questions about blocks, layouts and publishing workflows reach the same team, so an editorial problem does not sit in a queue behind a code release.
Need a development team that stays?
Tell us what the platform is, what it integrates with, and what has been deferred. We will tell you what it takes to get it current and what it takes to keep it there.
What the arrangement actually looks like
Maintenance sold as a monthly report is mostly a monthly report. These are the things that have to happen for the arrangement to be worth its price, and they are the things we commit to in writing.
An assessment first
Before anything is agreed, the platform is reviewed: versions, dependencies, what cannot currently be updated and why, the integration surface, and the backup and access position. Both sides then know what is being signed up for.
A scheduled update cycle
Updates are applied on a defined cadence, on staging, checked, then released. Critical security patches jump the queue. Nothing is applied blind to production because it appeared in the dashboard.
A release process, not a sequence of edits
Changes go through version control and staging, with a note of what shipped and when. Production is never the place where work is tried out.
A standing backlog
Requests, deferred items and known problems live in one visible list with the reason each is where it is. Deferred maintenance is a decision that someone made, not a thing that quietly happened.
Reporting people can act on
What was updated, what broke, what was fixed, what is still outstanding, and what we recommend next. Short, and written for whoever has to justify the budget.
A named developer
The person answering knows the architecture because they wrote it. There is no first line reading the codebase for the first time while a form is down.
Four years on the same platform
The clearest evidence for this is not a maintenance contract, it is a development relationship that lasted. WPlook Studio held senior WordPress and systems architecture responsibility for the M3 Tech group across a four year engagement, from 2021 to 2025, covering Multi-Prêts, Mortgage Alliance, Invis, Mortgage Intelligence and Intelligence Hypothécaire.
We took the codebase over from the previous agency and stayed with it: continuing development alongside the updates, the infrastructure consolidated from twelve servers to two, and page load taken from sixteen seconds to under one. That is what the long phase looks like when it is working. Most of the spend in a relationship like that is new work rather than keeping the lights on, which is the sign of a platform being used rather than merely kept alive.
What this is, and what it is not
This is a development relationship, not a hosting product. We work on infrastructure the client owns or that their IT group has chosen, and we are glad to work alongside a managed host. Where an organization is looking for standalone managed WordPress hosting rather than a development partner, that is a different service and we will point you to one rather than bundle it.
We also do not take on support for a platform we have not assessed. Inheriting an unknown codebase and being accountable for its uptime from day one serves nobody. An assessment first tells both sides what is being signed up for, and occasionally concludes that the honest recommendation is to rebuild rather than to maintain.
Frequently asked questions
-
Do you support sites you did not build?
Yes, after an assessment. Taking uptime responsibility for a codebase nobody has read is how both sides end up unhappy. The assessment is short, it tells you what condition the platform is actually in, and occasionally it concludes that rebuilding is cheaper than maintaining. We would rather say that before a contract than after one.
-
Is hosting included?
No. This is a development relationship, not a hosting product. We work on infrastructure you own or that your IT group has chosen, and we work alongside managed hosts routinely. If what you need is standalone managed WordPress hosting, that is a different purchase and we will point you at one rather than bundle it.
-
What happens if an update breaks something?
Most of it is caught on staging, which is why updates go there first. When something does reach production and breaks, the fix is ours and it is not billed as new work. Where an update genuinely cannot be applied safely, the reason is documented and there is a plan to resolve it rather than another deferral.
-
Can you work alongside our internal team?
Yes, and it is a common arrangement. The usual split is that we hold the architecture, the release process and the parts that are expensive to get wrong, while an internal team handles content and day-to-day changes. Shared version control and a shared backlog matter more than where anyone sits.
-
What if we only need occasional help?
That works, but be clear about what it buys. Ad hoc support is fine for changes and new features. It is not a substitute for a scheduled update cycle, and a platform without one drifts into the frozen state this page opens with, usually within about two years.
-
How quickly do you respond?
It depends on what is agreed, and we would rather agree something we can hold to than publish a number. Security issues and anything affecting availability are handled immediately; ordinary requests run against the backlog. What you should ask any supplier is who specifically answers, and whether that person has read the codebase.