“When Will We Finish This Migration So R&D Teams Can Work On Innovation?”

Richard Mironov -

There’s a funny bit of split thinking that I often run into, and which came up in a recent CPO coaching discussion.  It’s when we confuse delivering a new (or re-architected) platform and pushing the very last customer off the old version to free up teams that keep it alive.

Framing up the situation

Imagine that we’re replatforming our B2B/enterprise product set: re-implementing Cranky-Old-Platform-A as Shiny-New-Platform-B.  One development team is keeping Cranky-Old-Platform-A running for our 480 paying enterprise customers … while other teams try to finish Shiny-New-Platform-B.  These re-architectures tend to be 9-month R&D efforts that actually take 2.5 years, partly because we periodically add new features to Cranky-Old-Platform-A for major customer who can’t wait.  Which are then added to the “not yet in Shiny-New-Platform-B” list of reasons why those same major customers won’t migrate.  (See Migrations Are An Organizational Challenge.)

Or similarly…  our customers on Current-Product-v8 say they want lots of innovation and radical improvement, so we’re working on a Super-Cool-AI-Powered-Product-v9.  Hint: our customers will need to do some technical integration or learn new workflows/processes/tools or get a fresh systems audit in order to move from v8 to v9, all of which they hate and will resist.  Dramatic improvements are almost never free or effortless, and every enterprise customer has a 4-year backlog of software waiting to be updated. see other post

Here’s the challenge

Most of our executive attention/Board updates/roadmap updates/marketing sizzle is focused on when we launch our hot new thing.  Discussions are about whether we hit our delivery milestone (and who we punish if it’s late).  When the very first customer migrates, or moves from v8 to v9, we celebrate and wave the flag and declare done-done.  High fives around the board room.  And we’re all eager to start on the next strategic new thing: getting to launch took way too much time and money: visions of future projects are dancing in our heads.

But getting the very first customer to move off Old-Version-of-A onto New-Version-of-A is just the start of a long slog across the entire installed base.  The opening gun.   A journey of 1000 upgrades.

 Here are some of the underlying facts that we all want to ignore:

  • As long as there’s a single paying customer using Old-Version-of-A, that customer expects us to support and maintain it.  If it breaks or goes offline, we need to fix it.  (See We Have To Support Every Line of Production Code Forever.)
  • In my decades of migrations/replatforming, I’ve seen that it’s nearly impossible to deliver 100% backward compatibility if we’re adding new features, changing underlying technology, or doing parallel development where we keep updating both Old-Version-of-A and New-Version-of-A.  If we remove even the smallest obsolete feature/function, some customer complains.  (See The Risks of Replatforming.)
  • While most B2B/enterprise customers shout for shiny new tech and better platforms, in reality they hate to migrate or expend energy on our upgrades.  If there’s anything truly interesting in New-Version-of-A, it will inevitably take some work/testing/data migration/new procedures/audit review/effort to adopt it.  So when we formally announce an absolute end-of-support date for Old-Version-of-A, our largest customers (correctly) assume that’s a suggestion, an optional date, a negotiable item.
  • And reinforcing mega-customer attitudes, our revenue-side execs are willing to tell smaller customers that announced EOL/EOS dates are (in fact) set in stone, but they are rarely willing to tell our largest customers that hard end-of-support dates are really hard end-of-support dates.  “JPMC needs another 6 months.  Even though we already gave them an additional 12 months.  They are too big an account to risk, so we’ve extended the unofficial support period for Old-Version-of-A for just a few more quarters, and just for them.”  Note that these are precisely the high-visibility customers who will call the CEO when Even-Older-Version-of-A stops working perfectly.  “Can’t you just pull a few folks off other work to get them a patch release?  It can’t be that hard, probably only take a day or two.  We can’t afford to p*ss them off right now.”

This sets up a situation where the CEO and go-to-market execs are simultaneously pushing to re-allocate R&D off of Old-Version-of-A and extending the effective support period for Old-Version-of-A.  The strong connection between extending support for even one customer and delaying re-assignment of the team is not obvious.  And individual account teams are rewarded for keeping big customers happy, not for doggedly resisting demands for more time.

