Retire a legacy product IV: the transition period

A customers once approached me, asking a question that seemed very simple and yet out of the blue “I used to have this filter X. Where is it now in the new module?”

She is a customer who came from our legacy solution, and now uses the new solution. The type of customers we internally call — a migrated customer. In her question, she was simply referring to a filter that she was used to in the legacy, and couldn’t find in the new solution. Migrated customers have a lot to get used to, and compare to. You’ll likely find them attempting to use the new solution in the old way.

If you’re a Product Manager who’s driving the replacement of a legacy product, you can be in for a long transition period that doesn’t seem to end. To add to that, it’s not just a transition for the migrated customers, but also for the internal functions, e.g. Service, Consulting, and Sales.

This is the finale of a series where I’ve discussed 4 bits and pieces of retiring a legacy product:

• I — What does it mean, esp. in a B2B setting (Jobs, involved people, complexity level, desired outcome)
• II — Internal buy-in (From individuals to mid-managers to leadership back to individuals)
• III — Accounts and contracts (Handling various contracts, collaborate with stakeholders)
• IV — The transition period (Customer care, product collaterals, continuous buy-in)

Since Q4 2023, I’ve been drafting and pushing forward a plan to sunset an ancient legacy solution from our product suite — a 16-year-old B2B software. There are hundreds of B2B customers using it; half of our organisation knows the solution like the back of their hands; the replacement solution is the stepson whom most don’t look straight in the eyes. Never said it was easy, but it’s going forward.

In the first three parts of this series, I’ve discussed the roles and jobs, the steps and complexities, the buy-ins and legalities, etc, of replacing a legacy with a new solution. This last part will be short and crisp — if you have successfully led through all the previous steps, and only have the transition period ahead of you, I’m certain a few principles and reminders are all you need.

See through what’s behind the comparisons

In the example at the beginning, the migrated customer appeared to have missed a filter in the new solution. What mattered the most was not asking about the filter, rather firstly telling a missing feature apart from the result of comparing. To do this, use our regular interview techniques, i.e. ask open questions and get to the bottom of things. Then map the actual feedback according to the types of customers (migrated, or started off from the new solution).

If the interview result pointed to a valid reason to add a functionality, develop it. In this case, the filter was added to the new solution based on strong proof.

Don’t encourage nostalgia

Change is done — new contract signed, data migrated, roll-out awaits. Encourage the customers and internal parties to move only forward. When you hear statements or complaints about how “enough”, “working well”, and “smooth” was the previous solution, know that it’s probably false positivity. We tend to remember the good aspects in the past, especially the present takes a bit of effort.

I will not recommend that you let it go, rather, politely and repeatedly call it out. Communicate the motivation that drove us to develop the new solution, the cost of the non-scalable legacy, as well as the fact that dwelling on the nostalgia isn’t helpful. Offer the perspective that the sooner they start embracing the new reality, the easier and quicker the transition would be.

Stay attentive

I would be lying if I tell you that you can relax now. You might have achieved internal and external agreements to replace the legacy, but there might be plenty of post-deal scenarios to keep you busy. So don’t toss away any data and collaterals you prepared and presented along the way just yet. It’s likely that no one but you has a file depot that stored all the facts, materials, meeting minutes, etc.

When your stakeholders waver back, you’ll need those facts again — to reassure them that the contract situation is not as complex as they thought, or to stop them from worrying about workload by showing the state of data migration. You may need to produce new materials as well, e.g. a fact sheet or a communication guide to make sure everyone is well geared up.

At the end of the day, on one is likely to be perfectly ready for such a job. Were you perfectly ready prior to starting this journey? And did you let it stop you?

That’s all for this series of Retiring A Legacy Product! I’d like to thank you for reading. Any questions or comments, I would love to hear from you.