Hiring a Drupal, Joomla or PHP development company, where the published support window is the number that decides the quote

Before you compare day rates for work on Drupal, Joomla or a plain PHP site, ask one question and get the answer in writing. Which version of the platform and which version of PHP will this run on, and on what date does each of them stop receiving security fixes? Those dates are published by the projects themselves, they are not a matter of opinion, and they decide whether you are buying a site or buying a site plus an upgrade project you have not agreed to yet.

There is real demand behind these platforms despite the industry talking about them less. Harvested on 22 October 2026 against Google's India location on its own, drupal web development company and drupal website development company each ran at 390 a month, joomla web development company at 320 a month, php website development company at 320 a month, and angular web development company at 110 a month. In the United Kingdom, harvested the same day against the United Kingdom on its own, drupal development agency and php website development company each ran at 40 a month and umbraco web agency at 30 a month. Those are two separate markets measured separately.

PHP publishes its own support dates, and they sit underneath every quote here

Whatever the content management system on top, almost everything in this family runs on PHP, and php.net publishes the support position for each release branch. Read on 22 October 2026, that page states the policy plainly. "Each release branch of PHP is fully supported for two years from its initial stable release." After that period, "each branch is then supported for two additional years for critical security issues only." Its own glossary defines end of life as a release that "is no longer supported" where "users of this release should upgrade as soon as possible".

The dated table on the same page, as read that day, is the part to put in front of a supplier.

PHP branch	Initial release	Active support until	Security support until
8.2	8 December 2022	31 December 2024	31 December 2026
8.3	23 November 2023	31 December 2025	31 December 2027
8.4	21 November 2024	31 December 2026	31 December 2028
8.5	20 November 2025	31 December 2027	31 December 2029

Read that table against today's date and one thing jumps out. PHP 8.2 leaves even critical security support at the end of December 2026. Any proposal that quietly targets 8.2 is proposing a platform that stops receiving security fixes within months of launch. That is not a reason to reject the supplier. It is a reason to ask the question, and to get the version named in the scope rather than discovered on the server.

For the content management layer, each project publishes its own release and support schedule. Drupal publishes a core release cycle schedule on drupal.org, Joomla documents its release cycle on docs.joomla.org, and Umbraco publishes long term support and end of life dates on umbraco.com. An automated fetch of all three was attempted on 22 October 2026 and none returned readable content to it, so the dates are not reproduced here. Open them in a browser, write down the end of life date for the exact version you are being quoted, and put that date in the contract as a known fact rather than a surprise.

Why an older open source platform is often the right answer

There is a lazy assumption that choosing Drupal or Joomla in 2026 is a mistake. It is not, and the three cases where it is clearly correct are worth naming.

• You already have one. A working site with ten years of content, custom modules and trained editors is an asset. Replacing it to follow fashion spends a budget to arrive back where you started.
• The permissions model is the product. Drupal's handling of roles, workflow states and multi editor publishing is genuinely strong, and rebuilding that behaviour on a simpler platform is how a cheap replatform becomes expensive.
• Nobody can hold the licence over you. These platforms are open source, which means the code cannot be withdrawn and no vendor can reprice your access to your own site. For public bodies and anybody on a long procurement cycle, that is a real commercial property rather than an ideological one.

The case against is narrower and honest. The hiring pool for these platforms is smaller than it was, and the cost of finding a second supplier is part of the total cost of the decision. That is the next section, and it is the one most buyers skip.

Supplier replacement risk, which is the real reason to care about the stack

The thing that goes wrong with a specialist platform is not the platform. It is the day the agency that built it stops answering, and you discover how few other firms will take the work on. Price that risk at the start, while you still have a choice, using three concrete checks.

First, ask the firm to name two other companies that could maintain this build if they disappeared. A confident shop answers immediately and often names competitors it respects. A shop that cannot name one has told you that it is the only exit.

Second, ask how much of the site is standard platform behaviour and how much is bespoke code written by this firm. The bespoke portion is the part a replacement supplier has to learn. A build that is ninety per cent standard modules with light theming can be picked up in a week. A build with a large custom layer is a relationship rather than a website.

