Most ColdFusion migration advice starts with the wrong question. It asks "what do we rewrite it in?" before anyone has asked "what is this application actually worth, and to whom?" That ordering is how migrations run two years long and quietly get cancelled.
We have been building and maintaining ColdFusion systems since 1998, and we are an Adobe Solution Partner, which keeps us close to Adobe's ColdFusion roadmap and gives our clients an escalation path into Adobe when one is needed. So we start from a position most modernization shops do not: a ColdFusion application that has run reliably for fifteen years is not a liability to be escaped. It is working software with embedded business logic that nobody fully remembers writing. The risk is not the language. The risk is throwing away that logic in a rewrite that recreates the bugs you already fixed.
The first decision is not technical
Before we look at a single .cfm file, we sort the application into three buckets:
- Keep and stabilize. Code that works, rarely changes, and carries low security exposure. Migrating it is motion without progress. We patch the runtime, lock down the surface, and leave it alone.
- Rewrite with intent. The parts under active change, or the parts blocking a business capability you actually need. This is where a migration earns its budget.
- Retire. Features that exist because someone asked for them in 2011 and nobody has used since. Every migration is also an audit. The cheapest code to migrate is the code you delete.
Most ColdFusion estates are 70% bucket one, 20% bucket two, 10% bucket three. The teams that struggle are the ones who treated all of it as bucket two.
The split is not academic. When we upgraded Osceola County's ColdFusion infrastructure, most applications moved to the new servers with compatibility work only, and a smaller set were rebuilt where the old code would not survive the new environment. Treating those as two different problems is why the migration finished with zero downtime, extended the application lifecycle by more than a decade, and cut operating costs by 40%.
Where AI helps, and where it does not
This is the part the market gets wrong in both directions. AI does not "translate ColdFusion to a modern stack" by pointing a model at a repo and accepting the output. We have watched that approach produce code that compiles, passes a smoke test, and silently drops an edge case that mattered to finance.
Where AI actually accelerates the work: mapping the codebase, surfacing dead code and duplicated queries, drafting test scaffolding around legacy behavior so a rewrite has a safety net, and proposing translations a senior engineer then reviews line by line. AI that ships, not AI that demos. The judgment about whether a translation preserves intent stays with a person who has migrated these systems before.
What "done" looks like
A migration is finished when the new system carries the business logic the old one encoded, the team trusts it in production, and the parts you kept are documented well enough that the next person does not have to rediscover them. Not when the last .cfm file is gone.
If you are weighing a ColdFusion migration, the most useful first step is the triage, not the rewrite. We do that as a focused engagement: read the estate, sort it, and tell you plainly what is worth moving. See our approach to ColdFusion migration and our broader ColdFusion work.