An aging platform inside an acquisition target

Many good businesses run on software that is getting old. An online store on a commerce platform version whose support has ended. A SaaS product on a framework two major versions behind, on a language runtime that no longer gets security fixes. The business still sells, the customers still log in, and the seller's numbers look fine. The platform question tends to surface during diligence, often in the second or third week, when someone reads the version numbers against the vendor's published support dates.

At that point a buyer needs more than "the stack is dated". It needs to know what has stopped, what it exposes, what the ways out are, what each would cost on stated assumptions, and what could go wrong to revenue while the work is done.

This is how an independent reviewer reads an aging platform inside an acquisition target, and how the result tends to reach the deal.

What "end of support" means in a review

"End of life" is used loosely, and the loose version causes bad negotiations. A platform as a product is rarely gone. What ends is support for a specific version line. Our engineering partner PERETZ covers the operator's side of this decision, for a store owner choosing a route, in Leaving Magento in 2026: Upgrade, Shopify Plus or Custom Laravel?. The reviewer's job is narrower: establish, on evidence, where the target stands today for every piece of software it depends on.

Most vendors and open-source projects publish a lifecycle with at least two dates per version. Standard or active support ends first: bug fixes and compatibility work stop. Security support ends later: after that date, newly found vulnerabilities in that version are no longer patched by the maintainers. Some vendors and third parties sell extended support beyond that, at a price and for a limited period. A finding has to say which of these stages applies, because the risk is very different on each side of the security date.

The stack is several products, not one

An e-commerce site or web application usually rests on a chain: the commerce platform or application framework, the language runtime (for example a PHP, Node.js, Python or Java version), the database server, the operating system or container base image, the search engine, and front-end build tooling. Each has its own lifecycle. The chain matters because the links constrain each other. An old platform version often cannot run on a supported runtime, so the runtime stays old too, and the operating system under it stays old to keep that runtime installable. One stalled upgrade can hold four layers back.

The reviewer records each component's version from manifests, server images and configuration, not from the seller's summary, and sets it against the published dates. That work sits in two of our six layers: Code & architecture, and Infrastructure & cost.

Patches, extensions and customizations

Version age is the headline. What decides the size of the problem is usually underneath it.

Security patch status

A version still inside its security window is only as safe as the patches actually applied. The reviewer checks the last security release installed against the latest one published for that line, how patches are applied (a tested process with a staging environment, or by hand on the live server), and whether any patch was skipped because it broke something. A store that is in support on paper but six patches behind is, in practice, unpatched. Where card payments are involved, the question extends to payment scope: card industry security standards expect timely patching of the systems in scope, and a checkout that handles card data directly widens that scope compared with hosted payment fields or a redirect to the payment provider.

Extensions and their vendors

Commerce platforms in particular accumulate third-party extensions: payments, shipping, tax, search, promotions, feeds to marketplaces. For an upgrade or a move, each one is a question. Does a version exist for the target platform version? Is the vendor still active? Is the license tied to a domain, an account or a named company, and does it transfer to a new owner? Is it paid yearly, and who holds that account? An abandoned extension sitting in the checkout path is often the single item that turns an upgrade into a rebuild of that function.

Customizations and core changes

The most expensive pattern is a modified core: platform files edited in place instead of extended through the platform's supported mechanisms. Every patch and upgrade then has to be merged by hand against those edits, which is often why patches stopped being applied. The reviewer compares the installed core against a clean copy of the same version where possible, counts the overrides, and reads samples of the custom modules that carry business rules such as pricing, delivery, tax and customer-specific terms. Those rules are what any route forward has to carry across, and they are rarely documented.

Hosting and the runtime underneath

Hosting decides how much of the patching burden sits with the target and how hard any change will be. A fully hosted platform carries most of it for the merchant. A self-hosted platform on a virtual server carries all of it: operating system updates, runtime versions, database upgrades, certificates, backups. Managed hosting splits it, and the contract says where the line is.

The reviewer looks at who controls the hosting account and the domain, whether servers are built from code or configured by hand over the years, whether a second environment matches production closely enough to test an upgrade, and whether backups have ever been restored. A host that has itself announced the end of a runtime version or server plan creates a date the buyer does not control. Account control often matters more than age; see ownership gaps that stop a software deal.

The paths forward and what they cost

Each route fixes some things and puts others at risk, and the right one depends on the buyer's plan for the business. We describe options; we do not recommend a vendor or a platform.

Cost ranges and their assumptions

Ranges come from counting what the work touches, not from the size of the company. As rough rules of thumb, and only with the assumptions stated: bringing a version up to its latest security release is usually days to a few engineer weeks if the core is unmodified and a test environment exists, and much more if core edits must be merged by hand. An upgrade across several versions of the same platform is often a few months of work for a small team, driven mainly by the number of extensions with no compatible release and the number of overrides. A move to another platform or a rebuild is usually measured in quarters, and its range is the widest, because undocumented business rules and data cleanup are where estimates go wrong.

