When a business chooses a platform for its website, the conversation usually centers on features, design and price. Those matter. But the decision that quietly shapes the next five years of cost is a different one: how the platform handles time. Every piece of software changes, and the question is whether those changes arrive on a schedule you can plan around or as surprises you have to absorb. Drupal's answer to this question is one of the strongest reasons we build on it, and it is rarely discussed outside developer circles. This article is an attempt to discuss it in business terms.
The calendar, in one paragraph
Drupal publishes its release schedule years ahead. A new major version arrives roughly every two years, in December. Between majors, a minor version arrives twice a year, in June and December, adding features while keeping compatibility. Each minor is supported for about a year: six months of bug fixes, then six months of security fixes. Security releases for core and covered modules go out on a fixed weekday, with advance notice for anything serious. And each major version is supported until shortly after the next one ships, so there is always a supported version to be on and always a known date by which to move.
That paragraph is the whole system. Everything below is about what it buys you.
Upgrades become line items, not projects
Because the dates are known, the work can be scheduled. A minor update in June and one in December. A major upgrade every two years, planned for a quiet month. Weekly security updates that take minutes. On a maintained site these are routine entries in a maintenance calendar with predictable effort next to each, and they can be budgeted the way you budget any recurring service.
Compare this with the alternative, where change arrives whenever a vendor decides, in whatever size, and every update carries a small chance of being the one that changes everything. Planning around that is possible, but it costs attention, and attention is expensive. A published calendar gives you that attention back.
Major versions are continuations
The word "major" sounds alarming, and there was a time when it deserved to. Since Drupal 8, however, each major release is built from the last minor of the previous one with deprecated code removed. Content, configuration, users and files carry over. Custom code that follows current APIs keeps working. Automated tools identify and rewrite most of what does not. The move away from Drupal 7 was the last rebuild; everything since has been a step.
The practical effect is that a Drupal site built well today has a clear path through Drupal 11, Drupal 12 and beyond, without a rebuild in sight. The investment in content modeling, integrations and design compounds instead of resetting.
Security on a schedule
Drupal's security team is one of the largest and longest-running in open source. It coordinates fixes for core and for every contributed module that opts into coverage, publishes them on a fixed weekly window, and announces highly critical releases in advance so teams can be ready. A release of that kind in May this year was announced days ahead and shipped in a stated window, and sites that follow the routine were patched the same evening.
For a business, that means two things. First, that vulnerabilities are handled by a process, not by luck. Second, that the process is visible: every advisory is public, dated and rated, so anyone can verify that a site is current. Verifiability is a quiet advantage that pays off the day a customer's procurement team asks.
Long support windows
Drupal 10 was released in December 2022 and is supported until December 9, 2026. Drupal 11 shipped in 2024 and will be supported until shortly after Drupal 13 arrives, roughly 2028. Four-year windows are long enough that a business can choose its own moment to move, rather than being pushed. They also mean that a site launched at any point in a version's life has years of runway before the next major decision.
Predictability lowers the cost of everything else
This is the part that is easy to miss. A predictable platform changes how you build on it. Integrations can be designed for the long term because the ground will not shift underneath them. A component library can be refined over years because it will still be relevant. Content models can be trusted to outlast the design that first displayed them. Sites that cost less to change are usually sites whose owners were able to invest in structure, and structure is only worth investing in when the platform will still be there to reward it.
Our own delivery model is built around this calendar. Maintenance plans are priced against it. Upgrade work is scheduled into it. Peak seasons are protected from it. The platform's predictability becomes ours, and then yours.
What this means for a decision you might be making
If you are choosing a platform, ask each candidate three questions: when is the next major version, how long is the current one supported, and where is that written down. Drupal's answers are public and have held for a decade. If you already run Drupal, the calendar is a tool: look up the dates, put them in your planning, and let upgrades become the boring, budgeted events they are meant to be. And if you would like help turning the calendar into a plan for your site, we are glad to do that.