App Consolidation

Foodora was consolidating multiple country-based apps into one global product. For the business, this meant moving existing customers successfully before the legacy apps could eventually be retired.

For customers, there was no reason that organisational or technical change should mean starting over. They already had accounts, saved information and an established relationship with the product.

Every additional step — downloading another app, signing up again or re-entering information — introduced another opportunity to lose them.

The consolidation touched more than the product interface. Product was responsible for migration and retention, Marketing for communication and incentives, local teams for rollout, and Engineering for what was technically possible.

My role was to represent the customer experience within those constraints — keeping effort, continuity and clarity part of the decision-making as the migration strategy took shape.

Rather than beginning with screens, we aligned around one shared goal:

Move existing customers successfully while creating as little disruption as possible.

Before exploring the migration experience, we established a simple principle:

Never ask customers for something they’ve already told us.

That gave us a way to evaluate solutions beyond whether they were technically possible. The migration should minimise customer effort and confusion, avoid creating unnecessary dependency on campaigns or incentives, and still work within the existing platform and backend constraints.

The aim wasnt to redesign the entire product. It was to make the transition feel as effortless as the existing technology allowed.

The obvious solution was also the easiest technically: ask customers to download the new app, sign in or create an account again, and rebuild what they needed.

But that transferred the complexity of consolidation directly to the customer.

Working with Engineering, we explored how much context could move between the old and new apps — allowing more of the transition to happen behind the scenes.

That changed the question from “How do we help customers migrate?” to:

“How much of the migration can the system do for them?”

Working closely with Engineering, we explored different ways to move customers between the apps rather than committing immediately to the simplest implementation.

Three approaches emerged: asking customers to migrate manually, matching accounts in the new app, or using a Deep Link Exchange to carry migration context from the existing app into the new experience.

Each came with different trade-offs across customer effort, technical complexity, edge cases and operational cost.

The Deep Link Exchange required more engineering work upfront, but offered the strongest continuity for customers — reducing repeated steps while still working within the available technical constraints.

Once we chose the Deep Link Exchange direction, the challenge became designing for the different situations customers could arrive in.

The new app might already be installed, the customer might be logged in, their account might or might not be recognised, and the expected connection could fail.

Rather than designing a single happy path, we treated migration as a system of connected states — each with a clear route forward or fallback.

This kept the experience predictable even when the underlying conditions were different.

Migration communication couldnt rely on a single message repeated everywhere. Customers encountered the old app with different intentions and at different stages of the rollout.

We designed a progression of interventions — from lighter-touch banners and prompts to more prominent modal or full-screen experiences as migration became more urgent.

This allowed the experience to become increasingly explicit without immediately blocking customers from what they came to do.

The principle was simple: use the least disruptive intervention appropriate for that moment.

The final journey connected the old and new apps as one continuous experience rather than treating them as separate products.

Customers started in the app they already knew. From there, the migration guided them to install or open the new app, carried available account context across, and introduced authentication only when needed.

Once connected, customers arrived in the new app ready to continue.

The complexity remained underneath the experience. For the customer, the journey needed to feel like moving forward — not starting again.

Our initial flow focused on completing the migration successfully. Once the account transfer worked, customers simply moved into the new app.

Research exposed a gap: the system knew the migration had succeeded, but customers didn’t necessarily know what had happened.

We added a clear success moment that confirmed the transition and reassured customers that their account had moved with them.

Completing a technical process and giving someone confidence that it worked are two different things.

Our initial flow focused on completing the migration successfully. Once the account transfer worked, the experience simply moved customers into the new app.

Research exposed a gap: the system knew the migration had succeeded, but customers didn’t necessarily know what had happened.

We added a clear success moment that confirmed the transition and reassured customers that their account had moved with them before they continued.

It was a small addition, but an important one. Completing a technical process and giving someone confidence that it worked are two different things.

The migration needed to work across both iOS and Android, but app installation, deep linking and authentication behaved differently across platforms.

Rather than forcing both platforms into the same flow, we kept the customer intent consistent while adapting the journey to each platforms behaviour and constraints.

The destination remained the same: customers arrived in the new app with as much of their existing context intact as possible.