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

How To Nail Your eCommerce Replatform