Alessandro Desantis

As executives at enterprise and mid-market brands increasingly turn to more modern commerce platforms for their 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:](https://nebulab.com/blog/ecommerce-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!](https://nebulab.com/contact-us) We've run countless workshops over the years and would love to help make your replatforming project a success.


Better E-Commerce Replatforms Require Better Discovery Workshops

Stefano Sarioli

For an eCommerce brand, replatforms are always exciting projects that hold a lot of promise: a replatform can come with increased flexibility, lower maintenance costs, and a better customer experience that can significantly impact your top-line growth.

However, replatforms are also incredibly stressful and can quickly become a nightmare when they’re not planned or executed appropriately: because they’re large and irreversible projects, it’s easy to miss something important and only realize it too late. Suddenly, what was supposed to be a growth driver for your business turns against you, leaving your board, team, and customers unhappy.

In this article, we will share some strategies we follow when guiding our clients through a replaform, from picking your new eCommerce platform all the way through implementation and launch. Hopefully, we can help make your next replatform a bit less scary!


## 1. Start With the Why

This one should be obvious, but you’d be surprised how many store owners cannot clearly articulate why they are executing a replatform.

A replatform project is a big undertaking from many perspectives:

* **It takes time**: replatforms will take up a lot of your team’s time and energy. In our experience, most re-platforms take anywhere between 2-5 months, depending on the complexity of your online store. Enterprise replatforms can take years!
* **It’s expensive:** replatforms are expensive projects, no matter whether you use your internal team or work with an agency. Trying to cram a replatform into a tight budget is a recipe for disaster, so make sure you can allocate the right resources.
* **It’s risky:** re-platforms are inherently risky. While most software projects can be approached incrementally, re-platforms require a big-bang transition, dramatically increasing the likelihood of something going wrong.
* **It impacts morale:** for some of your team members, the replatform will come with a steep learning curve, considerable disruptions to their existing workflows, and even fears about their career opportunities (“Will this new skillset make me less relevant?”).

With all that is at stake, you want a crystal-clear understanding of why you need to replatform: you owe it to your team, your customers, and yourself. Some of the most common scenarios in which it makes sense to do a replatform are:

* **To increase flexibility.** If your platform is consistently preventing you from executing your digital roadmap, then it’s time to look for more advanced vendor–that is, provided that your roadmap is the result of an [intentional, data-informed product management workflow.](https://nebulab.com/blog/ecommerce-product-management)
* **To support growth.** If your existing platform is having growth pains, then you might want to switch to a more scalable solution that will support your brand’s long-term plans.
* **To reduce maintenance costs.** Some platforms are more expensive than others to keep up and running. Sometimes, this is an acceptable cost to pay for certain benefits (such as additional features), and sometimes it’s a non-justifiable expense.
* **To access a larger ecosystem.** If you can’t find any partners or system integrators willing to work with your current setup, and this is preventing you from reaching your business objectives, then it might be time for a change.

There are also many _bad_ reasons to do a replatform, such as your team only having experience with a specific stack (they can learn a new technology), fear of missing out because everyone else is using a different solution (they are not you), or an investor pushing you hard to make the switch (it’s unlikely they fully understand your business needs).

We suggest writing a [Request for Comments](https://nebulab.com/blog/driving-organizational-change-with-rfcs) about the replatform. This will help you analyze your motivations and assumptions, evaluate potential alternatives, and ensure that a replatform is the right move for your eCommerce store.

RFCs have the added benefit of helping you build commitment and create alignment on the project internally–and believe us, it’s something you will need badly if you move forward.


## 2. Think Brand First, Not Vendor First

So, you wrote an RFC, you discussed it with your team, and you’re all aligned on your motivations. The next question is, how do you compare the capabilities offered by different vendors?

Nowadays, there are tens of eCommerce platforms to choose from. As in most crowded software categories, they all offer a base layer of foundational functionality and a certain number of differentiators that make them stand apart. Some of these differentiators will be useful for your specific needs, while others are just marketing stunts that will lure you in but ultimately prove irrelevant.

When approaching a replatform, we typically categorize business requirements in one of three buckets–Big Rocks, Pebbles, and Sand:

* **Big Rocks:** these are major pieces of functionality. They are highly specific to your brand promise and business model. For membership-based brands, for instance, the #1 Big Rock is their membership billing engine.
* **Pebbles:** these requirements are still important but not unique to your brand. An example would be your average ERP or 3PL integration. For most brands, there’s not a lot of innovation involved in these foundational eCommerce features.
* **Sand:** these are minor requirements that can be taken more or less for granted. Most cosmetic improvements, such as the image carousel on your PDP, fall into this category.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ee19cec17172531bd1e236882c503471ca249262-3200x2104.jpg?fit=clip)

Once you have this mapping, you can understand how the platforms you’re evaluating will solve your requirements, prioritizing each requirement depending on how it’s been categorized. Feel free to ask the vendors you’re considering for help during this phase: after all, they know their own solutions inside out. However, you should always double-check their claims, as they are bound to be biased.

Whatever you do, make sure you base your comparison on your actual requirements–not on the narrative each vendor tries to push, nor on the hype around their product. It is ultimately irrelevant how many features or apps an eCommerce solution offers if you only use a tiny fraction of them. **Technology is just a tool: your platform should fit your brand, not vice versa.**

A platform-agnostic agency is the best partner for this kind of project: they have the expertise to advise you, but they are not married to one specific solution, which gives them the freedom to offer you what they genuinely believe to be the best path forward.


## 3. Account for All the Expenses

Platform and transaction fees are a _significant_ part of any eCommerce brand’s P&L statement. When replatforming, you should clearly understand the costs you’ll incur under the new tech stack if you don’t want any unpleasant surprises.

Unfortunately, many brands jump the gun here and only account for the most apparent and immediate costs, such as their platform’s transaction fees in the first year. As a result, they neglect other variables that are not as visible but equally important, only to get burned by their new vendor once it’s too late to go back.

When approaching a re-platform, we typically categorize the costs as follows:

* **License fees:** this is how much you’ll pay your vendors for access to their services. Most brands only include the cost of their eCommerce platform here, but you should also account for any third-party apps and services you will need.
* **Transaction fees:** these are the fees you pay on your payments, and they typically have fixed and variable components. Some platforms have integrated payment gateways with lower transaction fees, while others will require you to work with a third party.
* **Maintenance fees:** we would all love to use an eCommerce platform that requires zero maintenance, but that is rarely the case. While you can’t calculate precisely how much design and development effort you’ll need with your new platform, you should make an educated guess and understand how that compares with your current setup.
* **Replatform fees:** how much will it cost to execute the replatform? Assuming that your goal is reducing engineering spend, how long will it take you to recoup that initial investment under the new platform?

When evaluating these costs, you also want to understand how they will change as your brand grows: what would they look like at 2X your current scale? Does pricing grow linearly, more than linearly, or less than linearly? Will there be room for negotiation, or are you locked into this commercial structure forever? Does the new vendor have any minimum commitments?

Every platform is unique, but do your best to make an apples-to-apples comparison that clearly outlines the total cost of ownership and any pros/cons associated with each option.

## 4. Approach the Work Incrementally

Switching over to the new platform will require a Big Bang Release, where you switch your brand to your new tech stack almost overnight. This approach is typically frowned upon in software development: the more changes you’re introducing simultaneously, the more you increase the chance that something will go wrong.

The bad news is that Big Bang Releases are somewhat unavoidable with most replatforms. The good news is that there are several approaches to minimize the amount of uncertainty associated with them. In general, if you can do something _before_ you finalize your transition to the new platform, you should.

Here are a few techniques we typically adopt:

* Work closely with your in-house team or external partner to demo and test their work as often as possible. You don’t want the team to work in isolation for three months and then do your testing in one go: you’re bound to miss something or discover significant problems once it’s too late to do anything about them. Better yet, have your entire team do QA: you’ll be surprised how much more stuff you can find as a group!
* If you need to make any changes to integrations or external systems to make them compatible with your replatform, see if you can apply them beforehand in a way compatible with both the old stack and the new one. This typically applies to ERPs, WMSs, and 3PLs, but you can generalize it to other vendors.
* Test your data migrations ahead of time and continue to execute them continuously in the days leading up to the launch. That way, on launch day, you will only need to migrate a small portion of your data rather than all of it.
* Create checklists for what you will do before, during, and after the replatform. Launch day is incredibly stressful, so it’s essential your team doesn’t have to think too much about what they’re going to do.

These are just some ideas, and your mileage may vary depending on your setup and the complexity of your architecture. The rule of thumb is that you want to work in small increments and do the bulk of the work upfront, so you only need to pull the trigger on launch day.

You can also check out [this article](https://nebulab.com/blog/ecommerce-agency-productivity) we published about how to optimize your agency’s or digital team’s productivity. All of those strategies also apply to replatform projects!

## 5. Resist the Urge to Redesign

If there is one thing you take away from this article, let it be this: do NOT do a rebrand or redesign at the same time you’re doing a replatform. After over a decade of working with eCommerce brands of all sizes, we have witnessed so many failed attempts at this that we strongly discourage this practice.

There are several reasons why a redesign might be bundled together with a replaform. In our experience, it’s usually a combination of the following factors:

1. Most brand executives are visual people. During a replatform, they get understandably excited and come up with a million potential improvements to the customer experience, which often turn into a full-blown redesign.
2. The byproduct of #1 is that, in larger companies, the person sponsoring the replatform often feels the need to justify the investment to their boss through a tangible artifact, such as a rebrand/redesign. This gives them a clear “thing” to point to when someone asks them where all that money went.
3. Unfortunately, some eCommerce agencies do redesigns along with replatforms to increase the scope of the engagement, and so that the final result can be more easily turned into a compelling case study.

As we already mentioned, this is almost always a bad idea. Replatforms are complicated and risky, so you want to keep their scope as small and controlled as possible. Redesigning your website while uprooting its tech stack dramatically increases the risk of something going wrong during or after the launch. It also makes it much harder to isolate and measure the business impact of specific changes to the customer experience.

We suggest keeping the new website as similar as possible to what you had before. After you launch the replatform, you’ll have plenty of time to fully leverage the capabilities of your new tech stack, so there’s no reason to rush it.

## 6. Prioritize the Scary Stuff

Remember that Big Rocks, Pebble, Sand categorization we talked about earlier? That’s not just a way to map your business requirements, but it’s also an excellent mental model to keep in mind when prioritizing the different features involved in your replatform:

1. Big Rocks are the most critical problems to solve and carry the highest risk and uncertainty, so you want to get them out of the way as early as possible.
2. Pebbles are essential but less risky–you want to get them done and tested early, but not before you’re done with the Big Rocks.
3. Sand is irrelevant: while some of these features are important to your business, they’re also quick and easy to implement and can be left for last.

Unfortunately, we often see things being approached in the opposite order. Because it’s easier and faster to make progress on Sand than on Big Rocks, they focus on the lowest-hanging fruit while neglecting the big, scary problems screaming at them.

One brand we spoke with in the past, which was heavily subscription-based, reached the last week of their replatform without having done any work on their subscription engine yet. When they finally focused on it, they realized the provider they had picked wouldn’t be able to accommodate their needs, and they had to cancel the launch and go back to the drawing board.

To keep your team focused, it can be helpful to appoint a Product Owner/Project Lead. This person, who ideally has project management experience and understands your brand inside out, will be responsible for keeping track of the project’s progress and ensuring the team is prioritizing the work correctly.

One last word of warning here: remember that perfect is the enemy of good. Just like with the redesign, you’ll have plenty of time to improve your online store after the launch, so don’t get bogged down in pursuing tiny optimizations at the expense of bigger achievements.

## Launch and Celebrate!

If you follow the tips above, launch day should be much less stressful than it could have been. Just follow your checklists on launch day, sit back, and celebrate!

Besides that, now is the time you can fully unleash the true power of your new eCommerce stack. As always, make sure to move intentionally and be data-informed–[establishing a lightweight Product Management practice](https://nebulab.com/blog/ecommerce-product-management) can do wonders in ensuring you’re not getting ahead of yourself, but working on features that will actually move the needle.

We hope we managed to shed some light on what is typically a long and confusing process for any brands that go through it!

If you need additional help with your replatform, [don’t hesitate to reach out!](https://nebulab.com/contact-us) Our team works with a variety of eCommerce platforms. They would be more than happy to advise you on the best choice for your brand and guide you through the entire implementation and launch process.

The Nebulab

Better E-Commerce Replatforms Require Better Discovery Workshops

How To Nail Your eCommerce Replatform