Platform Migrations and the $100M Question: Why Understanding Before Designing Saves Everything
How technical capability assessment prevents expensive misalignments and wasted design work
You’re replacing a legacy platform that poses significant revenue risk. The current system is old, poorly supported, and could break at any time. Leadership prioritizes the migration, allocates budget, and asks design to envision the future experience.
So your team starts designing. Beautiful mockups emerge showing streamlined workflows, personalized features, and modern interactions. Stakeholders approve. Developers begin implementation.
Then you discover the new platform doesn’t support half of what you designed.
The Expensive Discovery
This failure pattern appears across organizations with depressing frequency. Teams select vendors or platforms based on feature checklists and pricing, then hand the project to design, who create experiences based on user needs rather than platform constraints. By the time technical limitations surface, substantial design work is sunk cost, stakeholder expectations are set, and the organization faces an uncomfortable choice: compromise the experience or invest heavily in customization.
One organization faced exactly this scenario. Their legacy e-commerce platform served a specific customer segment, but technical risks made replacement urgent. Leadership estimated a $100M revenue exposure if the system failed. The replacement project became a priority.
But before design work began, critical questions remained unanswered: Can developers make changes directly to the new platform, or does every modification require vendor involvement? What’s the cost of customization? Can core experience flows be adapted to specific business requirements, or is the platform opinionated about how things must work?
Without these answers, any design work would be speculative at best, wasteful at worst.
The Build vs. Buy Misalignment
The challenge intensifies when vendor solutions don’t align with organizational capabilities.
Third-party platforms often target traditional use cases—standard e-commerce journeys, typical enterprise workflows, common B2B patterns. Organizations with unique requirements find themselves trying to force-fit specialized needs into generic solutions.
One team evaluated a vendor for enterprise fleet management. The vendor positioned themselves as growing in the market—motivated but not established. Their solution appeared built for traditional e-commerce rather than the complex corporate buying workflows the organization needed: device lifecycle management, volume ordering, inventory tracking across locations.
The vendor offered extensive features for SKU management, demand forecasting, and inventory optimization. Impressive capabilities, but likely never to be used given the organization’s actual operational model. Meanwhile, the corporate-specific workflows would require heavy customization, raising questions about whether the vendor’s future platform versions would support those customizations or require expensive re-implementation.
This is the classic misalignment: buying a solution optimized for problems you don’t have while lacking support for problems you do.
The Data Lock-In Factor
Beyond feature fit, architectural decisions create long-term consequences.
When you build workflows and data structures within a vendor’s platform, extraction becomes difficult. If the relationship sours, if the vendor’s roadmap diverges from your needs, if pricing becomes untenable—switching costs escalate dramatically because your data and business logic live in proprietary systems.
Teams experienced with vendor relationships understand this risk viscerally. One described it as risking “repeating the situation where a tool was bought for one purpose but forced to fit another.” The original purchase decision made sense given limited information, but as requirements evolved and platform limitations surfaced, the organization found itself constrained by past choices.
The prevention strategy is architectural clarity: understand the data model, evaluate export capabilities, assess how much business logic will live in the platform versus your own systems. Make these assessments before design work begins, because they constrain what experiences are even possible.
The Design Involvement Question
This raises an organizational challenge: when should design assess vendor capabilities?
Traditionally, business analysts drive vendor selection. They create requirements matrices, evaluate feature coverage, negotiate pricing, and make recommendations. Experience design gets involved after the purchase, translating platform capabilities into user-facing interfaces.
But this sequence creates the misalignment. Business analysts focus on feature lists and business requirements. Interaction patterns, user experience constraints, and workflow feasibility often get evaluated superficially or not at all.
Several organizations have recognized this gap and adjusted their process. Design gets involved earlier—not to make purchase decisions, but to assess experiential feasibility. The approach: create a prototype showing the desired experience, then ask vendors how their platform would support that specific flow.
This inverts the typical demonstration. Instead of watching vendors showcase their platform’s capabilities and trying to imagine how those features might address your needs, you show vendors your needs and evaluate how naturally their platform accommodates them.
The method is expensive and time-consuming, so it requires judgment about when to apply it. For low-risk purchases or minor tools, the traditional feature-checklist approach suffices. For major initiatives—platforms that will support critical workflows for years, migrations that carry significant business risk, or systems that will require substantial customization—the upfront design investment prevents expensive misalignments.
The Phased Rollout Reality
Even with perfect vendor alignment, implementation timing creates design challenges.
Enterprise platforms rarely deliver full functionality immediately. Vendors present roadmaps showing impressive capabilities: enhanced notifications, advanced APIs, predictive analytics, seamless integrations. Leadership gets excited about future possibilities.
But Phase 1 delivers a subset. Maybe 40% of the promised functionality, focused on core workflows. Phase 2 comes six months later with incremental additions. Phase 3 is “on the roadmap” with no firm date.
This creates a design paradox: do you design for the complete future vision, knowing current implementation will fall short? Or design for current capabilities, accepting that users will experience a limited system that requires future redesign?
Neither option is good. Designing beyond current capabilities sets expectations you can’t meet and creates detailed specifications for features that may never arrive or arrive differently than promised. Designing only for current state means users experience an incomplete system, and your design work gets redone multiple times as capabilities expand.
The resolution requires partnership between design, product, and technical leadership. Design articulates the minimum viable experience—what capabilities must be present for users to accomplish their goals, even if imperfectly. Product negotiates with vendors to ensure Phase 1 includes that foundation. Technical architecture ensures customizations can bridge gaps without creating unsupportable technical debt.
Then the team sequences the rollout, each phase delivering incrementally better experiences without requiring full redesign. This is experience roadmapping, not just feature planning.
The Conversion Question
For revenue-critical platforms, adoption metrics matter enormously.
One organization discovered that 75% of registered business customers had never placed an order. The current platform was so difficult to use that customers created accounts but abandoned the actual purchasing process. The business impact was substantial—potential revenue lost because the experience failed.
This context transforms the platform migration from a risk-mitigation project into a growth opportunity. A better experience doesn’t just maintain current revenue—it unlocks latent demand. Customers who want to buy but can’t navigate the current system will convert when the experience improves.
But realizing that value requires understanding platform capabilities deeply. Can you optimize search for business-specific queries? Can checkout accommodate purchase orders and multi-approval workflows? Can the experience adapt to different customer segments with varying needs?
These aren’t cosmetic questions—they determine whether the new platform actually solves the conversion problem or just replaces one set of limitations with another.
The Right Sequence
If you’re leading product or design for a major platform initiative, the sequence matters:
Understand capabilities before designing. Invest time in technical discovery. What can the platform do natively? What requires customization? What’s impossible or prohibitively expensive? Get concrete answers, not vendor handwaving.
Prototype the critical workflows. Identify the 3-5 user journeys that matter most for your business. Sketch how they should work. Validate that the platform can support them before committing to detailed design.
Assess data architecture. Where will data live? How easily can you extract it? What business logic will be platform-dependent versus portable? These answers affect both current design decisions and future flexibility.
Phase deliberately. Resist the temptation to design the complete future vision immediately. Sequence capability delivery so each phase improves user experience measurably without requiring later redesign.
Test early. If the current experience has poor conversion or high abandonment, test early prototypes of the new platform with real users. Validate that your design actually improves outcomes rather than just looking better.
The Organizational Muscle
The best product organizations treat this as a repeatable capability, not a one-time exercise.
They’ve established clear criteria for when design involvement in vendor evaluation is worth the cost. They’ve created lightweight processes for prototyping desired experiences and validating platform fit. They’ve built relationships between design and technical architecture so capability assessments happen collaboratively.
Most importantly, they’ve normalized saying “we need to understand the platform better before designing” without that being interpreted as design moving slowly. The understanding is design work—just front-loaded to prevent waste later.
The Alternative
The alternative is expensive.
Designers create beautiful experiences the platform can’t support. Developers build workarounds that create technical debt. Users get launched experiences that frustrate them. Leadership questions why the expensive new platform doesn’t solve the problems it was meant to address.
And eventually, you find yourself evaluating another replacement, having learned the same lesson again.
Understand the platform. Then design the experience. The sequence matters more than you think.