A delayed update is a loan. The balance is small at first and the interest is invisible, so it never feels urgent. Six months later it is still invisible. Twelve months later the bill arrives all at once, and it is rarely a polite one.
We have picked up a lot of sites from this point in their life. The pattern is consistent enough that we can sketch the cost curve on a napkin before we even open the codebase.
What a year of "we'll get to it" actually costs
Imagine a mid-size Drupal site that stopped getting regular updates about a year ago. Nothing dramatic happened — the team got busy, the agency contract ended, the previous developer moved on. Traffic stayed roughly the same, content kept flowing, and from the outside nothing looked wrong.
When we open that site, we usually find four things at once. Drupal core is several minor versions behind, which means the upgrade path no longer runs in a single step. Half a dozen contrib modules have major-version jumps with breaking changes. A couple of custom modules were written against APIs that have since been deprecated and removed. And the PHP version on the server is either at end-of-life or close to it.
None of those are disasters on their own. Together, they turn what should have been twelve small two-hour updates into one six-week project with staging environments, regression testing, editor retraining, and a deployment window that cannot be moved. The same work costs several times more when it is done this way.
The quieter cost is the one that hurts
The upgrade bill is obvious because it shows up as a quote. The costs that hurt more are the ones that never appear on an invoice.
An outdated site is slower for visitors, which means fewer of them convert into leads, customers, or signups. It is harder to change, which means every new feature takes longer than it should and some features get quietly abandoned. It is riskier for editors, who start avoiding parts of the admin interface they no longer trust. And it falls behind on security, which is the one risk that is entirely avoidable with steady care.
A healthy site is the opposite of all of those. Pages respond faster, editors move faster, new campaigns go live faster, and your team stops thinking about the website as a source of stress.
What steady care looks like in numbers
Sites we maintain continuously have a very different profile. Core security releases land within days. Module updates are batched monthly, after being tested on a staging copy of production. Major upgrades are done once per Drupal release cycle, inside the normal rhythm, without a project plan. The "upgrade project" line item simply does not exist, because the site is never far enough behind to need one.
The annual cost of that care is lower than the emergency catch-up we just described — often by half, and far more predictable. It is easy to budget, easy to justify to a finance team, and easy to stop thinking about.
The honest takeaway
If your Drupal site has not had steady care in a while, the longer you leave it the more expensive the correction gets, and the more of that correction will be wasted on catching up rather than moving forward. The good news is that the curve is reversible. Sites we pick up in rough shape are usually back on a healthy rhythm within a month or two, and from that point the conversation changes completely — from "what broke" to "what should we build next."
If you are not sure where your site sits on that curve, we are happy to look. No sales pitch, no scary PDF. Just an honest read of where it is and what the next three months would cost to get it healthy.