The hard part is not the rate. It is finding anyone at all.
Almost nobody has learned CFML in the last decade, which is why this search is going badly. We have engineers who have written it in production since 2003, and who also write the platform you will eventually move to.
You are hiring against a shrinking population, not a busy market.
The usual levers do not work here. Raising the rate finds you people who have not used CFML for a decade. Widening the search finds agencies who will accept the work and then learn on your system. Waiting does not help, because the population is retiring, not being replenished.
This is a different problem from hiring a React developer in a competitive market, and it needs a different answer. What you are looking for is a team that has continuity in the platform; people who have kept CFML systems running without a break, so the knowledge is current rather than remembered.
That is what we have. iSummation has had ColdFusion applications in production continuously since 2003, including enterprise platforms in mortgage services and event ticketing that are still running. The engineers on those systems did not learn CFML for your project.
The second thing worth knowing is that the same people write .NET, Java and Node. That matters more than it sounds: the team keeping your ColdFusion application alive is the team that can migrate it when you decide to, without a handover, a re-comprehension phase or a second procurement exercise.
Six briefs, in rough order of how often we get them.
Cover a resignation
The maintainer has given notice and there is no successor. We take the handover while they are still reachable and hold the system afterwards.
Most common brief · fastest startKeep the lights on
Defects, month-end problems and small changes on an application that works and is not going anywhere for a few years yet.
Steady state · part-timeBuild features again
The application has been frozen because nobody dared change it. Unfreezing it is usually a documentation and testing problem before it is a coding one.
Change requests · new modulesClose a security finding
An audit or an insurer has flagged the platform and somebody needs to do the remediation work, not write another paper about it.
Hardening · engine upgradeRun the migration
CFML engineers who also write the target platform, so comprehension and rebuild are done by the same people, not passed between two suppliers.
CFML plus .NET, Java or NodeWrite down what nobody wrote down
Behaviour documentation for a system that has none, so that any of the other five briefs becomes possible at a sane price.
Discovery · the prerequisiteAgainst a direct hire, honestly.
A permanent in-house CFML engineer is a perfectly good answer if you can find one. Here is the comparison as we would put it to you, including where the direct hire wins.
What you get
- Full-time attention and deep, exclusive context
- Present in the room for the informal conversations
- Cheaper per hour at full utilisation
- But: a search measured in quarters, in a shrinking pool
- But: a single point of failure again, by construction
- But: no CFML peer to check their thinking against
What you get
- Starts in weeks, from people already writing CFML
- A named second who also knows your system
- Scales down when it is quiet, up for a project
- Peers to escalate to, on a platform with few of them left
- The same team can run the migration when you decide
- But: not in the room, and 4–6 hours of overlap, not eight
Four shapes, and how to tell which one you need.
Most CFML engagements start in the first or second row and move down over time. You are not committing to a direction by starting.
| Shape | Suits | Commitment |
|---|---|---|
| Fractional, a few days a month | A stable application that needs patching and the occasional change | Monthly rolling |
| One dedicated engineer | Active maintenance, a backlog, or covering a departure | Monthly rolling, 30 days notice |
| Small team — two to four | Unfreezing a system and building features again | Rolling, reviewed quarterly |
| Team plus migration | Keeping CFML alive while the replacement is built by the same people | Project plan, staged |
Hiring ColdFusion engineers.
Including the question about rates, answered, not deflected.
How quickly can somebody start?
Introductions within about a week, and a productive start usually two to three weeks after that. The gap is comprehension, not availability, an engineer who has not read your system is not yet useful on it, however experienced they are in CFML. Where there is a departing developer still in the building, we compress this hard and start within days, because that overlap is worth more than any amount of subsequent code reading. If you are in that situation, say so in the first message. It changes how we sequence everything and it is the one variable that cannot be recovered later.
What does a ColdFusion developer cost?
We will give you a real number once we know the shape of the engagement, and there are two things worth knowing before you compare quotes. First, CFML does not command the premium people expect from the scarcity, our rates for CFML engineers sit in the same band as our .NET and Java engineers, because they are largely the same people. Second, the number that matters is not the hourly rate but the ramp: a cheaper engineer who has never seen CFML will spend the first two months learning it on your system, and you pay for that whether or not it appears as a line on the invoice. Ask anyone quoting you how many ColdFusion applications they currently have in production. The answer is more informative than the rate.
Will you push us towards a migration we do not need?
No, and the commercial incentive runs the other way: a support retainer is recurring revenue and a migration is a project that ends. We have clients whose CFML we have maintained for over a decade with no migration in sight, because their applications work and the money is better spent elsewhere. What we will do is tell you once a year where the platform risk actually sits (engine support, hosting, your own team's continuity) so that if the answer does change, it changes on your schedule and in a planning meeting rather than after an incident. The decision is yours and we will deliver whichever way it goes.