“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.”
Of course, you already know that. You also know that finding a reliable guide to replatforming is hard. Especially at the large-to-enterprise level.
Why? Because most content on replatforming is produced by people like us: ecommerce platforms looking for your business.
That’s why, to coincide with the launch of our most-detailed guide on migration and replatforming, we decided to do something different …
Over the last 8 years, Paul Rogers has been involved in 20+ B2C and B2B ecommerce replatforms, either in a hands-on solutions role or supporting the definition of initial requirements.
His work is predominately cross-platform, meaning he’s supported clients in moving both to and from:
- Magento Commerce
- Bespoken systems
- Demandware (Salesforce)
- Shopify Plus
Rogers is currently a Magento 1 and Magento 2 Solution Specialist, a Google Partner, as well as a Shopify Plus Partner through Vervaunt, his consultancy business. Some of Paul’s recent clients include The V&A, Sony PlayStation, Waterford, O’Neills, Trotters Childrenswear, Dr. Martens, Beyond Retro, and various others.
Given his front-row seat on high-volume ecommerce migrations, I sat down with Rogers to ask some pointed questions about the dirtiest word in ecommerce.
Editor’s note on the Q&A:
The following answers have all been supplied directly from Paul Rogers. We have removed quote marks simply to eliminate repetitious punctuation. While Rogers is a Shopify Plus Partner, this post should not be read as a wholesale endorsement of Shopify Plus to the exclusion of the other platforms he works on.
What makes a business seriously consider replatforming?
I’m just going to assume that anyone who found this page is already considering replatforming. With larger organizations, my first point of contact is usually an Ecommerce Manager or someone working in the marketing or technical team.
There are generally some pretty common reasons:
Magento 1.x is the obvious example, which has caused a lot of people to at least consider their options. The other big ones that have been relevant to me over the last few years are Venda and BT Fresca.
Stability and scalability
I’d say this is the other most common reason with the projects I’ve been involved in — 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.
Cost of ownership
I’ve seen retailers looking at other platforms due to similar offerings being available these days with a much lower on-going cost of ownership, with Shopify Plus representing one of these options.
Quite a few retailers who 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 in this area.
That being said, replatforming projects aren’t easy and they 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
- Scoping and planning at the outset
- Creating reasonable timelines
- Addressing complicated set-ups
How do you build consensus and get stakeholder buy-in?
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 in 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 and being able to fully justify the project.
Talking about problems is unlikely to be enough for most businesses and 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 and presenting key benefits. I also wrote this piece which covers some suggestions in this area and Shopify Plus has an ecommerce RFP template that’s detailed and pleasantly objective (instead of being a sales pitch):
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 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 calling this expenditure out and using it within an argument to move to the new system, assuming there’s a benefit around 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 performance.
I would suggest forecasting these areas, with a special eye towards 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 this guide to calculating the total cost of ownership (TCO) on my blog, which covers a lot of the costs that need to be factored in when replatforming.
Do you have a recommended process for scoping and planning?
Nothing should ever be one-size-fits-all, but an overall process should include …
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 specification, the less time will be needed to interpret the requirements in the discovery, but this is not a replacement for the discovery and there’ll almost always be some level of change.
Discovery is usually anywhere from 4-25 business days (depending on the complexity of the project) and the partner would ideally relate functional requirements back to business objectives and extract more information about pain points and underlying reasonings via these workshops.
This is also where you’d go into the details 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 QA/UAT.
Initial requirements could be a blog post in itself. Going through your module list is usually a good place to start, as well as collating requirements from key stakeholders.
You can also find lots of information around platform functionality online, which can give you a base to define what’s essential — for example, scheduled publishing, page building functionality, stacked discounts or promotions, native product types, etc.
Ideally, within this initial specification, you’d cover:
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, visual collateral, etc. — 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 to 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 SI 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 also allows for a more accurate time and cost estimate.
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 as well as a project team on the client’s side. It’s usually the client that slows things down in my experience.
I’d say the average time for a replatforming project has come down considerably over the last few years — going from ~12 months to ~6 months for a mid-sized project.
I’ve worked on a couple of large Shopify Plus projects that have been delivered in under four months and some high profile Magento and Shopify Plus projects have been completed in under three months recently. I’d say this 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.
Going into a peak season, moving other systems (such as OMS, WMS, ERP, etc), have a new season launch coming up, or are making any other business changes are all valid arguments.
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 allow 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 allow 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 and an opportunity to address issues around anything from taxonomies or the overall catalog setup to the way that key integrations are handled and what’s been ported between systems.
Despite the work involved, this fresh start regularly ends up being a delightful surprise.
Interested in what migrating to Shopify Plus looks like?
We’ve just released our most-detailed guide to ecommerce migration and replatforming ever … be warned: this behind-the-scenes and hands-on look isn’t for the faint of heart.
Instead of a surface-level sales pitch, it includes everything you need to know about large-to-enterprise migration.