The only fix left for unsupported ColdFusion is not running it.
Isolation and WAF rules reduce the blast radius of an unpatchable runtime. They do not patch it. We contain what can be contained in the first fortnight, then move the estate to TypeScript and Node until there is no ColdFusion left to answer for.
Not ready? Check your exposure firstSelf-assessment
How exposed are you?
Eight statements about the estate as it actually runs, not as the wiki describes it. Tick what is true. Nothing is sent anywhere. The first three carry most of the answer, and what you mark is what sets the order the work would run in.
Nothing marked yet. Tick what is true and the tally follows you to the form, or send your details and we will ask instead.
What it costs when it lands
The exposure, priced in consequences
Not severity scores. What actually happens, how likely it is, and what it takes out of the business on the day it does.
| Scenario | Likelihood | What it costs you |
|---|---|---|
| Unpatched runtime vulnerability exploited | Adobe shipped seven CVSS 10.0 flaws in one June 2026 bulletin | Data access, service loss, disclosure obligations |
| The one person who understands it becomes unavailable | Certain, eventually | No safe changes; every incident becomes an outage |
| Hardware or hypervisor failure on an unreproducible box | Low per year, rising with age | Rebuild time measured in weeks, not hours |
| A customer security questionnaire is answered truthfully | On the next renewal cycle | Contract risk, remediation commitments with deadlines |
| A regulation or integration forces a code change | Moderate | Change must be made by someone who cannot safely make it |
How estates get here
None of this was a bad decision at the time
The version you run stopped getting patches
Adobe closes support on a published schedule. ColdFusion 2021 is in extended support until 10 November 2026, which explicitly carries no security patches and no hotfixes, and the 2016 and 2018 releases are long past even that. Once the window shuts, published vulnerabilities against your runtime stay open permanently. There is no configuration that changes it.
One person is the disaster recovery plan
There is a name everyone says when the server misbehaves. That name is a single point of failure, and it is usually a contractor with no successor.
You cannot answer the auditor honestly
The questionnaire asks about supported software versions, patch cadence and recovery testing. You know what the truthful answer is, and it is not the one you want to write.
What the work is
Containment first, then off it entirely
Some estates come off ColdFusion in one lift and one cutover. Larger ones come off in a sequence, most exposed first. Which one applies is settled before you commit to either, and both end the same way, with the runtime switched off rather than mitigated for another year.
- The finding closes when the runtime goes. Every other control on the list is a compensating one with a shelf life. Network isolation, WAF rules and credential rotation shrink the blast radius of an unpatched runtime without patching it, and they have to be defended at every audit for as long as the box runs. Coming off ColdFusion is the only step that removes the finding instead of arguing with it.
- Containment starts before the migration does. Some risk can be closed in a fortnight: network isolation, patching whatever can still be patched, credential rotation, dead public endpoints removed, a restore that somebody has actually watched work. That happens while the port is being scoped, so you are measurably safer long before the estate has finished moving.
- Sequenced by blast radius, not by convenience. Where the estate moves in stages, the routes that are public, handle credentials or touch money go first, so your exposure falls early rather than evenly. A low-traffic internal screen can sit behind isolation for another year without costing you anything, and it usually should. Where the application is small enough to come across in one lift, none of this applies and the whole thing cuts over at once.
- Behaviour you can prove did not change. Characterisation tests are written against the legacy behaviour before anything is ported, so the new implementation is checked against the old one rather than against an assumption. That is also the artefact an auditor asks for when a system in scope has been rewritten mid-cycle, and the reason a migration does not have to reopen your compliance position.
- The key-person dependency goes with it. Reading the estate closely enough to port it is the same work as writing it down. Business rules come out as documented, tested code, and the parts that never move end up inventoried anyway. Even a migration you paused halfway leaves you with the system in writing.
- Read-only
- access is all we need to start
- Fortnight
- to the first containment items closed
- Zero
- ColdFusion still running at the end
The cost of holding
Waiting is also a budget line
What the current position costs while the decision is deferred. Most of it is already being spent, which is why it rarely appears in the business case for leaving.
| Cost line | Today | After the migration |
|---|---|---|
| CFML contractor day rate | Scarcity premium, rising each year | Mainstream market rate |
| Hiring and time to fill | Months per role, when it fills at all | An ordinary hiring pipeline |
| Servers sized for the runtime | Sized for per-instance licensing, not for load | Sized to actual traffic |
| Unplanned incident time | Key-person dependent, unbounded | Tested, documented, shared across the team |
| Compensating controls | Defended at every audit, for as long as the box runs | Retired with the finding |
| The exit itself | Not spent, and growing with the estate | One off, priced per route |
Licence renewal is not on this list. Adobe moved ColdFusion to subscription pricing and the annual figure per instance is now modest, so it is rarely what makes the case. If the licence line is genuinely your only problem, it is a small problem and you should not migrate to solve it.
Running order
What happens, and when
1 · Discovery, read-only
Read-only access to the code, the server config and the deployment process. We inventory runtime versions, exposed surfaces, integrations, scheduled jobs and the credentials sitting in the templates. Days, not weeks, and no write access at any point.
2 · Containment
We implement what can be closed now rather than after the migration: isolation, remaining patches, removing public endpoints nobody uses, and a restore tested in front of you. Each one is an entry you can update on the register this quarter.
3 · Challenge
We put the sequence and the costs in front of your technology and finance leads together, and invite them to attack the assumptions. A plan that only ever arrives at the expensive answer is a sales process with a document attached. The numbers that survive that meeting are the ones that get funded.
4 · The port, most exposed first
Routes move to TypeScript and Node in the order the register implies, each one behind characterisation tests and independently revertible. The schema is not part of the move: the new services read the database you already have. The estate keeps serving traffic throughout.
5 · Decommission
The ColdFusion server goes read-only, then off, then archived. That is the point of the exercise: the register entry closes with a date rather than another mitigation, and the questionnaire answer stops being the one you did not want to write.
Straight answers
What gets asked before people start
Is my version of Adobe ColdFusion still supported?
Adobe publishes a support lifecycle per release: core support, then a limited extended-support window, then nothing. ColdFusion 2021 sits in that extended window until 10 November 2026, and it is worth being precise about what extended support means, because the name misleads people. It carries no security patches and no hotfixes. It exists to give you time to migrate. The 2016 and 2018 releases are long past even that, and ColdFusion 2023 runs to 16 May 2028. The practical test needs no lifecycle table: if you cannot download a current security hotfix for your exact build, vulnerabilities published against it will never be fixed. Discovery confirms which build you actually run, which is often not the one in the documentation.
What is the actual risk of running unsupported ColdFusion?
Specifically rather than generally: Adobe bulletin APSB26-68, on 30 June 2026, carried seven flaws rated CVSS 10.0. One of them, CVE-2026-48282, is a path traversal leading to unauthenticated remote code execution, and it was being exploited in the wild under two hours after public disclosure. That is the number that matters, because it is shorter than most change windows. An earlier one, CVE-2024-20767, was patched in March 2024 and was still being exploited that December, which tells you how long unpatched CF servers stay findable. If you are on a supported build you install the hotfix and the exposure closes. If you are not, the bulletin is simply a public description of a way into your estate that will never be fixed. Beyond that there is availability risk with no vendor to escalate to, compliance risk where a framework or a cyber insurance policy requires supported software, and key-person risk.
Is migrating really a security control, or is that just how you sell a rewrite?
It is a fair question and the honest answer has a condition attached. Migration is the control that closes an unpatchable-runtime finding, because the finding is about the runtime and nothing except removing it makes the finding go away. But it is a slow, expensive control, so it is the wrong answer when a cheap one exists. If you are still inside the support window, or the application has no public surface, sits behind isolation and has a tested restore, then patching and containment are the correct answer and we will tell you so. What we will not do is agree that isolation is a permanent substitute for a supported runtime, because it is not one and your auditor knows it.
Can we just keep patching instead of migrating?
If you are still inside the support window, yes, and you should. Patch promptly and get the containment basics right. That buys you time to migrate deliberately rather than in a panic. What does not work is treating patching as the permanent strategy, because the support window closes on Adobe schedule regardless of your roadmap. Patch to buy time, then use the time to leave.
How do we show an auditor that the migration did not change what the system does?
With the tests, and with the sequence. Before a route is ported we write characterisation tests against the behaviour the legacy application actually has, including the bugs, so there is a recorded definition of correct that predates the rewrite. The new implementation is then checked against that, per route, and a route can be reverted independently if it does not match. What you can hand over is a per-route record of what was pinned, what passed and when traffic moved. That is a considerably better position than most in-scope systems can evidence, and it is why a migration mid-cycle does not have to reopen your compliance position.
We are not allowed to give an external supplier code access. Can you still help?
Yes. Discovery can run entirely on your premises or in your VDI with read-only credentials, under your NDA and your logging. We do not need write access, production credentials or customer data at any point during discovery, and a lot of what matters is in server configuration and network exposure rather than the application code. The porting work can run the same way where policy requires it.
How is this different from a penetration test?
A pen test tells you which doors are currently unlocked. It cannot tell you that the building will keep producing unlocked doors for as long as the runtime is unsupported, and it will not remove any of them. There is overlap on the findings, and the two complement each other. The difference is that a pen test ends with a report and this ends with the system it was reporting on switched off.
Does the exit have to be done in stages?
No, and it should not be if your estate does not need it. Sequencing exists to spread risk and cost across a large surface, and on a large estate it is the right answer. Under a certain size, with few outside systems hanging off it, the honest answer is the opposite: the application comes across in one lift and one cutover, which is cheaper and finishes sooner than running two stacks side by side and paying for the bridge between them. Which of the two applies to you is among the first things discovery settles, and we say so even when the answer is the smaller piece of work.
How long before we are actually less exposed?
Sooner than the migration finishes, which is the point of doing it in this order. Containment lands in the first fortnight and closes real findings on its own: isolation, the last patches available to you, dead public endpoints removed, a restore somebody has watched work. After that the exposure falls each time a route moves rather than all at once at the end, because the most exposed things move first. Getting to no ColdFusion at all is a longer horizon and it depends on the size of the estate, which discovery is what settles. What we will not do is quote you a duration before anyone has read the code, because the number that comes back from that question is always the one the buyer wanted to hear.
Do we have to migrate everything?
Almost never. Most estates have a small number of applications carrying most of the risk and most of the business value, and a long tail that is low-traffic, internal and nearly dormant. The sequence follows the risk, and it is entirely reasonable for the tail to sit behind network isolation for years while the important systems move first.
We have an active incident. Can you start now?
Say so in the form and it goes to the top of the queue rather than into the normal reply cycle. Containment work can begin as soon as there is read-only access and someone who knows the estate, which in practice means days. The migration is a separate conversation and it should not be started in the middle of an incident, but the isolation, credential and endpoint work that comes first is exactly what an incident calls for anyway.
Intake
Start the exit
Two fields to start. You get a reply within one working day, written by whoever would be opening your codebase rather than by a salesperson. If you are mid-incident, say so and it jumps the queue.
- Read-only access to begin
- Containment inside the first fortnight
- Under your NDA and your logging