01Read and inventory
The application, the engine, the hosting, the integrations and the scheduled tasks. Anything urgent is raised the day we find it.
You get, an inventory and a risk list, both yoursModernize
Somebody who answers the phone and has read your code.
Not every ColdFusion application needs migrating. A great many of them need one thing: a maintainer who is not a single point of failure, and who will still be there next year.
At a glance
- Model
- Retainer with a named engineer
- Not
- A ticket queue with a rotating pool
- Covers
- Fixes, small features, patching, advice
- Handover
- Structured, while they are still there
- Documentation
- Written as we go, and yours
- Exit
- Notice period, no lock-in
What a retainer covers
Six things, and the fourth is the one people undervalue.
01
Keeping it running
Defects, incidents and the things that break at month end. An agreed response time, and an engineer who does not need to be told what the application does before starting.
Incidents · defects · month-end
02
Small changes
The tax-rate change, the new report column, the field the regulator now wants. Work that is too small to be a project but blocks somebody's week.
Change requests · reports · forms
03
Patching and hardening
Engine updates, dependency remediation and the exposure review that most CFML installations have never had. The single highest-value item on this list.
Engine · dependencies · exposure
04
Writing it down
Behaviour documentation produced as a by-product of the work, so the knowledge accumulates outside one person's head. This is what you are really buying.
Behaviour · integrations · runbooks
05
Telling you the truth about the platform
An annual view on engine support, hosting and where the risks are moving, so the migration conversation happens on your schedule, not after an incident.
Risk review · options · costs
06
Cover when your person leaves
The reason many teams call us in the first place. We can hold the system while you hire, or permanently if you would rather not.
Handover · continuity · on-callThe situation we are called about most
Your ColdFusion developer has resigned.
This is the most common first call, and the window is usually being wasted while the call is happening. If the person is still in the building, even part time, that access is the most valuable asset in the situation and it has a hard expiry date.
What does not work is asking them to write documentation. They will produce a description of the system as they understand it, which omits precisely the things that are only visible to somebody encountering it for the first time.
What works is structured sessions while we read the code, because the questions worth asking only surface once you are inside it. Then we watch a real release, and then we take the pager while they are still reachable.
Where the person has already gone, we reconstruct from the code, the database and the people who use the application daily. It costs more and takes longer, but it is a well-worn path and the output is the same: documentation you own.
Getting started
From first call to covered.
02Close what is urgent
Exposed surfaces and unpatched components dealt with before anything else, because those risks do not wait for a contract to be signed.
You get, the immediate exposures closed03Shadow the current maintainer
Or, if they have gone, work with the people who use the system daily to reconstruct what it is supposed to do.
You get, behaviour documentation started04Named engineer, agreed response
One person who knows your system, with a named second who also does. Monthly reporting on what changed and what we would fix next.
You get; continuity, and a monthly viewHow it works commercially
The things you should ask any support provider.
We would rather answer these before you ask than have you find out afterwards. If you are comparing providers, these are the questions worth putting to all of them.
- A named engineer, not a pool. You get a specific person and a specific second. The value of this arrangement is accumulated knowledge of your system, which a rotating queue destroys by design.
- Unused hours are not simply lost. Quiet months carry forward within the term. Support demand is lumpy and a contract that punishes you for a quiet quarter encourages exactly the wrong behaviour.
- Documentation is yours, in your repository. Everything we write about your system lives with your code, not in our wiki. If the relationship ends, the knowledge does not leave with us.
- We will tell you when to stop paying us. If the right answer is a migration, or bringing it in house, we will say so. A retainer that quietly outlives its usefulness is bad business for both sides.
- Notice period, no lock-in. No multi-year commitment, no exit fee, and a handover to whoever comes next that is as thorough as the one we asked for coming in.
- Migration credit if you decide to move. The comprehension work done during support is the first phase of any migration. You should not pay for it twice, and with us you do not.
Questions worth asking
About ColdFusion support.
The three that decide whether a retainer is the right shape.
Our application has had no attention for years. Will you take it on?
Yes, and that describes most of what comes to us. An application that has been running untouched is usually in better shape than its owners fear: the code is stable precisely because nobody has been changing it, and the business has adapted around whatever it does badly. What we find instead is accumulated exposure, an engine several versions behind, dependencies with published advisories, an administrator interface that should never have been reachable, and no tested restore. Those are all closable, usually within the first few weeks, and they are cheap relative to the risk they represent. The first month of any takeover is deliberately weighted towards finding and closing them rather than towards new work.
We only need a few hours a month. Is that worth anyone's time?
It is, and small retainers are a large part of what we do on CFML. The economics work because the expensive part is comprehension, and that is paid once. After an engineer has read your system, a handful of hours a month is enough to keep it patched, handle the occasional change and stay familiar enough to respond usefully when something does break. What does not work is calling somebody cold once a year: you pay for the comprehension again every time, and you get it at the worst possible moment, which is during an incident.
Can you work alongside our in-house developer, not replacing them?
That is often the best arrangement of the three. A single in-house developer on a CFML system carries a burden that is not really about workload, they cannot take leave comfortably, they have nobody to check their thinking against, and the organisation has no answer if they are ill. We can be the named second: reviewing changes, covering absence, taking the work they would rather not do and, importantly, being the person they can talk to about a platform almost nobody else in their network still uses. It is usually cheaper than a second hire and it removes the single point of failure, which is the actual thing you are worried about.
Related capabilities