How we Migrated 500.000 Subscribers to a New Platform

Our team of 80 specialists, which is already in the process of building 3 startups, is in a process of a rapid expansion of our company portfolio by focusing on a new business model — Venture Building.

With this business model, we focus on turning early-stage companies into successful, rapidly-scaling ones by providing them with experienced product development teams, funding and business expertise.

We are now in a phase where we’re open to co-founding new companies in partnership with experts who have strong domain knowledge. Because of this, we are looking for co-founders who have an idea on how to digitalize their own domain or have identified a specific problem within their industry that can be solved with a digital product – and they need a team that can help them with business and technical development, operational leadership and investments.

If you have an idea you’d like to discuss, share it with our team!

About this project

This project started when the client approached us to build a new, faster tech stack than the one they used at that moment as their old web couldn’t keep up with their growing customer base.  

Our client has a subscription-based business, and because of that the scope included both building and launching a new e-commerce website while at the same time planning and coordinating the migration of:

• Half a million existing users
• Subscribers’ payment tokens 
• Subscribers’ subscriptions
• Subscribers’ historical orders

This was a complex project and because of that it couldn’t be done without working with various stakeholders such as:

• client’s internal CX
• supply chain
• social and e-commerce teams
• external stakeholders for warehouse management
• ERP team
• performance management
• SEO team

This project also involved working closely together and getting support from technical engineers from payment gateways, migration engineers, and most importantly with the old stack development team.

3 key phases

This whole project was divided into three key phases, while the 2 websites (their old one and the one we were tasked to develop) were running in parallel, which was a challenge in itself.

Three key phases of the project were: 

• Launch and migration preparation

This phase was important as it helped determine if we could complete the migrations with such a large database. This phase included a lot of testing that helped us identify the possible challenges we might face later on, and that helped us to have a plan for solving it right from the beginning.

• A / B testing with new customers from selected countries

When converting users, we separated them into 11 different market groups (grouped by the country users are purchasing the subscription from). That way we were able to do the migration slowly and optimize the site as the number of users grew. This was important because this helped us prepare the site for the final phase – migration of already existing subscribers. 

• Update customers and migrate subscriptions

In the final phase, we were finally ready to transfer all of the existing customers to the new website, which required a lot of planning and a lot of solving of edge cases.

In the rest of the blog post, you can read about each phase in more detail.

PHASE 1 – Launch and migration preparation

One of the most important tasks was that before launching the new website, we had to be sure that we could, in fact, migrate half a million users. We used Chargebee as a user database for storing all customer information, subscriptions, and payment tokens. Because of that, the preparation included extensive coordination between Chargebee’s migration engineers and the client’s developers who had access to the Estrid user and subscription database.

PHASE 2 – A / B testing with new customers from selected countries

Once the new stack was built and tested, we didn’t want to make a complete switch to the new website immediately. The key performance indicators for the new website included making the web faster in speed and increasing conversion rate. And because of that having the old website as a baseline to compare to was an advantage we rarely get when measuring KPIs. We used the existing website traffic to the old site to test the new site performance. 

Our client operates in 11 different markets, and we planned to gradually increase the traffic to the new website starting from smaller markets to the larger ones. This helped us minimize the risk of losing data in the process, and because of this approach we were able to act very quickly if there was a sign of some problem approaching. So we built a new subdomain, where we would redirect half of all new traffic from the selected markets. 

To achieve that, we needed the agency handling the current web to implement the geolocation-based redirects, but we were still involved in the process by coordinating it. The logic was – if you are an existing customer, you stay on the old web, and because of that, you can access your account and subscriptions. If you are a new user and your market was selected for redirection – there is a 50/50 chance you will be redirected to the new subdomain. The whole user and conversion flow was mapped out by analytics consultants and monitored, both in Google Analytics and Hotjar.

Since geolocation isn’t always 100% reliable, we had to cover all possible scenarios. An example for that would be – what if an old user accidentally gets redirected and therefore can’t access their subscriptions? Or what if they get redirected, and they end up buying something on the new web. To avoid that, we had to migrate all customer accounts as empty placeholders and then periodically copy the existing accounts while the websites ran parallelly. If a customer had a subscription on the old site, the new subdomain had to automatically redirect them back if they tried to access their account and checkout. In a sense, we were forcing them to make all changes on the old site because we did not want them to accidentally create parallel accounts. 

