Every now and then we need to replatform a legacy product. The product has been a success, it has been evolving for years, and customers love it. But for a set of technical and business reasons it has limited growth potential.
I have done this a few times, and I have also watched while others have had to put their favourite toys away for good while they build new toys. So I thought I would share my journey, and hope that we don’t repeat the same mistakes
Rich Mironov has a great article about replatforming:
... This is an essential part of the software product business, but fraught with poor assumptions and lack of experience/understanding. And the majority of replatforming and reimplementation efforts I’ve seen have failed.
Migration is necessary if you want to move forward, we can't stay on legacy tech forever. Customer's demand new features, even though they love the old features. They want a simple and shiny UI, but they are experts on the old UI and don’t want it to change.
Migrating to a new platform is controversial. We know we’re going to upset customers, users, long time supporters, sales, support team, coworkers, management, and everyone else. They all want the things you are promising, but they are the ones that are going to be the recipient of some pain. There is going to be collateral damage along the way.
Here are some of my learnings
- Starting with the strategy and business case
- Plan for the long term
- Don’t just replace, provide a better future
- Minimise disruption through incremental changes
- Have a fall back plan
- Monitor progress and respond
- Nudging at the right time by the right amount
- Communicate with stakeholders and customers
Starting with the strategy and business case
You need a clear understanding of why you are doing this, and where it fits in against your other priorities.
A recent example was when mobile carriers needed to free up radio spectrum so it could be re-used for new mobile phone technology. Their customers had phones from the last 10 years that worked fine, and they didn’t want to upgrade. The growth of their business depended on the future customers on the future network, not on keeping the old customers on their old phones.
Migration is like any other feature you are building - it should follow the existing process as much as possible with a business case, strategy, and change plan. It may not be as simple as additional revenue or more active users. It may require understanding how removing code is a development and support cost reduction, and it may even come at the cost of lost users who don’t want to migrate.
Your sales team might see this as a threat to all the features you could be building. Your business case should answer why the new world is better than the old world. For example, whether it is faster delivery, lower support costs, better integrations, etc.
Plan for the long term
Once you are clear with the strategy you can break it into lower level goals. When does the new platform need to be available? What are the smaller steps you can make along the way? How are you going to migrate customers? How do you shut down the old system? How does it fit in with the customer upgrade cycle?
Work with your engineering team to have a high level idea of how long it might take. This is likely to be a big messy project spanning multiple years, so make sure it is not an optimistic time estimate. Set expectations with stakeholders and customers about what you are doing, and how long it might take.
Don’t just replace, provide a better future
Customers don’t care that you have good reasons for migration. They are worrying about a lot more things than your little app - your app is a small part of their day. They only care about what you are providing them, and their loss-aversion will drive a focus on the negative sides of the migration.
So if you’re going to put them through some change, it should be for the better. How will this save me time? How can it make my life easier? Does this make my current problems go away?
For example, think about what outcome you are trying to achieve for your customer. Look through your product analytics and see what are the most used features. What is that feature being used for, and what outcome does it drive? What you might be able to do to improve that outcome?
Another example was for an app that allowed customers to record issues so they could be handed to other people to be resolved quickly. The current system only had the ability to describe the location through a location hierarchy and text field. The new app was designed around the idea of a graphical mapping interface to exactly pinpoint the location of the issue, which not only made it clear where the task was, but opened up further analytics on identifying common issues by location.
Minimise disruption through incremental changes
We know that the first version of anything sucks. Sometimes 'Minimal Viable Product' is used as an excuse to put out poor quality work.
However in this migration you need to understand that any change is an opportunity for a customer to re-evaluate their choices. Customers may thing "... if everything is changing anyway, maybe I’m better off with the competitor."
The changes don’t need to be our classic software “MVP and iterate” model. They could also be other forms of gradual improvements. For example, starting with broadcast communications about the plan, followed by targeted comms about how it affects you directly, followed by some discount offer to show the customer that you value their business and want to keep the relationship.
Have a fall back plan
Naturally something is going to go wrong. Whether the new tech doesn’t work or the customer doesn’t migrate, things may not go as smoothly as you would like.
In one case of migration, the mobile apps we ran into some bugs along the way, not related to the new app, but it was coincidental in the minds of the customer. Rather than add new uncertainty, we decided to pause the rollout of the new app, fix the bugs, and then restart the rollout.
Monitor progress and respond
How do you even know if the customer is moving across to the new platform? Having product analytics tools installed is essential.
If you are doing a hard lift-and-shift you know exactly when the customers move across, but this is a brave (and often foolhardy) way of working. It is more likely you are trying out specific customers on the new platform and testing as you go. Perhaps the new customers, or the less demanding customers.
Use the analytics tools to monitor your new users versus the baseline of the old platform. You’ll want to see if users are taking up the new software, are they getting their tasks done, and whether they are as efficient as before.
Having analytics allows you to assess how your migration is going. You can now reassess your timeline, and also plan some nudges to move more and more customers across. Key milestones like 50% of users migrated is something you should celebrate with the team
Nudging at the right time by the right amount
In our mobile apps, we created deliberate nudges to gently push our customers over to the new application. We started small, with an advert within the old mobile app for the new app. Customers could click on the advert and it would take them to the app store. Over time the advert got more insistent, for example it became a pop-up at first login that you needed to click through. Eventually the advert could not be dismissed, and the old app was effectively dead.
During this time we also removed the app from the app store. This doesn’t remove it from the existing user’s device, but it does stop new users starting to use the system. If a user has an old version of a mobile app installed there is no way to get rid of it. So the final step is disabling the API calls from the retired app.
It was important for you to be in control of the migration process otherwise it never ends. This means designing those changes to be triggered remotely. In the case of mobile apps, you may even need to get these software nudges in early so you can catch those users that don't update their apps very often
Communicate with stakeholders and customers
Since this is a long process, make sure you communicate your progress along the way.
Customers on the new system want to feel special, but also that you are heading in the direction they need from you. Letting them know your high level steps of migrating them to their new system. Not only will they be a bit more accepting of the small glitches along the way, you are likely to get feedback on whether you are doing the right things in the right order for them.
Conclusion
Not surprisingly, migrating off legacy technology is not too dissimilar to building the right new technology for our customers. Start with the business case and a deep understanding of what the market and customer needs - and deliver incremental value to the customer. Not everything is going to go smoothly, so monitor along the way and make course corrections as necessary. And make sure customers and stakeholders are in the loop.
How has migration gone for you?
Let me know in the comments
Photo by Rodolfo Mari on Unsplash
Comments
Post a Comment