When the legacy platform is still generating revenue, every migration decision gets pressure-tested by one question: Why are we replacing something that’s making money?
The honest answer? Because the platform is one staffing change away from collapse, the codebase is long-term unmaintainable, and the vendor’s roadmap has us boxed in. This never travels well past the CFO. So the scope gets cut. Vendors get trusted. And eighteen months later, the new platform earns less than the one it replaced.
Two disciplines separate migrations that work from the ones that quietly underperform for two fiscal years before anyone names the underperformance. Mid-market manufacturers tend to skip both.
Discipline 1: Scope discipline when the legacy is still earning
The instinct under pressure is to descope features that “the new platform will handle eventually.” Eventually never arrives on the original timeline. The features that get descoped are almost always the ones driving revenue on the legacy — the niche-dealer workflows, the customer-specific overrides, the data exports that three customers depend on but no one mapped.
But the fix isn’t to “preserve everything, do an apples-to-apples migration!” The fix is: any feature touching a revenue stream gets a named owner, a measured baseline, and an explicit cutover plan. If you can’t produce all three, you can’t legitimately descope it. You’re guessing.
Try this:
Three lines on a one-pager, per feature
#1: What revenue runs through this feature in the last 12 months?
#2: Who is the named business owner who signs off on its removal or change?
#3: What’s the cutover state — degraded, parity, or enhanced — at go-live?
If those fields are blank, the descope is a wish, not a decision.
Discipline 2: The vendor-management gap
Mid-market IT shops are structurally outgunned in vendor negotiations. The vendor has a deal desk, a delivery org, a customer success manager, and a master playbook. You have a Senior Manager who’s also running the help desk.
The gap shows up in three places:
Scope creep that benefits the vendor’s margin, not your platform. “We’ll need an additional 200 hours to handle the dealer overrides” — translation: nobody read the SOW the vendor wrote.
The handoff from sales to implementation. The team that sold you the platform is not the team building it. Get the implementation lead in the room before the contract is signed. Their estimate is the one that matters.
Acceptance criteria written by the vendor. If the vendor wrote the test cases, the platform passes them. Write your own.
The vendor isn’t being malicious. They’re optimizing for their margins while you're optimizing for your platform. Without explicit countermeasures, their optimization wins.
Why do both bite together?
Descope without discipline + vendor-managed implementation = a platform smaller than the legacy on day one, more expensive to operate by month six, and underperforming revenue projections for two years.
The descope decisions get made under pressure. The vendor accepts them happily. The implementation hits the reduced scope on time. The platform launches “successfully.” Twelve months later, revenue is running a measurable margin below the pre-migration baseline, and nobody can point to a single decision that caused it.
It was thirty decisions. Each one defensible. None of them disciplined.
Two artifacts that can protect you:
A revenue-feature matrix. One line per legacy feature touching revenue, with the three required fields (above).
Built before the scope is locked.
Updated through delivery.A vendor accountability log. Every SOW change, every acceptance criterion negotiated, every milestone the vendor moved or missed.
Reviewed weekly with the vendor lead.
Surfaced monthly to the steering committee or leadership.
Neither artifact requires new tooling. Both require discipline.
The shops that build them ship migrations that earn more than the platforms they replaced.
The shops that don’t, don’t.
The thirty decisions that quietly killed that migration? Nobody made a bad one. That's what makes this worth writing about every week.
Plant Floor to Cloud goes out every Tuesday. If you’ve shipped a migration like this, or you’re in one right now, I want the war story.
Reply — I read every one.
And forward this to someone who’d find it useful!
Views are my own and do not represent any employer. Nothing in this newsletter is attributable to or sourced from any specific company. All case content is generalized to protect employer and client confidentiality.