Ecommerce Replatforming Questions: An Honest Conversation

Editor's Note: This post was originally published in 2018 by Aaron Orendorff and has since been updated for accuracy and readability by Conan Tobias.

“Migration,” says Paul Hodge, CEO at Laird Superfood, “is a dirty word around here. It’s costly to switch, and migrating is a major upheaval.”

Finding a reliable guide to replatforming is hard, especially if your business is growing faster than your infrastructure can keep up with.

To help you make this decision, we’ve written a detailed guide on migration and replatforming and now, we’ve decided to do something different: sit down with someone who’s had a front-row seat on high-volume ecommerce migrations.

Over the past nine years, Paul Rogers has helped hundreds of B2C and B2B businesses with their ecommerce platform migration, either in a hands-on solutions role or supporting the definition of initial requirements.

His work is predominantly cross-platform, meaning he’s supported clients in moving both to and from:

• Shopify
• Magento Commerce
• Demandware/Salesforce Commerce Cloud
• Custom systems

Rogers is a a Google Partner and a Shopify Partner through Vervaunt, his consultancy business. Some of Rogers’ recent clients include MUJI, The Science Museum, and Sony PlayStation.

What makes a business seriously consider ecommerce platforming?

With larger organizations, my first point of contact is usually an ecommerce manager or someone working in the marketing or technical team. They usually all have some pretty common reasons:

Platform end-of-life

In 2020, Magento ended support for Magento 1, forcing users to upgrade to Magento 2, a costly and time-consuming replatforming project. The risk of staying on the platform, even with an open source community creating patches, was that third parties would no longer support their plugins.

In 2021, Salesforce is now doing the same to its brands and forcing a move from its sitegenesis platform to Storefront Reference Architecture (SFRA.)

Stability and scalability

I’d say this is the other most common reason, with underlying technical issues or heavy customization affecting major releases or deployments, maintainability, upgradeability, and the stability of integrations. 

Lack of agility

Another common reason I see is merchants not being able to get new feature requirements or even backlog work delivered fast enough, coupled with too much of a reliance on integration partners. For example, let’s say a retailer wanted to begin testing subscriptions. This may take months and cost up to $20,000 on another platform, whereas on Shopify would be easy to drum up a proof of concept, and would cost barely anything.

Cost of ownership

I’ve seen retailers looking at other platforms these days due to the availability of similar offerings with a much lower ongoing cost of ownership, such as Shopify. Everyone loves SaaS platforms—they are more cost effective, transparent and agile. You can extend it, and it won’t cause problems down the line. The urge to customize is on other platforms is much bigger, which inherently costs both time and money.

Security

Quite a few retailers have made the decision to replatform after discovering a vulnerability or a breach of some form. This has often been a decision to move to a hosted, SaaS platform, largely because it removes a lot of the concerns and risks with self-hosted on-prem software or legacy systems that require a lot of support.

People trust Shopify stores—Shopify stores don’t get hacked. 

That said, replatforming projects aren’t easy and require a huge level of investment, both in terms of monetary allocation and people’s time. When you consider all of the associated costs and the people that need to be involved, a replatforming project requires a lot of justification.

What are the most common objections to replatforming?

The biggest points of failure for replatforming projects is not having stakeholder buy-in. Being able to create a strong case and get backing from key people within an organization is critical for these kinds of projects.

The other objections I often hear surround:

• Dealing with “sunk” and upfront costs
• Time investment from team members
• Confusion about the scope of the project and timelines
• Complicated setups
• Risk of losing SEO rankings

How do you create an ecommerce RFP?

James Gurd, a very experienced and well-respected ecommerce consultant, created this video series. It has some excellent tips on managing an RFP process in general, but also on getting buy-in from the right stakeholders and the importance of having a project sponsor.

From the limited experience and exposure I have in this area, the key to getting buy-in has come from putting together strong arguments for switching ecommerce platforms and being able to fully justify the project.

Talking about problems is unlikely to be enough for most businesses, so you’ll need to build a detailed case for where the return will come from and key benefits to the business.

In two relatively recent replatforming projects I’ve worked on, the project leads (who were an ecommerce manager and a head of ecommerce) did a really good job of getting buy-in from a director-level project sponsor, who was fully committed to the project and, in the case of the second, building a project steering committee who were able to support and champion the project across the business.

Again, this came from a long process of justifying the project as the best platform to sell online and presenting key benefits. I also wrote a piece that covers some suggestions in this area, and Shopify has an ecommerce RFP template that’s detailed and pleasantly objective.

Sunk costs and ongoing costs are touchy subjects. How can they be addressed?

Sunk costs—meaning, the amount of time, energy, money, etc. someone has already invested in their current ecommerce platform—is always a tricky point to approach.

As part of this, there will often be individuals who are reluctant to change, due to the time they’ve invested in the system. These are often the hardest people to convince.

The best approach I’ve seen clients succeed with is addressing this pain point and weighing it against the benefits of reduced waste and longevity.

After that, you have to address ongoing costs. This is likely to be looked at as a combination of upfront licensing fees, the cost of the initial website build, costs associated with integrations, any additional contractor or team member costs, and then possibly increased on-going costs.

Countering the upfront costs can be difficult, particularly if they’re not budgeted for. But, there’s usually a good argument for longer-term benefits if you’re improving the overall customer experience and expect to drive improvements in your ecommerce platform’s performance.

