Replacing the Legacy Dinosaur
vs. the old enterprise on-prem system
An entrenched legacy system, often on-prem and years out of date, runs a core process. Your wedge is that the buyer's pain, slowness, cost, no one understands it, is the system itself, but inertia and fear of migration keep it alive.
Buyer mindset
The buyer knows the legacy system is bad but is terrified of the migration. The system is woven into everything, the people who understood it have left, and ripping it out feels like open-heart surgery. They have likely been burned by a failed replacement before. Fear of the switch outweighs daily frustration, until the system causes a crisis.
Where they win
- ›Deep entrenchment: it is wired into processes, data, and other systems across the org
- ›Sunk cost and a fully amortized license that feels free to keep running
- ›The devil they know: failure modes are understood and worked around
- ›Switching risk is real, migrations of core systems genuinely do fail
- ›Internal champions whose jobs are built around maintaining it
Where you win
- ›Cloud, modern UX, and a fraction of the maintenance burden
- ›The legacy total cost is huge once you count maintenance, specialized staff, hardware, and downtime
- ›Security and compliance: unpatched legacy systems are a growing liability, often the trigger event
- ›Speed: modern architecture does in seconds what the old system does in minutes or overnight batches
- ›Talent: nobody new wants to learn the old system, the knowledge base is shrinking
- ›A proven, de-risked migration path that addresses the buyer's real fear head on
Traps to avoid
- ›Underestimating migration fear and pitching a rip-and-replace that triggers their trauma from the last failed project
- ›Selling modern UX to buyers who care about risk, not aesthetics
- ›Ignoring the internal champions whose identity is tied to the legacy system and who will quietly kill the deal
- ›Failing to find the trigger event, security, compliance, an outage, that makes inertia finally untenable
Discovery questions
- ›Who actually understands the current system today, and what happens when they leave?
- ›What does the legacy system fully cost you, counting maintenance, specialized staff, hardware, and downtime?
- ›Has a security or compliance review flagged the current system yet, or is that coming?
- ›Have you tried to replace it before, and if so, what went wrong?
- ›What is the process that the old system makes painfully slow today, and what would speed unlock?
- ›What event would force this to finally become a priority, and can we get ahead of it?
Landmines to plant
- ›Ask when the legacy system's underlying platform loses support, and what their compliance exposure is after that date.
- ›Ask how many people in the building could rebuild the system's logic from scratch if it failed tomorrow.
- ›Ask for the all-in annual cost including the specialists who keep it alive, not just the license.
Objection talk tracks
“It works, and replacing core systems is too risky.”
Migration risk is the right thing to be worried about, and I will not wave it away. But there are two risks here, not one. The risk of moving, which we de-risk with a phased path and parallel run, and the risk of staying, an unsupported system that fewer and fewer people understand, on borrowed time. The second risk grows every quarter. Let me show you how we make the move boring and reversible so the only real risk left is doing nothing.
“We have already paid for it, so it is basically free to keep.”
The license is paid, agreed. The system is not free though. You are paying for specialists who know it, hardware that supports it, downtime when it stalls, and the slow process it forces on your team every day. Let me add all of that up next to our all-in cost. The legacy system is almost never free once you count what it quietly costs to keep alive.
“We tried replacing it before and it failed.”
Then you know exactly where these projects go wrong, which makes you the best customer I could ask for. Tell me what failed last time, the scope, the cutover, the data. Our approach is built around not repeating those mistakes, phased rollout, parallel running, no big-bang cutover. Let me walk you through how we avoid the specific failure you lived through.
Proof to gather
- ›A full legacy cost model: specialists, hardware, downtime, and process drag versus modern all-in cost
- ›A de-risked, phased migration plan with a parallel-run option, addressing the buyer's prior failure
- ›Win-loss stories of similar legacy replacements that went smoothly, with the technical sponsor as reference
Make this card yours in 60 seconds
Drop your product and competitor into the builder to generate a tailored, exportable version of this play.
Open the builder