DPD · Product adoption
Two technically successful user migrations that failed to deliver adoption or learning
How rollout decisions, missing critical functionality and a temporary login process created cost without achieving the intended business outcomes.
Executive summary
The migrations worked technically. The product outcomes did not.
Across two rollout stages, users were successfully given access to a new B2B platform. But access did not become meaningful adoption, and the planned learning loop did not influence the product.
The internal BETA introduced a temporary authentication process to accelerate access. Users then encountered a product without the critical functionality needed for their work. The feedback cycle the rollout was intended to create did not produce corresponding product changes.
The later business migration repeated the same structural problem: technically onboarded users still could not complete their primary tasks.
The real problem
This was not primarily an access problem
The technical question was how to move users from a legacy platform into a new one. The product question was whether the new platform was ready to support their work.
That distinction changed how I evaluated migration readiness. I looked beyond account creation and login to the complete conditions required for adoption: critical functionality, roles, permissions, data, operational dependencies and a reliable route from feedback to product decisions.
Migration 01 · Internal BETA
Fast access was treated as the outcome
The internal rollout had two intended goals: allow employees to test the product in real work and use their feedback to improve it before business customers were migrated.
Two authentication paths were considered. I mapped both to make their dependencies and long-term implications visible.
Temporary login with the same credentials
What this variant includes
- The legacy and new applications remain connected.
- Users enter the new product with their existing login and password.
- This grants access rather than completing a real user migration.
- Password change and recovery remain supported by the legacy system.
- The solution works only until the two systems are separated.
- Adapting the shared processes still required more than one implementation sprint.
The central question was whether a temporary route justified its own implementation time. Its value depended on using early access to test the product and generate learning before the unavoidable target login was built.
Target login for two independent systems — Recommended
What this variant includes
- The legacy and new applications are separated.
- BETA users are actually migrated to the new system.
- Users create a new, independent password for the new product.
- The new system owns password change, recovery and reset.
- The flow includes validation, failed attempts, account locking and supporting emails.
- New security requirements include stronger password rules and CAPTCHA.
This variant was more complex, but it represented the required target state. Building it directly would have avoided implementing authentication twice and focused the team’s effort on the migration that still had to happen.
Decision and consequence
The decision optimised implementation speed, not migration value
The temporary solution was selected because it was easier to implement and the team wanted to provide internal users with access quickly.
But access was only an enabler. The intended outcomes were adoption, product testing and actionable user feedback.
Because critical functionality was still missing, internal users had little reason to use the product in their daily work. When feedback was eventually collected, it did not reliably translate into product changes.
The temporary authentication process therefore created implementation and replacement work without enabling the learning it had been introduced to support.
Evidence before implementation
The implementation debt was visible before development began
During the decision analysis, I raised the risk that separating the temporary and target authentication models would create implementation debt and require the team to replace work shortly afterwards.
“Would this create excessive implementation debt when the two systems and user models had to be separated later?”
I also questioned how long the shared-password solution was expected to remain in place. The anticipated transition period was short, strengthening the case for investing directly in the target model.
What the shortcut deferred
The complexity that concerned the team still had to be delivered
The target authentication model was a larger piece of work because it separated the two systems, introduced an independent password and accounted for the paths required to activate and recover access. Its scope made the temporary route appear safer.
But the shortcut did not remove that work. It delayed it. The additional implementation could only have been justified if early internal access produced evidence that changed the product. User testing and direct conversations were not prioritised, and the feedback collected did not create that learning loop.
Migration 02 · Business customers
The next migration increased the operational complexity
Business migration required more than replacing the temporary login. Accounts, users, custom roles and permissions, missing data, operational profiles, security constraints and legacy dependencies all had to be understood before customers could move safely.
I structured the problem as a migration-readiness model rather than a list of interface requirements.
- Inventory accounts, users, roles, permissions and required data.
- Segment customers by migration complexity.
- Map legacy roles and permissions to the target model.
- Identify gaps, blockers, workarounds and compatibility requirements.
- Define data rules and missing-data handling.
- Plan migration waves, dual-run and transition criteria.
Despite the increased technical preparation, users were again moved before the product contained the critical functionality required for their primary work. Technical onboarding succeeded; practical adoption remained blocked.
My contribution
I connected delivery decisions to product readiness
Key activities
- Mapped temporary and target authentication flows and their dependencies.
- Raised implementation-debt and rework risks before development.
- Analysed roles, permissions, data and operational migration dependencies.
- Prepared recommendations for segmentation, migration waves and transition criteria.
- Collected and documented user feedback when access became available.
- Made the gap between technical release and usable product value visible.
My role was advisory and design-led. I prepared and communicated the analysis and recommendations, but I did not own the final rollout decisions or control whether every recommendation entered implementation.
Leadership perspective
Migration readiness is a product decision, not a release checklist
The repeated pattern exposed a decision-system problem: technical feasibility and delivery speed carried more weight than evidence about user value and operational readiness.
The central lesson was not that every recommendation must be accepted. It was that teams need an explicit mechanism for evaluating evidence, assigning decision ownership and revisiting assumptions when the expected outcomes do not appear.
For future migrations, I would establish adoption criteria before implementation: which user task must be possible, which functionality must exist, what behaviour will count as meaningful use, how feedback will enter prioritisation and who owns the decision to proceed.