ColdFusion → TypeScript
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.
Fixed-scope audit · 10 working days · You keep the report either way
- to a costed migration plan
- 10 days
- feature freezes required
- 0
- of ported routes covered by tests
- 100%
The situation
If any of this sounds familiar, you are in the right place
The big-bang rewrite keeps getting cancelled
Every estimate comes back as eighteen months of no new features. The business says no, correctly, and the codebase ages 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, not big bang
A routing layer sits in front of the legacy app. We move one route, one screen, one service at a time to TypeScript. Traffic shifts over gradually and every step is independently revertible.
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.
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 200-template 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.
Get a migration audit
Two fields to start. We reply within one working day with either a scoping call slot or an honest "we are not the right fit".