Part 8: Changing Business — One night at a time

Everybody that has been working in the context of a larger system upgrade or migration knows that what we’re looking at is a heavy lift! And it doesn’t necessarily get easier if you decide to ‘leave no stone unturned’ and revamp the entire landscape. Surprisingly yet, fast-forwarding like we do brings you one big advantage that more narrow migrations and changes wouldn’t — you don’t need to back-integrate and uphold a lot of legacy systems’ interfaces. And you have the big opportunity to build something very coherent and made mostly of already existing parts (i.e., the selected SaaS). However, this only holds true if replatforming can minimize the duration of running two platforms in parallel by migrating the business swiftly.

Let’s be honest: running an old platform to support your existing business, while designing and building its successor in parallel is insanely expensive and can bleed you dry as a company. The easiest way to deal with that is — not doing it, meaning you close the store for renovation and only work on the new platform. Of course, this isn’t realistic and as Emma’s business is rapidly developing, the very opposite is the case: we need to develop features and improvements on the old platform and simultaneously anticipate those in the new one.

The details of the business in different countries and markets are quite varying, so complexity in terms of features needed also heavily differs. This then also means we don’t know every little detail of functionality yet and need to discover along the way of migrating our business. At Emma we refer to 3 classes of business footprints in a market: 1. Pioneers that are nascent and still need to proof their business case, 2. Emerging that are scaling and 3. Trailblazer that already have scaled and are the most mature. Today Trailblazer countries roughly account for 80% of our business and yield the highest degree of complexity.

Now, when doing a migration from a highly customized legacy system to a new one, a common anti-pattern experienced is to ‘just carry all requirements over’. The systems’ contexts are very different and just because back in the day you’ve decided to solve a specific problem in a certain way, doesn’t mean in a new system environment the same applies. Doing so will easily lead to scope inflation, a (again) suboptimal system design and very long implementation lead times, due to the fact you are replicating a legacy design on top of a new one. Also, there might be integrated solutions on the SaaS platforms or additional purpose-fit services available that could replace your self-built logic. Instead, deeply understanding the business requirements we assessed and put into epics and user stories, we now begin to challenge those requirements with our business stakeholders and re-apply the 6 questions we ask ourselves every iteration (please see part 3 for reference):

1. Are we working on the right topics?
2. Are we working on the topics the right way?
3. Did we really understand the problem domain before jumping into solutions?
4. Can we solve this more simplistic?
5. Is this the right scope for a version 1?
6. What will it take to make the version 1 replace the legacy system entirely?

Using the MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) classification method, this rigid process helps us to minimize the requirements intake and increase speed for a first working version. By this we get early to the point of running the business of a country entirely on the new platform and thus can stop developing features for it on the legacy one.

To be fair, this process is not an easy one, as it involves deprioritizing features and functionalities that will hurt the business directly, sometimes in terms of revenue loss. However, dramatic as those might be regarded in the local perspective of a country, on the global level this still makes sense since it will decrease the time until we can seize parallel development and focus only on the new platform.

Focusing on the global biggest impact levers and minimizing the timeline in mind, we intentionally planned the rollout / migration of our business onto the new platform not as a ‘big bang’ scenario (where you flip the switch for all of business in a single instance) but instead in an incremental way, starting with as little complexity as possible, i.e., Pioneer markets and then unlocking the more complex cases for Emerging and finally Trailblazer markets case by case.

We are thrilled to have successfully rolled out the first Pioneer countries (i.e., Columbia and Chile) by now and prepare now intensively for the higher complexity class of Emerging and Trailblazer markets. As we learn with each country rolled out and having the overall number of >30 ahead of us, we also plan for multiple rollout teams in the project that use the blueprints from the earlier rollouts and replicate efforts in parallel, streamlining the overall endeavor further.

But then again, the whole effort is based on our believe in agility, deeply rooted in Emma’s cultural DNA, iterating on current working hypotheses, and adapting on the feedback gathered. So certainly, we will adapt our approach to the learnings we have on the way. Yet we feel confident we’re doing the right thing and we’re doing it in the right way within our planning horizon at the time of this writing.