Skip to main content
← Back to Blog

ColdFusion in 2026: What Still Runs on It and Why That's Not the Scandal People Think

July 15, 2026

ColdFusionLegacy ModernizationEnterprise Software

Tell a room of developers that ColdFusion is still in production in 2026 and you get the laugh. Tell them what it is running and the laugh gets quieter: insurance plan management, continuing education platforms with regulatory reporting obligations, municipal finance systems, member services for organizations with decades of records. Systems where the cost of being wrong is measured in audits and lawsuits, not lost signups.

We have built and maintained ColdFusion systems since 1998, and we now spend much of our time doing remediation and modernization work on CFML estates. That vantage point supports a claim most commentary gets backwards: the scandal is not that these systems still exist. The scandal is how many of them are unmanaged.

Why the systems are still here

The systems that survive on ColdFusion survive for a reason. They encode years of business rules that exist nowhere else: rate calculations, eligibility logic, state-by-state compliance quirks, the accumulated fixes from every edge case a real customer ever hit. The application is often the only complete record of how the business actually works.

That is not technical debt in the dismissive sense. That is an asset with a maintenance problem. Replacing it means re-discovering every one of those rules, and organizations that treat the rewrite as a greenfield project discover them one production incident at a time.

Adobe, for its part, has not abandoned the platform. ColdFusion 2025 shipped with a current JVM underneath it, and the upgrade path from older versions is real, if not effortless. There is also a live open-source CFML ecosystem around Lucee and, more recently, BoxLang. "Dead language" is commentary shorthand, not an engineering fact.

The actual risk profile

Here is what we find when we assess a ColdFusion estate, and none of it is the language:

End-of-life runtimes facing the internet. ColdFusion 10 and 11 installations, years past their last security patch, serving public traffic. This is the single most common serious finding, and it has nothing to do with CFML syntax. An unpatched runtime is an unpatched runtime.

No source control. More common than anyone admits. Production file edits as the deployment process, which means fixes regress, there is no audit trail, and the disaster recovery plan is a prayer. When we find this, it goes to the top of the list, ahead of any platform conversation.

Knowledge concentrated in one person, or zero. The developer who understood the system retired, and the organization has been making only the changes it can make safely, which is fewer every year. The application still works. The organization's ability to change it is what died.

Databases and reporting stacks aging in place alongside the app. The application upgrade conversation always arrives dragging a SQL Server version, a reporting layer, and an authentication story behind it. Estates age as a unit.

Notice the shape of that list. Every item on it is a management decision, not a technology verdict. A patched, version-controlled, documented ColdFusion 2025 application on supported infrastructure is a perfectly defensible place for a stable line-of-business system to live. An unpatched CF10 box with FTP deployment is indefensible, and rewriting it in a fashionable stack while keeping the same practices would produce a fashionable unpatched box.

What stewardship looks like

The organizations that do this well treat the estate like the asset it is. They know what they are running and what it touches. They keep runtimes on supported versions, which after the CF2025 release means there is a current target to land on. They put source control and a deployment path in place before considering anything bigger. And they modernize deliberately, when the change velocity of the business demands it, not out of embarrassment about the logo on the runtime.

Embarrassment is a terrible input to architecture decisions. Risk exposure, change frequency, and business criticality are good ones. We wrote up the decision framework we use to sort applications into remediate, modernize, or leave alone.

If some of your estate runs on CFML and you are not confident which bucket it belongs in, that assessment is the work we do most: ColdFusion services, migration, and security remediation.

Have a problem worth solving?

Tell us what you are trying to build or modernize, and we will tell you honestly how we would approach it.