Auth0 to Cognito Migration
Accounts migrated
~1.2M
Registered customers across all regions
Drop-off post-migration
Zero
No measurable drop-off across authentication flows
Regional rollouts
12
European markets covered in the migration
Context
Authentication migrations get framed as engineering problems. This one touched 1.2 million customers.
The brief arrived as a supplier swap: move from Auth0 to AWS Cognito, maintain the existing experience, avoid drop-off. Standard framing for an infrastructure change. The constraint set followed: no custom fonts, limited error state control, restricted UI customisation within Cognito's hosted UI.
At 1.2 million registered customers across 12 regional rollouts, any meaningful drop-off in authentication flows represents direct customer acquisition and retention loss. That scale meant the brief deserved more scrutiny than it had received before it reached design.
Authentication migrations are usually invisible to users. The design challenge was keeping it that way while identifying what could genuinely improve, not just survive.
Challenging the Brief
The constraint set had been built on an assumption. I tested it before accepting it.
Before accepting the stated limitations as fixed, I requested direct AWS environment access to review the actual Cognito capability set. I went through the head of engineering to get it approved and stated my intent publicly on the kick-off call. Engineering knew from the start I was going to challenge the constraint set.
That investigation revealed the brief had been built on an assumption: that Cognito's limitations were absolute. Some constraints were real. Others were negotiable with the right technical approach. I wrote up the distinction and used it to reopen the scope conversation.
Constraints that were real
Platform limits that genuinely couldn't move.
No custom fonts within Cognito's hosted UI. Limited control over specific error state presentation. Restricted layout customisation within the hosted sign-in page. These were confirmed through direct environment access and accepted as fixed.
Constraints that were negotiable
Limitations assumed to be absolute that weren't.
Several restrictions assumed to be platform-level were addressable with the right technical approach. Identifying which ones opened the scope conversation back up and gave the team a more accurate picture of what was actually possible.
What I Pushed For
I advocated for two additions. Neither made it into the build. Both are in the backlog.
The capability review opened a conversation about what authentication could be, not just what it had to maintain. I pushed for two improvements that would have meaningfully changed the experience for users beyond the migration baseline.
Pushed for
Reduced friction for returning users. Removes the password recall step for infrequent logins. Deprioritised by the PM on implementation complexity relative to the migration timeline. I understood the reasoning. I disagreed with the call.
Pushed for
Google and Apple sign-in to reduce registration abandonment on mobile. Particularly relevant given the proportion of mobile traffic. Deferred. The migration was treated as a like-for-like swap to minimise risk, with improvements sequenced separately.
Not built — documented and backlogged
Both features are defined, scoped, and ready for prioritisation
I wrote up the case for both magic links and social login and made sure they entered the product backlog with the original rationale attached. The migration created the foundation. The roadmap exists to build on it.
Documenting the reasoning matters. Features deprioritised without written rationale tend to disappear. Features with documented context can be picked up by a future PM who understands why the work was deferred, without needing to rebuild the business case from scratch.
North Star Design
The team needed a shared picture of the destination before they could sequence how to get there.
Without a North Star, phased delivery decisions look like compromises rather than deliberate steps toward something. I designed the authentication experience built without timeline or technical constraints: the version that represents the right answer, not the achievable answer given current conditions.
That design gave the team a shared destination. It made sequencing decisions legible rather than arbitrary. When magic links and social login were deferred, the team understood they were deferring a step toward the North Star, not abandoning the direction.
A North Star is not a wish list. It is a sequencing tool. It answers the question every phased delivery plan needs answered: what are we phasing toward?
Resolving the Sequencing Disagreement
Engineering and Trade disagreed on delivery order. Customer journey criticality was the deciding framework.
Engineering pushed for single-phase delivery to reduce integration complexity. Trade wanted registration prioritised first, given its direct impact on new customer acquisition. Both positions were commercially rational. Neither was obviously right.
Engineering's position
Single-phase delivery reduces integration surface and testing complexity.
Breaking the migration into phases introduces risk at each handoff and extends the period during which two authentication systems coexist. Engineering's case for consolidation was sound and worth taking seriously.
Trade's position
Registration drives new customer acquisition and should ship first.
The commercial-critical flow benefits from the new infrastructure sooner. The case for leading with registration was a conversion argument and reflected a legitimate business priority rather than a stakeholder preference.
I resolved the disagreement by sequencing based on customer journey criticality: starting with the flows most users encounter most often, deferring lower-frequency flows to subsequent phases. That framework gave both Engineering and Trade a legible reason for the sequencing that wasn't purely a design preference.
Platform Considerations
Android was designed as a coherent experience in its own right, not a broken version of iOS.
The migration covered web and the JD Sports iOS and Android app. Once it was clear a custom UI wasn't going to be funded for web, the app ceiling was set by the same constraint. I designed within it rather than advocate for investment that had no realistic path to approval.
On Android, the absence of Apple Sign-In created a genuine design problem. Treating both platforms as identical would have left Android users with an unexplained gap where a sign-in option should be. I designed a separate Android flow that presented the available options clearly and coherently without drawing attention to what was missing on iOS.
Before — Auth0
After — Cognito
Outcome
Zero measurable drop-off. A roadmap where none previously existed.
The migration delivered without measurable drop-off across authentication flows. Maintaining baseline performance through a full supplier change touching 1.2 million registered customers across 12 regional rollouts was the right definition of success for this phase.
The longer-term outcome is the infrastructure and backlog that now exist. Authentication is a product surface that had accumulated technical debt and had no defined improvement roadmap. It has one now.
Commercial outcome
Zero measurable drop-off across all authentication flows post-migration. Baseline customer acquisition and account access performance maintained through a full infrastructure swap.
Backlog created
Magic links and social login defined, scoped, and backlogged with documented rationale. Both are ready for prioritisation without needing to rebuild the business case from scratch.
Roadmap
Authentication improvement roadmap created where none previously existed. The North Star design establishes the sequencing logic for future phases.
Org learning
Constraint investigation approach adopted on subsequent infrastructure-adjacent projects. North Star model used as a sequencing framework going forward within the product team.
What This Case Study Shows
How I handle not getting everything I pushed for.
The navigation case study shows how I identify a problem, gather evidence, challenge stakeholders, and ship and govern the result. This one shows something different: I challenged a constrained brief before accepting it, pushed for improvements that didn't make it into the build, shipped cleanly anyway, and left the product in a better position than I found it.
The maturity is in not needing to win every argument to do good work.
Key Decisions I Personally Drove