Choose the right CFML runtime before you spend money on a rewrite.
Adobe ColdFusion to Lucee assessment and migration. The honest version of this offer is that the recommendation might be to stay on Adobe ColdFusion, move to Lucee, evaluate BoxLang, or do none of those yet and stabilize what you have first. You get the recommendation in writing either way.
The question usually arrives attached to a deadline.
Almost nobody wakes up wanting to change CFML engines. It comes up because something else forced it.
- Licensing is under review. A renewal is coming, the number went up, or finance is asking what the line item buys.
- The engine is aging out. ColdFusion 2021 left core support on 10 November 2025 and leaves extended support on 10 November 2026. Extended support does not include security patches. "Upgrade" has quietly become "decide." Adobe's lifecycle dates.
- A cloud migration is on the roadmap. Moving to AWS is the moment people reconsider the runtime, because you are rebuilding the deployment anyway.
- The ColdFusion knowledge is walking out. One or two people understand the application, and their retirement date is closer than your modernization date.
- Someone has proposed a rewrite. The number is large, the timeline is long, and you want to know whether there is a smaller answer that addresses the actual risk.
If any of those describe you, the useful first move is a decision, not a migration. The two are frequently confused, and the confusion is expensive.
Three engines, compared on what actually decides it.
There is no universal winner here, and any consultant who tells you otherwise is selling the migration rather than the decision. The right answer depends on which of these rows your organization is actually constrained by.
| Factor | Adobe ColdFusion | Lucee | BoxLang |
|---|---|---|---|
| Support model | Commercial vendor support with a published product lifecycle and a company contractually on the other end. | Open-source project with community support; commercial support available from third parties rather than from a single platform vendor. | Newer JVM-based CFML runtime with vendor-backed commercial support available from its maintainers. |
| Licensing approach | Commercial per-server or per-core licensing, renewed on Adobe's terms and lifecycle. | Open source, no per-server licence fee. Cost moves from licensing into the operations you now own. | Open source core with commercial options; a newer entrant, so factor in less accumulated production history. |
| Engine-specific dependencies | The reference implementation. Adobe-only tags, functions, and administrator features are available by definition. | Independent implementation. Most ordinary CFML carries over; Adobe-specific features are the migration surface to inventory. | Independent implementation with its own compatibility posture. Expect a larger validation effort on a mature legacy codebase. |
| Deployment & cloud fit | Runs well on AWS; licensing model needs deliberate thought in autoscaling or containerized topologies. | No per-instance licence cost makes horizontal scaling and containerization straightforward to reason about. | Designed with modern JVM deployment in mind; the same containerization advantages apply. |
| Operational responsibility | Patch cadence follows Adobe's bulletins; escalation path is contractual. | You own patching, upgrade timing, and triage — either in-house or through a retained specialist. | Similar ownership profile, with a smaller pool of operators who have run it at scale. |
| Team risk | The largest pool of engineers with direct experience, though that pool is shrinking industry-wide. | Smaller but active community; CFML skills transfer, engine-specific operational knowledge does not automatically. | Smallest talent pool today. Reasonable for a team investing deliberately; risky as a continuity plan. |
| Codebase compatibility | No migration, therefore no compatibility work. This is a genuine advantage and it is routinely undervalued. | Compatibility is good for ordinary application code and imperfect at the edges. The edges are what the assessment measures. | Requires the most validation of the three for a long-lived Adobe ColdFusion codebase. |
This table describes categories of difference, not a scorecard. It deliberately carries no licence prices or version-specific claims: those change, and a page that quotes them goes stale and starts misleading people. Current licensing and lifecycle terms come from the vendors themselves, and the assessment prices your actual situation.
Find out what breaks before production does.
If the assessment supports a migration, this is the shape of it. Nothing here is exotic; the discipline is in not skipping steps when the deadline gets close.
Inventory
Every template, component, scheduled task, datasource, mail configuration, custom tag, Java integration, and third-party extension the application actually loads — as opposed to what the documentation says it loads.
Compatibility matrix
Each engine-dependent item classified: carries over unchanged, needs modification, needs replacement, or has no equivalent. This document is what turns "should we migrate" into a number.
Runtime, configuration, extension review
JVM settings, servlet container, connection pooling, caching, session and clustering behaviour, and the administrator configuration that never made it into source control.
Test and regression plan
Coverage over the paths that carry money, data, or compliance weight. Legacy CFML rarely arrives with a test suite; building enough of one is part of the work, not a prerequisite for it.
Parallel environment
The target engine stood up beside the current production system, running the same code against the same data shape, so differences surface where they cost nothing.
Integration and performance validation
Every external integration exercised, and performance compared against a measured baseline from the current system — not against a target somebody imagined.
Controlled cutover and rollback
Designed for phased cutover with a soak period and a tested rollback path. Rollback is rehearsed before cutover, because a rollback plan nobody has executed is a hope.
Written runbook and handoff
Deployment procedure, configuration inventory, known differences, monitoring, and the rollback procedure — written for the person who inherits it, not for me.
When staying on Adobe ColdFusion is the right call.
This section exists because it is the part most vendors leave out. A migration is a project with a cost, a risk profile, and an opportunity cost, and there are situations where it is straightforwardly the wrong purchase.
- You need a vendor support agreement. If an outage has to end with a call to a company that is contractually obligated to answer, that requirement outranks the licence saving.
- Procurement or compliance names the vendor. Public-sector and regulated buyers often need a named vendor with a published support lifecycle. Community support can be excellent and still fail that test on paper.
- The application materially depends on Adobe-specific features. If the compatibility matrix comes back heavy, the migration is a rewrite wearing a smaller word.
- You cannot fund enough testing. Migrating a system you cannot afford to validate is how a licence saving turns into an outage. If the testing budget isn't there, the answer is to upgrade in place and revisit later.
In those cases the useful engagement is a supported-version upgrade and hardening pass, not an engine change. You'll get that recommendation in writing, with the reasoning, and you are free to take it to anyone.
What you actually receive.
A CFML Engine Fit Assessment is a fixed-scope, written engagement. It is designed to be forwarded internally and to survive being read by someone who was not on the calls.
- A written engine recommendation — Adobe ColdFusion, Lucee, BoxLang, or stabilize first — with the reasoning that produced it.
- A compatibility and risk register naming each engine-dependent item, its classification, and the risk attached to it.
- A migration approach covering sequencing, environments, testing strategy, and cutover shape.
- A proof-of-concept recommendation where the analysis is genuinely uncertain and a small experiment would resolve it more cheaply than more analysis.
- A rough delivery roadmap with phases and effort estimates you can take into a budget cycle.
- Assumptions and explicit exclusions — what I assumed, what I did not examine, and what would change the recommendation.
The four I get asked every time.
Can you migrate Adobe ColdFusion to Lucee?
Yes, where the assessment supports it. Both are CFML engines, so a large portion of ordinary application code tends to move with little or no change. The work concentrates in the places where an application depends on the engine rather than the language: Adobe-specific tags and functions, administrator and datasource configuration, scheduled tasks, caching, PDF and document features, mail, and any Java or third-party extension the application loads.
How big that surface is varies enormously between codebases, which is why the assessment comes first. Two applications of identical size can differ by an order of magnitude in migration effort.
Will all my CFML code run unchanged?
No, and I would be careful with anyone who says otherwise. Lucee is an independent implementation of CFML, not a drop-in clone of Adobe ColdFusion. Expect differences in engine-specific tags and functions, some behavioural edge cases, a different administrator and configuration structure, and features that exist only on the Adobe side.
"Most of it will probably work" is true and useless for planning. The compatibility matrix replaces it with a list of specific items and a defensible effort estimate for your codebase.
When should we stay on Adobe ColdFusion?
When you need a commercial vendor support agreement; when procurement or compliance requires a named vendor with a published support lifecycle; when the application materially depends on Adobe-specific features; or when you cannot fund enough compatibility and regression testing to migrate safely.
Upgrading in place on a supported Adobe release is a perfectly good outcome, and it is the recommendation in a meaningful share of these assessments. The licence line item is rarely the largest number in the decision.
How do you control migration risk?
By ordering the work so that surprises are cheap. Inventory and compatibility analysis before commitment; regression coverage over the paths that carry money, data, or compliance weight; a parallel environment where differences surface without consequences; integration and performance validation against a measured baseline; then a controlled cutover with a soak period and a rollback path that has been rehearsed rather than merely written down.
During my time as a CTO I ran migrations of this shape at production scale without downtime — an AWS platform migration of a production CRM, and a 100M+ file migration off Microsoft DFS. That is history from prior work, not a guarantee about your system or a claim of completed engine migrations. What carries over is the method: designed for phased cutover and rollback, so that if something does surface, the answer is a decision rather than an incident.
Where to read further.
Primary source — the Lucee project itself. For engine capabilities, releases, configuration, and support options, go to the project rather than to anyone's summary of it:
- lucee.org — the official project site, downloads, and community.
- docs.lucee.org — official documentation and reference.
Third-party further reading. TeraTech, a ColdFusion consultancy, publishes an overview of Lucee that covers both the cost and cloud appeal and the operational trade-offs of community-led support. It is a competitor's marketing content and worth reading as such — useful framing, and I'd verify any figure in it against the vendors before acting on it:
- TeraTech: everything you need to know about Lucee (third-party source)
For Adobe ColdFusion licensing terms and support lifecycle dates, use Adobe's own published lifecycle documentation. Those terms change, and a consultant's page quoting them from memory is exactly the wrong input to a licensing decision.
Book the free 30-minute assessment.
We'll go through your engine, version, integration surface, and what's forcing the timeline. If the honest answer is that you should stay where you are, that's what I'll tell you on the call — before either of us has spent anything.
Book the free technical assessmentPrefer to write it down first? Send the details or email sales@coldfusioncafe.com — I reply within one business day.