This phase lasted around a month because we used insights from the analytics and KPIs to uncover more areas for performance improvement, enabling us to have a fully optimized new website before we redirected all of the new traffic there. Once all new traffic was redirected to the new domain, it was time for the big migration. 

PHASE 3 – Update customers and migrate subscriptions

When all of the new users had been redirected, the only thing left was migrating over half a million subscriptions and updating existing customers. Sounds simple enough, right?

Now there were many more scenarios we had to think about. The first and the most obvious one is what if the subscription is scheduled to renew during the migration period. To solve that, we asked the old agency to export all subscriptions renewing soon to be scheduled to renew two days after the batch date. So if your account was being migrated on the 13th, but your subscription renews on the 14th, your next billing would be moved. This practice saved us several times since we had time to fix any unusual data before the renewal was processed. We now also had to refactor some of the safeguards from the new stack launch. For example, a user would only get redirected to the old site on a login attempt if they were not migrated yet. 

Furthermore, we couldn’t just “trust” that 500k subscriptions were imported successfully, and there was no way to check each of them manually. Instead, with the help of Bornfight’s BI team, we built a script that compared the old site database CSV with Chargebee’s database CSV file and could be used daily to validate that no one was left behind in the migration

And now we were finally ready.

The user migration had to be done in batches since Chargebee could only process 50k records per day, and the whole operation had to be done on a tight schedule. This is because the users were blocked from accessing both the old site and the new site while being migrated, so there is no room for data change during the migration. Imagine it as if we packed and sealed a box of subscriptions, transferred them to the new system, and only after we were sure the transfer was successful, we reopened the box and let the users in. 

Bornfight set up a server where the old agency exported the files and where Chargebee could access it at 3 AM CET, and that way the import starts and finishes as early as possible.

The simplified procedure looked something like this:

• The day before: schedule blocking of users based on next day’s batch IDs
• Migration day 00 AM: export migration files (6 of them) by the script to BF’s server
• Migration day 3AM: Chargebee starts import
• Migration day 9 AM: if everything goes well, Chargebee notifies of successful import and shares error file
• Migration day 10 AM: Bornfight unblocks users on new site and starts data validation
• Migration day 12 AM: Errors shared by Chargebee and from the data validation are analyzed and determined whether they should be acted upon

Again, we were smart enough to start with only 30 customers and ramped up numbers from there. Every day we were finding and weeding out more edge cases, fixed export files, and manually fixed those imports. It was at around 2000 customers per day when we had found 99% of the new edge cases that we couldn’t find in the test migrations. We then safely moved to 50k daily batches.

We were once again the driver and the coordinator of the process, and we were in constant communication with the client – daily and transparently through Slack updates. Their CX team was updated with exact subscription IDs in case of any errors, so that they could act proactively and be informed if a customer gets in touch.

The whole process lasted around 3 weeks since we did make pauses in case there was a larger error. However, with all the safeguards in place and after manual error fixing, we are proud to say that only 3 out of half a million subscriptions were left to import after we did a final comparison between the 2 databases.

WHAT DID WE LEARN?

This project tested our knowledge and expertise, and we are glad it did as these are the kind of projects we excel in. And as with any other project, we learned some lessons we would like to share with you now:

1. Always start small and increase load if you have the opportunity – it will allow you to weed out unexpected edge cases and fix things that you wouldn’t have found otherwise
2. Test, test, test – there is never enough testing, and we did a lot of it while increasing the numbers – we always did it with real data since you can never think of enough weird inputs as real-life users can create them – like the user who pastes their whole shipping address in the zip code field
3. Validate – don’t just trust things will go well, make sure you can have proof that they did
4. Have a contingency plan – although we didn’t have to use it, it felt better knowing that we had mechanisms to revert the migration in case something really did go awfully wrong

If you want to learn more about this project, you can read about it in our case study here!

_____

We’re available for partnerships and open for new ventures.

If you have an idea you’d like to discuss, share it with our team!