Third, ask for the documentation that a new developer would read on their first day, and read it yourself. You are not checking the technical content. You are checking whether it exists and whether it was updated this year.

Upgrade, migrate or rebuild, decided on three questions

Most enquiries about these platforms are not new builds. They are a site on an older version and a decision to make. Three questions settle it faster than a discovery workshop.

Does the content still describe the business you run now? If the answer is yes, you are looking at an upgrade, which keeps the content and the structure and moves the platform underneath it. If the content is half obsolete, the cheapest route is often a smaller new site rather than a careful migration of pages nobody should keep.

How many custom modules or extensions does the site depend on? Get the list with a one line purpose for each. Every item on it is a thing that has to work on the new version, and the ones written for you are the ones nobody else is maintaining.

Is the current site earning traffic you cannot afford to lose? If it is, the move has to be planned around preserving it rather than around the launch date, and our replatform sequence before, during and after a migration is the order to run it in.

What to ask a specialist shop that a generalist cannot answer

Six questions separate a firm that lives on these platforms from one that will learn on your budget.

• Which version are you proposing, and what is its published end of life date?
• How do you apply security releases, how quickly after they are published, and who decides?
• Which contributed modules or extensions will this site rely on, and when was each one last updated by its own maintainer?
• Show me a site you built on this platform that is still running and that you no longer maintain.
• What is in the staging environment, and can I see a change go from staging to live?
• If we wanted to move off this platform in four years, what would we be able to take with us?

That last question is the most revealing in the set. The honest answer is the content and the media, usually in a structured export, and rarely the templates or the custom behaviour. A firm that promises you could take everything has not done it.

Reading a quote for work on a site somebody else built

Maintenance and enhancement work on an inherited build is priced differently from a new project, and there is a specific line to look for. A good firm will quote a short, paid familiarisation period before committing to any estimate, often a few days, and will tell you what it expects to find. That is a sign of competence rather than reluctance. Any firm that gives a firm price for changes to a codebase it has never opened is guessing, and the guess will be resolved in its favour.

Separate three budgets in your own head so they do not merge in the invoice. Keeping it secure, which is unavoidable and should be a predictable monthly figure. Keeping it working, which covers breakages and small fixes. And making it better, which is the only one of the three that is optional.

Questions buyers ask about Drupal, Joomla and PHP suppliers

Is Drupal harder to find developers for than WordPress?

The pool is smaller, which affects both price and how long a replacement takes to find. Treat it as a cost of ownership line rather than a reason to avoid the platform, and ask any prospective supplier how many developers in its own team can work on your build.

Should we move a Joomla site to something else?

Only if you can name the problem the move solves. A Joomla site that is kept current, is on a supported PHP branch and is editable by your team is not a problem. A Joomla site three major versions behind with an unsupported PHP underneath it is a security decision rather than a preference.

What does plain PHP development mean on a proposal?

It usually means either a framework such as Laravel or Symfony, or a bespoke application with no content management system at all. Ask which, because the two have very different maintenance profiles. A framework has a published upgrade path. A bespoke codebase has whatever its author left behind.

How often should security updates be applied?

Agree it as a commitment with a clock on it rather than as good intentions. A reasonable position is that critical platform security releases are applied within a few days and routine ones within the monthly cycle, with a record of what was applied and when.

Is Angular comparable to these?

No, and conflating them causes bad briefs. Angular builds the interface in the browser while Drupal, Joomla and PHP frameworks run on the server. A project naming both is usually a system with a server side back end and a browser side front end, which means you need a firm comfortable on both sides, or two firms and a defined boundary between them.

What a browser side build hides from the machines reading your site

The platform choice on this page has one consequence that rarely reaches the proposal. A site whose pages are assembled on the server arrives complete to anything that fetches it, which includes the crawlers behind assistant answers. A site assembled in the browser can arrive almost empty to the same fetch, so a well built Angular front end can be invisible to the systems increasingly describing your business to buyers. That is a question for the technical conversation rather than the design one, and it belongs in the brief for any of these platforms. AI Knows Us reads what assistants actually say about a business and shows which pages each answer was built from, which is how you find out whether your platform decision is costing you a description you never saw.