What to do?

It’s easy for product folks to fall into lecture mode, talking down to execs.  Or to offer hyper-detailed technical descriptions of replatforming challenges of zero interest to our audience.  (“v8 runs on AWS, v9 in Azure, so the new data synchronization and containerization APIs have more algorithm-related parameters than we expected…”)

If instead we switch to the language of money and hard commercial trade-offs, we can make a better case.

  1. Track migrations on a percent basis, using total account unweighted by revenue.  (If we weight by revenue, we’ll see very little progress since our 10 largest accounts are laggards.)  We’ll see that 15% of all customers have migrated, then 20%, then 30%... that 540 small accounts and 3 huge accounts have moved... that we’re making progress each month. Gives us a guess about when we’ll be done, and undercuts the claim that no one is moving.
  2. Relentlessly show/explain that migrations happen in segments, in waves.  15% of the installed base can move quickly and painlessly; 30% will need extra help from Support/Services; 20% are waiting for FeatureX that’s in the next dot-release; 5% waiting for FeatureY; 20% will wait until the very last day of support before reading any of our notifications or taking any action.  And 10% will never migrate, no matter how much help we offer and how wonderful v9 is.  (They will tell our account team that their non-renewal is because of this replatforming, but there’s usually some other root issue.)   This should prompt a tough conversation about firing a few of our paying customers.

    Plan to re-explain every month: this is not obvious and hard to retain. B2B/enterprise execs focus on our top accounts rather than our mid-market segment, and often generalize from one complaint from HumongoCorp. 
  3. Make economic arguments.  “The 2 teams supporting Old-Version-of-A cost us $2M/year.  We can’t move them to new revenue opportunities until the very last customer has retired Old-Version-of-A.”
    “C-Staff thinks that Not-Yet-Started-Project-D might be worth $50M/year, but it’s currently unstaffed and takes a year to build.  This is the team to work on that.  So we’re postponing $4M/month for every month we extend support for anyone.  Giving HSBC another two quarters on Cranky-Old-Platform-A     would cost us $24M in lost revenue next year.”
    “We project that Shiny-New-Platform-B could save HSBC $12M+ in reduced fraud and faster account setups. Can our CEO call their execs to make an 8-figure business case for getting this done?”
    “How can we push them harder to start migrating?  What extra support could we give them?  Can we engage a third-party consulting team to do it for them – for a fraction of that $4M/month?”
  4. Avoid magical thinking.  We could convince ourselves that old software never breaks, or that all customers are excited about v9, or that backporting features into v8 is easy, or that our stream of support-is-ending-on-31Dec2025 notifications will motivate all customers.  (Nope.)  We move the last sustaining team onto something new, rationalizing that we can always pull them back if disaster strikes.  (It will, at the worst moment.)  We tell ourselves that replatforming at other companies goes smoothly.  (It doesn’t.)  We blame customer non-enthusiasm on poor engineering.  (It occasionally happens.)  We hope that webinars and brilliant product marketing materials will get HugeInc to put this ahead of their other 40 top-priority items.  (Unlikely.)  We choose hope over previous experience.  (Don’t be such a Cassandra!)
  5. Consider some upfront exec negotiation.  “I understand how critical it is for us to shut down Cranky-Old-Platform-A.  As soon as the very last paying customer has migrated off –  or not renewed, or been fired by us  –  we can move that team onto more urgent work.  That requires an iron-clad commitment from the entire exec team, however, that 31 March 2026 is the absolute last day of support for Cranky.   No exceptions, no extensions, no special side deals, no separate hosting, no best-efforts professional services, no C-level engineering escalations for big out-of-support accounts.
    If we’re all agreed [sign here!], then full energy against Shiny-New-Platform-B.  Otherwise, let’s agree that R&D will spend $2M/year on Cranky for many years to come.”

Sound Byte

It’s easy to confuse the delivery of new software with customer adoption.  Replatforming and major platform improvements run into migration trouble as much for one-off support extensions as for technical issues.  Let’s see the pattern, and be collectively smarter next time.