Move off ColdFusion
without freezing your roadmap
We port CFML applications to TypeScript and Node.js one route at a time. Your current app keeps serving traffic and keeps shipping features while the migration runs underneath it.
Traffic keeps arriving, and every request still lands on a page that works. That is the part you cannot switch off.
Under every page, one .cfm file: markup, queries, mail and the business rules, all in the same template.
Includes include includes. Two tiers down the map runs out, and a query fires from somewhere inside it.
Every one of those queries lands on the same schema. It is the one thing here that does not have to change.
One cell. 0.12. Nobody remembers writing it, and half your accounts are rated by it.
One business rule, recovered from every layer it touches, before a line of it is rewritten.
Your rules all run like this. Overlapping, undocumented, and load-bearing.
Before anything moves, tests record what the old stack actually does. Correct or not.
Then it goes over. In one piece if it is small enough, otherwise route by route, with the old app serving the rest.
The same tests run against the new route. Same requests, same answers, or it does not ship.
Same pages, same business rules, new stack. No feature freeze, and every step revertible.
- 10 days
- to a costed migration plan
- 0
- feature freezes required
- 100%
- of ported routes covered by tests
The situation
If any of this sounds familiar, you are in the right place
Every estimate comes back unbounded
Eighteen months and a feature freeze, or a range so wide it is useless. Nobody signs either one, so the estimate gets redone next year against a codebase that has aged another year.
Nobody left can safely change it
The people who wrote the CFML have moved on. What remains is tribal knowledge, undocumented tags, and a test suite that never existed.
Business logic is buried in the templates
Decades of rules live inside .cfm files mixed with markup and queries. It is genuinely valuable, and no one can tell you where it all is.
What we do
How we approach it
Strangler-fig by default, one piece when it fits
For most estates a routing layer sits in front of the legacy app and we move one route, one screen, one service at a time to TypeScript, so traffic shifts gradually and every step is independently revertible. For a small application with few outside integrations that machinery costs more than it saves, and the whole thing is ported and cut over in a single release instead. The audit tells you which of the two you are before you commit to either.
Logic extracted before it is rewritten
We read the CFML and recover the actual business rules into documented, tested TypeScript functions first. The rewrite becomes mechanical because the thinking has already been done.
Your database stays where it is
Migrating the application and migrating the data are separate projects. We do not force both at once. The new services talk to your existing SQL Server, Oracle or MySQL schema on day one.
You end up with tests
Every ported route gets characterisation tests written against the legacy behaviour first, so we can prove the new implementation matches the old one before traffic moves.
The engagement
How it runs
1 · Audit (10 working days, fixed price)
We inventory every template, custom tag, scheduled task and integration. You get a dependency map, a risk register and a sequenced migration plan with estimates per slice.
2 · First slice
We port one real, revenue-touching route end to end. It proves the pattern, establishes the CI pipeline, and gives you a concrete number for everything that follows.
3 · Steady state
Slices ship on a predictable cadence. Your team pairs with ours and takes over as much as it wants. The goal is that you do not need us at the end.
4 · Decommission
When the last route is off, the CF server is switched to read-only, then archived. Licence renewals stop.
Questions
Frequently asked
How do you migrate a ColdFusion application without a rewrite freeze?
We use the strangler-fig pattern. A proxy sits in front of your existing ColdFusion application and routes each request either to the legacy app or to the new TypeScript service, based on a per-route configuration. On day one everything routes to ColdFusion. Each slice we complete flips one more route to the new stack. Because both systems run side by side against the same database, your team can keep shipping features in CFML the entire time, and any slice can be rolled back by changing one line of routing config.
Can you just port the whole application in one go?
If it is small enough, yes, and then it is usually the cheaper answer. A small application, one database, and no outside integration that cannot be paused for a weekend: there the routing layer and the dual running cost more than they save. We port the whole codebase, run the characterisation tests against it, and cut over in a single release. What that asks of you is a short window where new work lands in the new stack rather than the old one, measured in weeks rather than the eighteen months a big-bang rewrite usually implies. Bigger than that, or wired into half a dozen systems you do not control, and incremental is the honest recommendation, because the risk of a single cutover grows with every route nobody has read in a decade. Either way the audit states which side of the line your codebase falls on before you commit to an approach.
What do you migrate ColdFusion to?
TypeScript on Node.js by default, because it gives you the largest hiring pool and the closest thing to a like-for-like mental model for CFML developers. We are not dogmatic about it; we have moved teams to .NET and to Go where that matched their existing operations. The audit recommends a target stack based on what your team already runs, not on what we prefer to write.
Do you migrate Lucee and Railo applications too?
Yes. Lucee, Railo and Adobe ColdFusion all present the same core problem: CFML business logic entangled with presentation and data access. Lucee codebases are often slightly easier because they tend to be newer and use fewer proprietary Adobe tags, but the migration approach is identical.
How long does a ColdFusion migration take?
The audit gives you a real answer for your codebase in ten working days. As a rough shape: a mid-sized application with a handful of integrations typically runs six to nine months of part-time work alongside normal delivery. Larger estates run longer, but because slices ship continuously you are getting value from month two rather than at the end.
What happens to our database during the migration?
Nothing, initially. The new TypeScript services connect to your existing schema (SQL Server, Oracle, MySQL or PostgreSQL) through a typed data access layer. Once the application is fully migrated you have the option of a separate, much lower-risk schema modernisation project. Keeping these apart is the single biggest thing that stops migrations failing.
What if our ColdFusion code has no documentation or tests?
That is the normal case and it is what the audit is for. We recover behaviour by reading the templates and by writing characterisation tests against the running application: tests that assert what the system currently does, correct or not. Those tests then become the acceptance criteria for the ported code, which is how we prove equivalence without documentation.
Can our own developers do the work with your guidance?
Yes, and it is usually the cheapest option. A common shape is that we deliver the audit, build the first two slices while pairing with your engineers, then drop to a review-and-unblock role while your team runs the remaining slices. You own the codebase and the capability at the end.
What does the migration audit cost?
It is a fixed fee agreed before we start, scoped to the size of the codebase. You keep the dependency map, risk register and sequenced plan whether or not you continue with us. It is a genuinely useful artefact for going out to other suppliers, and we would rather you make an informed decision.
Next step
Start the rewrite
Your name, your email, and three questions we would ask on the call anyway. The reply comes from the engineer who would run the migration, inside one working day, and it is either a scoping call or an honest "we are not the right fit".
- Reply in one working day
- From the engineer who would run it
- No sales sequence