Learnings from re-platforming: Business expectations (4 months) vs reality (2 years)
“Ow! How’s that going?” This was the common response when I told other Product people that I was managing a re-platforming work.
Arguably, re-platforming is one of the most complicated things you can do in your Product career. With re-platforming, you’re not working with a blank canvas. Rather you’re working to change (and hopefully improve) someone else’s work, with pre-defined boundaries and expectations. Additionally, your stakeholders will be unwilling to lose certain functionalities or change certain workflows they are already accustomed to. To top it off, the number of stakeholders which you have to consult with multiplies and becomes multi-layered.
During my time at Les Mills, we were re-platforming our subscription systems — billing, taxation, marketing platform, and website to new a few. This was done across 115 different countries. As you can imagine the level of complexity behind all of this was extremely high. This led to many mistakes and learnings along the way. There were some things we did right, and some things we could have done better, a lot better. We managed to get through the bulk of the re-platforming work in a couple of years. Here are some of my learnings throughout the journey:
1. Resource the team properly
This one is especially important. Replatforming is very intricate. Especially if you are re-platforming a number of systems like we did. You need a dedicated (and ideally in-house) team or even teams to handle this from start to finish. It’s highly recommended that you bring people in who had previously done a re-platforming work.
Resource also includes time. Give the team sufficient time to re-platform. Actually, give the team more time, way more time than you think you’d need. When I was brought into the team, it was expected that we’d launch the new platform in a few months. Two years later, it’s still not fully completed yet. The devil is in the details.
2. Gather and document all functionalities of the existing platform, as well as what the new platform is expected to bring
Do this before you start anything! Then review them with the relevant stakeholders. Ask them why certain functions are important or were implemented in the first place. Knowing this will give you some context and you may find better ways to achieve the same outcome in a different and better way in the new platform.
Not having a great level of documentation will lead you to some surprises down the track. Having a Business Analyst would be super helpful here. I know, I know… A lot of “agile” teams are moving away from the idea of having BA roles… But hey personally, I think the BA (or at least someone who can do the job of a BA) would do wonders.
Understanding what the expectations are on the new platform would also be super helpful. Are there any pain points from the legacy platform which the new platform is supposed to solve? This will also help you with choosing the right solution and tools.
3. Test, Test, Test
If location is the golden rule of real estate, then testing is the golden rule of re-platforming. For every single user journey you’re migrating, create test cases for each. Whether that is pricing verification, login validation, or cancellation emails, know what you need to test before migrating. This will give you an indication of whether you have successfully migrated a particular journey or function.
Then, don’t forget to log each test result… so you don’t have one of those “what happens in this scenario again?” moment… (we may or may not have done this for some of our test cases 😐)
4. Have a changelog
Again, re-platforming is extremely complicated. There will be times where you have to change certain logic, especially if you are re-platforming in multiple stages.
For us, we had to change our SSO logic to connect the different platforms we integrated with numerous times. This was partly because we were pressed for time and had to launch the new platform for a specific country first. After a number of changes, we got lost in its intended logic and around what changes had been made. This led to some “huh??” and “oopsies” moments when we rolled out the new platform to other countries.
5. Communicate with your stakeholders
From the second point above, hopefully, you have things nicely documented already. This is not enough! Communicate your progress and upcoming plans with stakeholders to ensure that their requirements have been fully understood and will be correctly implemented. We had an important requirement around our Affiliate offers which we had missed due to a lack of communication between myself and our stakeholders in the US. Ceremonies like sprint reviews would help with this.
6. Treat the new platform as a product
Many would treat the re-platforming work itself as a “project”, as your company probably expects an “end date”. As a Product person, it’s your responsibility to treat re-platforming as a product. Have an iterative approach to things. There were times where I had to make a call to introduce certain features (change email address with no email confirmation sent & price reduction without an indication of the original price, to name a couple) early but not fully due to the value that the first iteration would bring.
Have an objective to what the new platform should be achieving — i.e. higher conversion rate, reduce support tickets, etc. This will provide you and the team good indications that the re-platforming has been both “successful and meaningful.
Alright. This is just several out of the many learnings I’ve taken along the way. I’m sure there are many other important learnings which other Product people have experienced. Feel free to reach out so we can share our experiences!
For now, I’ll leave you with a brief reflection of my first re-platforming experience.
What I wish we had
Better documentation and analysis work.
An in-house development team.
More time.
What I’m grateful for which we had
A Tech Lead who had done re-platforming work before.
“Hard” (negotiable) deadline.
Moments of celebration for each milestone.