Two comparisons distort most decisions. One sets a one-time build quote against a monthly subscription; the honest comparison is total cost of ownership over several years, including apps, fees, hosting, support and the framework upgrades that a custom build will still need. The other assumes a rebuild ends the problem; every framework and runtime has its own lifecycle, so the new system starts a new clock. How a reviewer turns counts into engineer weeks and calendar time, and why a full rewrite is rarely the answer, is set out in how technical debt is measured and put into a deal. Platform fees that scale with revenue also belong in the margin discussion covered in the technology behind the SaaS numbers.

Risk during a migration

For an online business, the platform is the till. Whatever route is chosen, the period of change is when revenue is most exposed, and a buyer is often planning that period for its first year of ownership.

Revenue and checkout

Prices, taxes, discounts, delivery fees and customer-specific terms must calculate the same way on the new system, and a mistake in any of them costs money on every order until someone notices. Customer accounts may not move cleanly: password hashes from one platform often cannot be used by another, which means forced resets and some loss of returning customers. Order history, subscriptions, stored payment tokens and gift card balances each need their own plan, and payment tokens usually depend on the payment provider's cooperation.

Search traffic

Where organic search brings a large share of visits, a change of URLs is a revenue risk. Every old address needs a permanent redirect to its closest new page, and content, structured data and internal links have to move with it. Some hosted platforms impose fixed URL patterns, so the reviewer checks which old addresses can be kept and which can only be redirected.

Integrations and operations

Connections to the ERP, warehouse, accounting, marketplaces, email and reviews were built against the old platform's interfaces and will need to be rebuilt or re-pointed. Cutover is usually planned away from peak trading, with a parallel run on real orders and a written rollback plan. A migration timetable that crosses the buyer's busiest season deserves a hard look.

A migration already in flight

The hardest state to read is a migration half done at the time of the deal: two systems, partly moved data, an agency contract mid-term, and a seller who presents the new platform as nearly finished. The reviewer measures progress on evidence (what runs in production, what data has moved, which integrations are live), reads the contract and remaining budget, and asks what happens to the work between signing and closing.

How it reaches the deal

An aging platform is rated on our severity scale against the buyer's plan, and the report says which plan. As typical patterns, not rules: a version still receiving security fixes, with a funded upgrade plan, is often Medium. A version past its security date with an internet-facing checkout is usually High, because fixes have stopped and the way out takes months. Evidence of an unpatched vulnerability that is being exploited in the wild, or signs of compromise, can be Critical and is normally expected to be addressed before closing. Every finding carries evidence, business impact and a cost range with assumptions, as described in the report.

We do not negotiate, and we give no legal, tax, valuation or investment advice. These are the points a deal team usually takes to counsel:

• Price. Whether an upgrade or move that is needed whatever the buyer's plan is reflected in the price, and on which range.
• Plan. Whether the work sits in the first 100 days or the first year, with a budget, an owner and a timetable that avoids peak trading. See the diligence report as the first draft of a 100-day plan.
• Condition. Whether specific steps happen before closing, such as applying outstanding security patches, moving card handling out of scope or transferring extension licenses and hosting accounts.
• Conduct between signing and closing. Whether the seller may start, change or stop a migration in that period, and who decides.
• Protection. Whether escrow, a specific indemnity or disclosure schedules address a known exposure, and whether insurance underwriters ask about it, since their cybersecurity questions often reach unsupported software.
• Double counting. Whether the same upgrade cost appears in price, escrow and the plan budget at once.

For a seller, an old platform with a priced plan and current patches reads as a cost the buyer can model. Found by the buyer with no plan, it reads as an open question, and those tend to be priced at their worst case.

A checklist for an aging platform

• Every component listed with its version: platform or framework, runtime, database, operating system or base image, search, front-end tooling.
• Published support dates for each, with the stage it is in: standard support, security only, extended support, none.
• Last security release applied against the latest available, and how patches are applied and tested.
• Core modifications counted against a clean copy of the same version.
• Extension inventory: vendor, active or abandoned, compatible version available, license terms and transfer, account holder.
• Business rules for price, tax, delivery and customer terms written down, with where each lives in the code.
• Hosting: account owner, who patches what, environments that match production, a restored backup.
• Payment flow and its card data scope.
• Integrations and the interface each depends on.
• Share of traffic and revenue from organic search, and the current URL structure.
• Any migration in flight: evidence of progress, contract, remaining budget, decision rights until closing.
• Cost ranges per route, each with its assumptions, team and what drives the high end.

What to do next

If you are buying a business on an aging platform, share your plan for it with the reviewer before the work starts, since a buyer who plans to replatform anyway reads the same finding differently from one who plans to keep the store steady. Our technical due diligence reads the platform and the stack under it on evidence, prices the routes with assumptions and sets out the points for counsel, at a fixed fee agreed in writing before we start. When time is short, a red-flag memo tells you whether the platform is a price question or a plan question.

If you are selling, the platform is one of the few technical facts you can still change or at least plan. With months ahead, exit readiness builds the inventory, brings patches current and prices the route. Closer to a sale, vendor due diligence puts an independent reading in front of buyers. Neither path is short, and neither makes an old platform new; both turn it into a cost with a plan instead of a surprise.

Questions