Symfony 6.4, Drupal 10 and PHP 8.2 in a deal that closes in 2027

Between 30 November and 31 December 2026, three parts of a large share of PHP software lose support. Symfony 6.4 stops getting bug fixes, Drupal 10 reaches its end of life, and PHP 8.2 stops getting security fixes. Each of them is a version number, and each would usually sit in the appendix of a technical review. For a company that is being sold or bought around the turn of the year, the timing moves them closer to the price.

This note is for the people on both sides of such a deal: the owner preparing a sale, the buyer reading a target, and the advisors between them. How to upgrade each part is an engineering question, and our engineering partner covers it step by step in Symfony 6.4, Drupal 10 and PHP 8.2: three support deadlines before 2027. Here we look at what the dates do to a deal.

The three dates

The dates come from the official schedules of Symfony, Drupal and PHP. We keep them, with other dates that matter to owners, on one page: technology deadlines for owners.

Why the timing matters in a deal

A software deal is rarely signed and closed on the same day. Between the letter of intent, the review, the signing and the closing there are usually weeks, often months. A component that is supported when the buyer's review starts in November can be unsupported by the time the deal closes in February. The review then has to describe two states: the company as it is when it is read, and the company the buyer will actually own.

The second point is about the buyer's first months. An upgrade that nobody has started becomes work the buyer must fund and staff right after closing, at the moment the team is also learning a new owner. That is why a reviewer does not treat an end-of-support date as trivia. It is a dated piece of work with a cost, and it lands in the first hundred days unless someone moves it earlier. How findings turn into that plan is in From due diligence to the 100-day plan.

None of this means the product is broken. It works on the day after the deadline as it worked the day before. What changes is that any weakness found later in that version stays without an official fix, and the cost of moving forward grows with every month the gap to current versions widens.

What a buyer's reviewer looks at

On these three parts, a reviewer usually wants answers to a short list of questions, and most of them can be answered from the code and the servers in a day:

• Exact versions in production: the framework and CMS version in the dependency lock file, the PHP version on every server, not only on the developer's laptop, and the hosting provider's plans for older PHP versions.
• Patch level, not only the major version: a product on the last release of its line is in a very different position from one that stopped taking updates two years ago. The second has a longer list of known issues behind it.
• Third-party modules and packages: which of them already have versions for Symfony 7 or Drupal 11, and which are abandoned. Abandoned parts are where upgrades slow down and where costs hide.
• Custom code: how much of the business logic lives in the company's own modules and bundles. In Drupal especially, the size of the upgrade follows the size of the custom code.
• The plan: whether an upgrade is scoped, priced, scheduled or under way, and who will do it. A plan with a date and an estimate reads very differently from "we will look at it next year".
• The people: whether the developers who know the custom code are still there and will stay through the work. That question is covered in Key person risk in technical due diligence.

How it turns into deal terms

An unsupported or soon unsupported core is a finding with a cost to fix. In our experience that cost reaches the deal in one of a few familiar ways, and the choice between them is for the parties and their lawyers, not for the reviewer:

• it is priced in, and the cost of the upgrade comes off the value;
• part of the payment is held back until the upgrade is done;
• the seller agrees to finish the upgrade before closing, as a condition of the deal;
• it is disclosed, with the plan and the estimate, and the buyer accepts it as known.

The reviewer's job is to make each of these choices possible: to say what is out of support and when, what the upgrade involves, how long it takes and roughly what it costs, and what the risk is in the meantime. A wider look at old platforms in a target is in An aging platform inside an acquisition target.

What a seller can do in the time left

For an owner who plans to sell in 2027, the useful window is now. A finding the seller has already fixed, or at least planned with a date and a price, weakens the seller's position far less than one the buyer finds on its own. In practice that comes down to five steps:

1. Write down the versions. Framework, CMS, PHP, database and the main packages, for every system the business relies on. Your team or hosting can answer in an afternoon.
2. Get an estimate. A short audit by the team that will do the work, or by an outside one, turns "we are on an old version" into a scope, a time frame and a range of cost.
3. Do the upgrade if it fits before the data room opens. For many products the move from Symfony 6.4 to 7.4 or from Drupal 10 to 11 is weeks, not months, when the custom code is moderate.
4. If it does not fit, document it. The plan, the date, the budget and who is doing it, ready for the data room. Our note on the technical section of a data room shows where it goes.
5. Keep applying every available update on the current version until the switch, so that the gap a buyer reads is as small as it can be.

This is the kind of work a technical baseline before the banker covers, and what our exit readiness program runs month by month. When the seller wants an independent report to share with buyers, that is vendor due diligence.

What a buyer can do

A buyer looking at a target in the next few months can treat the three dates as a fixed item in the review scope. Ask for the versions early, before the full review, so that the cost of an upgrade is in the model before the price is. Ask whether the seller has a plan and an estimate, and test the estimate against the size of the custom code. Decide early which of the deal mechanisms above fits, because a condition before closing changes the timeline of the deal itself. And put the upgrade, with an owner and a budget, into the first hundred days if it is not finished before closing.

For a buyer, the date itself is rarely the problem. The problem is learning about it late, after the price has been agreed. A red-flag memo early in the process, or a full technical due diligence, puts it on the table while it can still be priced.

A short checklist

• Which systems run on Symfony 6.4, Drupal 10 or PHP 8.2, and on which servers.
• The patch level of each, and the date of the last update.
• Third-party modules and packages without versions for the next major release.
• The size of the custom code that has to move.
• A plan with a date, a budget and named people, or the decision not to upgrade and why.
• What the hosting provider will do with older PHP versions, and when.
• How each item will be shown in the data room and in the disclosure.

Questions