As executives at enterprise and mid-market brands increasingly turn to Shopify for its flexibility and ecosystem advantages, the stakes have never been higher. A failed replatform doesn't just mean cost overruns—it means lost revenue, damaged team morale, and potentially catastrophic business disruption.
The solution isn't more sophisticated technology or larger budgets. It's a disciplined approach to discovery that surfaces what truly matters before a single line of code is written.
Why Most Agencies Get Discovery Wrong (And Why That's Expensive)
Here's the uncomfortable truth: most agencies treat discovery as a checkbox exercise. They'll send a brief questionnaire, schedule a few calls, and call it done. The reason is simple—thorough discovery doesn't scale. It requires senior talent, takes weeks to execute properly, and can't be easily templated across clients.
But this shortcuts approach creates predictable problems:
- Misaligned stakeholders discover fundamental disagreements three sprints into development.
- Hidden technical debt surfaces when legacy systems refuse to integrate cleanly.
- Scope creep becomes inevitable when requirements weren't properly captured upfront.
The financial impact is severe. We've seen brands burn through millions (yes, really) in development costs before realizing their initial assumptions were wrong. One client came to us after three failed projects in which different agencies had attempted to migrate the brand's custom subscription model to Shopify—failures that could have been prevented with a proper discovery process.
The Executive Case for Deep Discovery
Consider discovery an insurance policy for your replatforming investment. A properly executed discovery workshop costs 5-10% of your total project budget but can prevent 50-80% of the risk factors that typically derail implementations:
- Risk mitigation is the primary value proposition. Discovery workshops identify integration challenges, stakeholder misalignments, and technical constraints before they become expensive problems.
- Accelerated time-to-market follows naturally. Teams aligned on clear requirements move faster than teams constantly having to change course.
- Improved team dynamics emerge from collaborative planning. Discovery workshops reveal communication patterns, decision-making processes, and internal politics that will impact your project's success.
Nebulab's Discovery Framework: A Five-Phase Approach
Our discovery process has evolved through countless replatforming projects over the years. It's designed to surface critical information and design an implementation plan that minimizes risk and maximizes alignment.
Phase 1: Stakeholder Alignment and Baseline Setting
Before any workshop begins, we identify the right participants. This isn't about including everyone—it's about including the right people. We need at least one representative from each department that will either execute the replatform or be impacted by its results.
The stakeholder selection process matters more than most teams realize. Include too few people, and you'll miss critical requirements. Include too many, and the workshop becomes unwieldy. We typically aim for 6-8 participants maximum.
Each stakeholder receives a comprehensive questionnaire covering their role, current systems, performance metrics, and concerns. The survey is tailored to uncover the specific information we'll need for productive workshop discussions.
The questionnaire serves two purposes: it gives us baseline context and starts stakeholders thinking strategically about the project. When people arrive at the workshop, they're already mentally prepared for deeper discussions.
Phase 2: Envisioning Success and Failure
Every workshop begins with alignment on what we discovered during stakeholder interviews. We present our findings and ask: "Does this accurately reflect your situation?"
If everyone agrees, we proceed. If there's disagreement, we've identified a critical issue. Internal misalignment often masquerades as technical complexity. Better to surface and resolve these conflicts in week one than discover them in month six.
Our first collaborative exercise involves envisioning success. Each stakeholder writes down what their ideal end state looks like—not just technical specifications, but business outcomes. Fast-forward to six months post-launch: what does success look like for your specific role and responsibilities?
The counterpoint exercise, a Pre-Mortem, follows immediately: if everything goes horribly wrong, why did it fail? This approach consistently surfaces risks that wouldn't emerge through traditional requirements gathering.
These exercises reveal stakeholder priorities and potential conflicts. When the marketing director envisions "flexible campaign landing pages" but the IT director fears "maintaining custom functionality," we know there's a conversation to be had.
Phase 3: Architectural and User Journey Mapping
Understanding your current state is prerequisite to designing your future state. We map your existing technical architecture, focusing on data flow and system integration. We answer questions such as:
- What are the third-party systems you integrate with?
- How do inventory updates flow between those systems?
- What happens when a customer initiates a return?
We then conduct a user journey mapping exercise, giving equal dignity to both customers and internal users. Your operations team, customer service representatives, and marketing coordinators all have their own user journeys, with their own points of friction that impact business performance. A replatform that optimizes for end-customer experience while creating (or failing to address!) friction for internal users is a failed replatform.
The architectural and journey mapping exercises run in parallel, with insights from one informing the other. Technical limitations often explain customer experience friction, while user behavior patterns reveal why certain integrations are critical or what integrations are missing that would facilitate the user's life.
Phase 4: Solutioning
In the fourth part of the workshop, we move into solutioning, where we design the new reality.
In doing this, we typically aim to be very conservative with the consumer's user journey: unless there's compelling business justification for dramatic change, the post-replatform consumer UX should closely mirror the existing one. This might seem counterintuitive: after all, isn't the whole point of the replatform to improve the user experience?
While the answer is yes, that doesn't mean you should do it immediately. Postponing the UX improvements reduces development complexity, contains implementation costs, and minimizes the risk of alienating your users with a completely new UX. We've discussed this (somewhat counterintuitive) approach at length in our article about replatforms: time and time again, we've seen a more conservative approach outperform big-bang replatforms.
Architectural changes, however, can and should be more transformative: during this phase, we redesign your e-commerce infrastructure to support your business objectives and enable future evolution. This means dropping legacy tools, improving how you use them, or adopting new ones, with the two-fold goal of streaminling your internal operations and enabling future evolution for your consumer UX.
Phase 5: Launch Strategy and Risk Mitigation
In the fifth and final stage, we have a good understanding of where you are and where you want to be. All that's left to figure out is how to get there.
To do that, we design your launch strategy, and we do it based on your scale and risk tolerance. While smaller brands might opt for a coordinated launch across all channels and markets, enterprise clients typically require phased rollouts, beta testing with select customer segments, or market-by-market deployment.
The launch strategy is usually a mix of business considerations (e.g., will team members have to operate two systems until we're fully switched over?) and technical considerations (e.g., how are we going to keep data in sync between different systems during the interregnum?).
We also go deep on risk mitigation: what can go wrong at different stages of the project, how are we going to minimize that risk, and what is our recovery process for the worst-case scenario?
This phase concludes the workshop and produces your implementation roadmap, complete with timeline, resource requirements, and risk mitigation strategies.
What Discovery Workshops Do (And What They Don't)
As you have seen, discovery workshops have several benefits:
- They set the stage for a successful replatform. Clear requirements, aligned stakeholders, and realistic timelines create conditions for successful partnerships, preventing friction and second-guessing.
- They generate returns that extend far beyond replatforming projects. The architectural diagrams, user journey maps, and stakeholder alignment achieved during discovery become valuable assets for future initiatives.
- They improve your internal communication and decision-making processes. The skills and frameworks learned during discovery transfer to other strategic projects.
However, a discovery workshop is not a panacea! No matter how thorough your workshop, you will never be able to capture your full spectrum of requirements, and you will still be left with unanswered questions. That's alright: the purpose of the workshop is not to eliminate uncertainty, but rather to identify the areas of biggest uncertainty so that you can adress them head-on during the project rather than pretend they don't exist.
If you're looking to replatform and could use some help running a discovery workshop, reach out! We've run countless workshops over the years and would love to help make your replatforming project a success.
