Of the seven claims in this series, this is the one I've seen do the most damage: "Most customers are on the current platform. The remaining migrations are underway."
What that usually means: a meaningful share of revenue sits on an older version, sometimes several. The migration program has been "underway" for two or three years. It moves in bursts, usually when a customer complains or a renewal is at risk, then stalls again. There's no single owner, no automated path, and no visible forecast for when it will be done.
It gets explained away in almost every management presentation I've seen, and it rarely gets examined closely. Post exit, it becomes the anchor on the growth plan (really it already was a drag on growth and a cost tar pit…). Every legacy version means duplicate maintenance and split engineering attention. It means security exposure on older components. It means customers who can't use new features, including every AI capability in the roadmap. And it means a renewal risk every time you push a customer to upgrade, because an upgrade is the moment a customer is most likely to go look at the alternatives. Let’s not even start with the CSM and support overhead and nightmare…
The questions I ask are relentless on purpose, because this is where the fuzzy answers can be seen most often during diligence.
How many customers and how much ARR sit on each version today, and how has that changed every quarter for the last two years? Walk me through the upgrade process, step by step, and show me which steps are automated and which are manual. What's the elapsed time for a typical upgrade, from kickoff to live, and what's the range? How much work does the customer have to do: data validation, retesting reports and workflows, retraining users, pulling in their IT team? How many upgrades have you completed, over what period, and at the current pace, when do you finish?
Finally the two questions that usually change the tone of the room.
1) Who is the single accountable owner for the migration program? Show me their plan, their team and their budget.
2) Give me a list of at least ten customers who have upgraded that I can call.
On that list, pick some yourself from the full list of completed upgrades. Don't only take the references management offers. Ask each one how long it took, how much work it was, what broke, and whether they'd do it again. The customer conversations will tell you more than any migration slide. Also ask for the customers who declined or delayed an upgrade, and why. That list is where the churn risk lives.
For portfolio companies, the fix is not glamorous but it is simple. Name a single owner. Fund a team. Automate the upgrade path as far as it will go, because every manual step multiplies across hundreds of customers. Then report progress to the board every quarter as customers and ARR by version. A buyer who sees eight quarters of steady burn-down, with a named leader and a credible end date, will treat the migration as a solved problem. A buyer who hears "underway" will treat it as an unfunded project.
The red flag: no owner, no automated path, and a completion date that keeps moving. Assume it will absorb significant product, engineering, support and professional services capacity for most of the hold. Price it, fund it, and put a named leader on it in the first hundred days.
Next week: Technical Debt.