I would suggest forecasting these areas, with a special eye toward wasted budget if you’re looking to replatform at some point:

• BAU development
• Ongoing platform development
• Negative customer-facing experiences
• Ancillary costs like hosting and maintenance
• Time-to-market for new features and adding channels

I wrote a guide on my blog about calculating the total cost of ownership (TCO) which covers many of the costs that come with replatforming.

Do you have a recommended process for scoping and planning your ecommerce platform?

Nothing should ever be one-size-fits-all, but an overall process should include the following:

Scoping

Scoping a replatforming project is the most important phase, with a particular focus on the discovery, which takes place alongside (and is led by) the integration partner. The success of a project often hinges on the discovery and ensuring that all requirements are built into the project spec and stories.

Ideally, you’d provide enough detail on functional and non-functional requirements to the integration partner to give you an accurate pre-discovery quote that doesn’t leave too many time and material (T&M) areas open.

The more detailed the specifications, the less time needed to interpret the requirements in the discovery. This is not a replacement for the discovery, however, and there will almost always be some level of change.

Discover

Discovery is usually 4–25 business days (depending on the complexity of the project). Ideally, the partner would relate functional requirements back to business objectives and get more information about any pain points the business may have.

This is also where you’d go into detail around back-end processes, how different data points need to be integrated with other systems, and what customizations are required to native functionality, etc. Optimizations and requirements that hadn’t been considered previously frequently surface.

The outputs from these workshops would then be translated into either user stories or specifications and would generally include acceptance criteria to provide a point of reference for developers and for quality assurance (QA) or user acceptance testing (UAT).

Requirements

Going through your module list is usually a good place to start, as is collating requirements from key stakeholders.

You can find lots of information online around platform functionality, which can give you a base to define what’s essential—for example, scheduled publishing, page-building functionality, stacked discounts or promotions, and native product types.

Ideally, within this initial specification, you’d cover:

▢Integrations

ERP, OMS, CRM, and details on your preferred approach, the frequency of syncing, etc.

▢ Design, UX, and front-end

Cover requirements around core templates, key user journeys, mobile experience, key components, and more.

▢ Content management

If your current platform makes it difficult to update and manage content internally—themes, promotions, new products, and other visual collateral—then be sure to address that openly.

▢ Product catalog setup

Types, attributes, tagging, custom functionality, and any additional complexity

▢ Promotions and discounting

How does your company currently run major events, like back-to-school shopping and Black Friday, and how would you like to run them in the future?

▢ Customer accounts

Customer-specific content, handling of store credit and points, exposing custom information, account transfers, etc.

▢ Payments, shipping, taxes, etc.

Define the must-have payment gateways and, for both domestic and international orders, how you want customers to experience fulfillment and taxes. 

▢ Marketing requirements

SEO, tracking, GTM setup, loyalty programs, ESP, reviews and ratings, and more.

▢ Store setups

Namely, multi-brand, B2B or wholesale stores, and international stores along with the relationship and the nuances between each as well as how data and integrations should be managed.

▢ Data exports and imports

Products, customers, third-party systems, orders, etc.

These are just some of the top-level sections that I’d suggest covering, but there’d be lots of additional areas that should be defined in each section going into the project.

Lots of retailers don’t provide this level of detail and work with an agency partner to build out the initial scope, but I’ve always seen projects start better when there’s a clear, well-thought-out spec from the start that leads to more accurate time and cost estimates.

What’s a reasonable timeline for replatforming?

This is another big talking point going into a replatforming project, with the project owner usually looking to either complete the project really, really fast or wanting to prolong it for various internal reasons—although sometimes you do get retailers who are open based on the SI’s suggestions.

In terms of a reasonable timeline, this is dependent on the complexity of the project, the amount of work required on both sides, and the availability of key stakeholders and the project team on the client’s side. In my experience, it’s usually the client that slows things down.

I’d say the average time for a replatforming project has come down considerably over the last few years, from three to six months on Shopify, and six to 12 months on Magento for mid-sized projects.

But speed isn’t always a good thing (as you can easily end up compromising and losing structure), but it depends on the objectives going into the project.

A quick migration might be warranted if peak season is approaching, or other systems need to be moved (such as an OMS, WMS, and ERP).

The “perfect” time to replatform, especially when you factor in the full scope of the project, doesn’t exist.

With this in mind, I’d suggest trying to map out what the project could look like and how it could be adapted to make room for these other considerations. For example, delaying the start of the discovery by a couple of months while starting the initial planning phase and building out resource plans to get the project started. It could then be that you budget for a longer UAT phase or build periods of inactivity from your team into the plan and communicate this with the integration partner.

Any final thoughts on replatforming and migration?

A replatforming project represents an opportunity to improve core areas of your current operation and processes—allowing for optimization and development of under-performing or opportunity areas (such as merchandising, payments, production setup, catalog management, search, SEO, shipping, and any other pain points).

A lot of the replatforming projects I’ve worked on over the years have been looked at as a fresh start. Replatforming is the perfect time to address issues around anything from the overall catalog setup to the way that key integrations are handled.

Want to migrate to Shopify?

Is your platform cutting edge—or just cutting it? Read our Commerce Platform Evaluation guide to find the right ecommerce partner.

Download the guide