Moving users off a legacy product without breaking trust
Leadership wanted to retire an older rewards product and consolidate onto a new flagship. A forced cutover was operationally simpler — but it touched users' real assets, so it risked confusion and backlash. I designed a voluntary, phased migration that earned the move instead of forcing it: 70% migrated on launch day, 52% voluntarily within 14 weeks, and not a single user was ever force-migrated.
- Role
- Product Manager (lead)
- Team
- 1 PM · cross-functional (eng · design · marketing · support)
- Timeline
- Phased rollout · 14-week window
- 70%
- Launch-day flow conversion
- 52%
- Legacy base migrated, 14 wks
The setup
As the company shifted focus to a new flagship investment product, an older rewards-based product became expensive to maintain and hard to explain inside the broader experience. Leadership wanted users off it.
The catch: this wasn't a feature swap. Users still held real value in the legacy product, so a direct forced migration risked confusion, distrust, and backlash — against the exact users the new flagship needed most.
The challenge
Three goals pulled in different directions:
- Business simplification — stop paying to run two overlapping reward systems.
- User trust — make existing holders feel their assets and early support were respected.
- Migration effectiveness — move a meaningful share of legacy assets, not just user counts, before anything irreversible.
A forced transition was the simplest path and the riskiest one. I needed a strategy that reduced uncertainty and earned adoption.
The core bet: earn the migration, don't force it
The key decision was to not start with forced migration. Instead I split the transition into phases, turning one irreversible call into a staged process with measurable checkpoints.
| Phase | What happens | Why |
|---|---|---|
| 1 · Voluntary | One-click transfer of legacy assets into the flagship | Give users control, collect real adoption data |
| 2 · Observe & retarget | Watch adoption, support tickets, sentiment by segment | Adjust messaging before escalating |
| 3 · Forced decision | Only then decide whether/how to force the rest | Make the high-risk call with evidence, not guesses |
The product judgment calls
1 · A one-click transfer that feels like an upgrade. Behind the scenes the flow sold the legacy product, converted the value into rewards, and created a new flagship order. The user should feel they're upgrading, not rebuilding a portfolio by hand — so the flow avoided unnecessary input and preserved any leftover reward balance.
2 · Migration is atomic. A transfer only counts as successful if the new flagship order is created. A dropped connection mid-flow must never leave a user half-migrated — partial completion on real assets is exactly how you lose trust.
3 · Deliberately no cash incentive. The obvious lever was to pay users to migrate. I argued against it: a bonus reframes the move as something the company needs, not something better for the user, and quietly undermines the "this is an upgrade" narrative. Messaging leaned on product value and protected rights instead.
4 · Protect high-value users without creating unfairness. Some holders had enough legacy assets to exceed the flagship's normal holding cap. Raise the cap for everyone? Only migrators? Only those already over? We chose to protect existing rights without minting a permanent privilege — attractive enough for whales, still fair to users who'd adopted the flagship early.
5 · A launch built around signals, not a single announcement. Phase one bought awareness and trust; phase two retargeted based on real adoption and support feedback; stronger messaging only came later, once early migrants had created social proof.
What shipped
A voluntary one-click migration flow with entry points from the legacy product, in-app comms, post-migration product states, holding-limit rules per user segment, success-event tracking, admin visibility for support, and a coordinated launch across product, marketing, and support.
What I owned
I led this end to end as PM:
- Framed the migration problem and set the first-phase strategy — voluntary before forced.
- Segmented users by ownership level and migration risk.
- Defined the one-click transfer experience and its success criteria.
- Translated asset and holding-limit rules into product requirements.
- Aligned product, design, engineering, marketing, and support around a sensitive, asset-touching transition.
- Defined the metrics and post-launch actions that would guide the forced-migration decision.
Impact
How to read these numbers. They use different denominators on purpose. 70% is the launch-day conversion rate of users who entered the migration flow — it measures how well the flow itself converts. 52% is the share of all legacy-product holders who migrated over the 14-week window — the project's real success metric, measuring penetration of the whole base. (A few high-value users hold a large share of assets, so we tracked migrated assets too, but the headline numbers are user-based.) All migration here was voluntary, before any forced step.
Beyond the numbers, the phased approach did its real job: it reduced strategic uncertainty, protected user trust, and kept an irreversible decision from being made before there was enough behavior to justify it.
What I took away
The interesting part of this project wasn't the migration flow — it was the judgment around it: how to move people off something they value without breaking trust, how to design incentives without making the narrative feel bought, and how to use sequencing and post-launch signals to de-risk a decision leadership wanted to make all at once.
Reach out to see more behind the workOut of respect for confidential client data, those details stay off the public site.
There's more behind this case: the real screens, dashboards, and the trade-offs that didn't make the write-up. I'll happily walk you through the real numbers and decisions in a conversation. Email me at