Reading time: 5-6 minutes.
Welcome to your guide to understanding the basics of ecommerce replatforming. Our starting point is to ensure you understand the language used by ecommerce professionals.
There are different phrases used to describe the same thing:
Some confuse this with the phrase ‘ecommerce rfp’. They’re related but not the same thing. A ‘RFP’ is a ‘Request for Proposal’, the process of asking external suppliers to submit a proposal and pitch for your business.
In the context of ecommerce, a RFP can be used for any service or technology selection. For replatforming, it’s an integral part of the process and happens once the business has a clear definition of project scope and budget, business requirements and technical principles. The RFP is a component part of the overall replatforming process, not the process itself.
Let’s define the key terminology:
|Ecommerce platform||An application that provides core ecommerce functionality e.g. online shopping basket and checkout.|
|CMS||Content Management System; technology that enables ecommerce teams to create, edit, manage & publish content to a website e.g. landing page banners.|
|ERP||Enterprise Resource Planning; enterprise application that enables the business to handle complex data and process flows to automate back-office functions related to like product planning, reporting & financial reconciliation.|
|OMS||Order Management System; application that enables the business to control the logic for how different order types are handled and the flow of information to and from the ecommerce application into other enterprise systems like the ERP.|
|WMS||Warehouse Management System; enterprise application that handles shipping and distribution logic to control how orders placed online get fulfilled to the end customer, passing order updates back to systems like the OMS e.g. order tracking.|
|COTS||Commercial Off The Shelf ecommerce package; a solution that is made available for other organisations to use when they pay a license fee.|
|Vendor||The owner of a COTS package e.g. SAP Hybris, Salesforce and Magento.|
|PaaS||Platform As A Service; a cloud computing model in which a third-party provider delivers hardware and software tools to users over the internet. The PaaS provider hosts the hardware and software on its own infrastructure e.g. Shopify.|
|SI||Systems Integrator; a technology services company that is qualified to build a website using a COTS ecommerce package and, if required, provide ongoing support & maintenance.|
|Fully managed||An ecommerce package where the application, application support and hosting are provided by a 3rd party e.g. Episerver.|
|On-premise||An ecommerce package where the implementation is done within your own organisation and not in the cloud. In this scenario typically your team will be responsible for managing hardware, application support, upgrades, patches etc.|
|Hosted||An ecommerce package where the implementation is done within a secure 3rd party hosting environment e.g. Rackspace. In this scenario you retain ownership of the hardware but typically outsource application support, upgrades, patches etc. to the hosting provider.|
|Cloud solution||The vendor hosts the database in their own data centre. and is responsible for managing the hardware, the database and the application updates. You have no access to the physical database or raw data.|
|Single tenant||This is a cloud solution where each customer is installed on a single database. This means you don’t share any databases with other customers.|
|Multi tenant||Many cloud solutions manage multiple customers on a single database, referred to as a ‘multi-tenant’ solution. They use partitioning to ensure data privacy and security. The benefit of this approach for the vendor is scalability since upgrades to the database only have to be performed once and not to multiple instances for each customer. |
Multi-tenant is typically lower cost than single tenant as it’s shared infrastructure, so set-up and maintenance is cheaper for the vendor.
|API||Application Progamming Interface; a set of clearly defined methods of communication among various components of a system, providing building blocks to enable you to access ecommerce application functions without requiring a hard coded integration e.g. adding an ‘add to basket’ button into blog pages hosted on a 3rd party CMS like Wordpress.|
|Micro services||A software development technique that structures an application as a collection of loosely coupled services. This provides modularity, enabling other systems to ‘consume’ all or only part of a service as required e.g. in-store digital kiosk uses the Ratings & Reviews micro service to access only product star ratings to display in store, but doesn't access the review content.|
|Headless||Headless ecommerce is where ecommerce services are provided by the ecommerce application but the presentation layer is delivered by a separate system e.g. CMS. Ecommerce platforms that expose application functionality via APIs and services can be used in a headless set-up. Headless enables front-end developers to present content using any framework they like.|
Now that’s sorted, let’s move on…
Ecommerce replatforming is the process of selecting new technology to deliver the ecommerce functionality for your organisation. For some this requires the implementation of a 3rd party COTS package to replace an existing one, for others it means migrating from an in-house bespoke solution to a 3rd party vendor and changing the operational model.
The extent of a replatforming project depends on your existing systems architecture and future growth plans.
The principles of replatforming are the same for every organisation but the scope and complexity of the project can vary significantly.
For example, a simple ecommerce project where an organization wants to use a fully managed cloud SaaS solution like Shopify and use an existing theme, doesn’t customise or integrate multiple 3rd party apps and has very simple back office integration, can take anywhere between 8 to 12 weeks.
However, for a larger enterprise with complex integrations and bespoke business processes that require a platform to be extend and/or customised, implementation will take at least 6 months (some take longer than 1 year).
This can often be the most confusing part of replatforming. There are lots of different vendor models out there. I’ve focused on the most used models to help simplify the landscape.
I highly recommend following Gartner’s quarterly Magic Quadrant for Digital Commerce report. If you’re an SME and your budget precludes a Gartner subscription, search online for one of the free reprints from a vendor like Episerver or Elastic Path. It won’t give you the full report but you’ll get a good enough summary to help point the way.
I cover how to select an ecommerce platform vendor in the guide, “How to select the best ecommerce platform vendor” (coming soon).
Use the tabs to learn what each of the principle ecommerce platform models are:
This is extremely costly and resource hungry, and increasingly rare. For most organisations it doesn’t make sense to replicate what is already available through existing vendors.
There are multiple scenarios in which it may be practical and necessary to invest in a new ecommerce platform. Below are the most common reasons.
Your current platform…
* I cover what a TCO is in the article “How to build a realistic replatforming TCO cost model”.
There are scenarios where the current platform is a good fit for the business, provides all the functionality stakeholders needs, but isn’t performing well or justifying your investment.
It is complex and costly to migrate between platforms, so you have to be certain the platform is the issue, not the implementation or how your business makes use of it.
I’ve worked on projects where the platform didn’t need changing; it just needed better implementation and configuration. Others where the SI partner, even if they’re well intentioned and working hard, doesn’t have the technical skills or resource to service the client adequately. Migrating to an alternative platform is the wrong decision (see below for a few reasons why), but switching to a more capable SI partner is the better solution.
Reasons why replatforming is the wrong decision if the platform is fit-for-purpose:
You should now have a clear understanding of what ecommerce replatforming is, and your options for selecting an ecommerce platform.
Your key take-aways.
Learn more about enterprise ecommerce replatforming by reading my other guides:
If you have any questions, please contact me using the online form, by LinkedIn or Twitter.
Free 10-part video series on ecommerce replatforming. Watch the introduction to learn why your ecommerce teams should put the right level of detail, effort and investment into project planning.
Just a quick intro to set the scene, there are six key reasons why I think it’s important that businesses put the right time, and effort, and resource into these projects to get the right output. So first of all, platform investment is a major investment for business. Whether you’re a small business starting out on your ecommerce journey or an existing £100 million plus retailer, there’s a lot of money spent investing in the platform, not just the technology, but all of the operational requirements that go around implementing a new platform. So it’s critical to get value for money.
Secondly, the platform has to support your operational needs. That means it needs to align with business strategy, goals, business processes and internal capabilities. Therefore, you have to sit and think about which technology platform solution is going to best align with your business.
Third, the project’s got to be affordable, so that doesn’t just mean upfront costs of development, and then the basic support maintenance. It means what happens to your OpEx and CapEx costs over the lifetime of that platform, three to five years down the line, as you grow. How do those costs scale? How affordable is it? What percentage of your overall revenue is the platform going to cost?
Fourth, there is risk. Whenever there is technology and people, there is risk. Therefore, you need to understand what those risks are, carefully define them and put a mitigation plan in place to do that. That requires close attention, and someone who is experienced in risk management.
Fifth, it’s an incredibly complex project. Ecommerce platforms have huge amounts of capability in them, and how each platform does each capability varies considerably. Good example is catalogue management and the way that product data is taken from back end systems and put into product master, how product data be configured, and how flexible the solutions are in terms of allowing you to put the data in how you want to do it, and configure the project in a way that’s best for your market and your customers.
Therefore, with this level of complexity, it’s critical to have very smart project management in order to ensure the project is scoped, properly defined, and that throughout the project, the project management is adhered to and that the scope is borne in mind when decisions are made in terms of prioritisation.
Last, by no means least, failing to put the right resource, team structure and investment upfront is actually a false economy. If you don’t put the right time and effort now, you can actually compromise project decisions and end up spending a lot of money later on rectifying poor decision making.
A great example is technical SEO; not making smart decisions for information architecture now can cost a lot of money retrospectively to fix.
So those are the six key reasons why your business needs to take this type of project seriously. I hope that you find my video series interesting. It walks you through all of the elements of running a successful RFP, from going to market to look at vendors after defining your business requirements, through to project management, SI partner selection and ongoing due diligence.
I’ve got a lovely Blue Peter style contact card, so if anybody has any questions, then please do get in touch. I’d love to hear from you and be happy to help.