I originally wrote this guide in 2015 and have then updated it a number of times since then, as the platform options and capabilities have changed. I last updated this piece in August 2020. You can jump to the different sections via the links below.

The question of what eCommerce platform to use (or migrate to) is always a really tough decision for any business to make, even moreso at the enterprise end of the market (where you have a lot more budget at stake, more stakeholders involved etc). Enterprise eCommerce solutions don’t come cheap and they require a huge amount of time (and a lot of people) to implement, run and maintain. This is why it’s fundamentally important that you remain highly organised and systematic in your research and decision-making process, as selecting the wrong platform can have a huge impact on your business (both short-term and long-term).

The process of selecting a platform should also be a group effort – it’s important not to just leave this task to your tech and eCommerce trading teams; everyone, from marketing to operations to customer services should weigh in as it’s a business-level decision. In a lot of cases, it’s necessary to bring in consultants from outside the organization so you can get objective feedback on what your company needs – just to ensure the process the structured well, the right considerations are factored in, the right technologies are looked at etc. I also think, in today’s market, there are a huge number of variables that it’s really hard to fully understand when you’re not working in this area day in day out.

From a really top-level, some key considerations that need to be looked at when selecting a platform are:

  • eCommerce Pricing / Licensing Model – I’ll talk more about this later on, but this is essentially the way that the license costs are calculated and billed.
  • Technical orientation – the fit of the platform from a technical perspective (e.g. if a non-technical brand team, may be better suited to a SaaS platform instead of an API-first, headless-only platform).
  • Business orientation – this is a big one, with the objectives of businesses often aligning well to different platforms. E.g. a platform like Shopify Plus offering benefits around agility or a platform like Magento Commerce offering very strong native B2B functionality). DTC brands, for example, would often prioritise agility over extensibility.
  • Platform eco-system – the technology partner and agency partner eco-system is a critical consideration for an eCommerce platform, with the agency partner often of near-equal importance as the platform itself (depending on the platform and the approach). The same can apply to the technology eco-system, helping to support agility and time-to-market for new features etc.
  • Native feature-set – aspects such as multi-store architecture or PIM capabilities can be critical for certain types of businesses (with specific goals), so this is a really key area. I’m a big fan of creating a really detailed functional specification and really understanding how some of the key areas align with requirements.
  • Extensibility – ability to grow with and extend the platform. This is often a key area and can be critical for users looking to really expand their eCommerce operations or offering. Nowadays, things like having the right APIs to introduce additional channels or move to a headless approach can be very important.

Also, resist the urge to look at different solutions right away. Before considering what your options are, you must first do internal research and figure out your specific functional and non-functional requirements, across the business – considering both short-term and long-term (e.g. allowing for new channels, internationalisation, omnichannel integrations etc). Attempting to review different platforms without a clear understanding of what you need is where projects often start to go wrong – with stakeholders just selecting a platform based on a sales process alone. It’s important to gather your requirements and build out objectives initially, with a view to then looking at how each platform matches them and allows the business to grow and scale, in-line with the objectives.

The below information and platform detail is designed to help with this process – if you have any questions around any of it, please feel free to email me ([email protected]).

eCommerce Platform Requirements Gathering

As touched on above, fully understanding your requirements is fundamentally important and it’s key that this is done way in advance of selecting the platform / defining the technology stack. Before you start looking at individual platforms. Here are some of the key questions that need to be asked to each department:

  • What are the main business objectives behind the re-platforming project (e.g. reduce cost, support growth in specific areas / improve scalability, become more agile, generally modernise technology, eliminate vendor lock-in)? What are the key channels?
  • What are the key restrictions / bottlenecks in the current eCommerce platform (e.g. time overheads, technical restrictions, inability to scale in certain areas)?
  • What are the critical existing features that your department needs (e.g. key integrations, PIM / catalog management requirements, support for advanced product configuration (e.g. bundling or builders), native subscriptions with open APIs, multi-store architecture, core merchandising features, page building functionality etc)?
  • What are the nice to have existing features that your department needs (e.g. advanced native search, native personalisation features, APIs to support headless, advanced reporting, built-in POS, endless aisle capabilities, built-in order management capabilities etc)?
  • What are the key systems integrations required for launch (e.g. ERP, WMS, POS, CRM etc)? How do these need to be integrated?
  • What are the future systems integrations required for phase two (PIM, OMS, iPaaS for integration etc)?
  • What are the key operational requirements (e.g. inventory management, returns, customer service functionality etc)?

A number of these areas could well be powered by third parties, but this still needs to be factored in to fully understand the overall setup, the total cost of ownership and the day-to-day of different team members. These are just a few examples – there’ll be a huge amount of areas that you should probably look at, spanning across the following:

  • Integrations – what these integrations look like, key systems, key line items and nuances, the frequency of data transfer and how this is managed, the preferred method of integrating (e.g. middleware platform, API integration, flat files etc), fall-back strategies etc.
  • Design & UX – requirements around the front-end of the website and how core user journeys, templates and components will be impacted by the technology stack etc.
  • Content management – integration with third-party CMS (if required – we’ll come onto headless CMS implementations later), scheduled publishing, ability to stage content, multi-user workflows, version control, how reusable content blocks should be managed etc.
  • PIM and catalog management – details of current product catalog setup, requirements around things like product types, management of key data, management of catalog across different storefronts, complex pricing logic etc.
  • Promotions – requirements around promotions and discounting and anything else loosely related to this (e.g. rewards points, loyalty programs etc).
  • Order management & payments – payment methods that need to be supported, key channels (e.g. subscriptions), pre-orders, multi-channel processes, store credit, tokenization etc.
  • Marketing – any requirements around marketing campaigns, technical SEO, tracking / tagging, analytics / BI setup / integration, management of campaign content etc.
  • Data migration and imports – what needs to be imported and when.

I’d suggest working with a Business Analyst or a consultant to undertake this activity properly – they’ll help to assess and understand the business-critical requirements and the non-essential ones. I usually recommend using something like Moscow ratings or impact mapping to help define the importance of each line item – which splits all requirements into must-have, should-have, could-have, won’t-have. I run a lot of these projects and would generally look to use these groupings to define phases and also for splitting out quotations / costings when it comes to reviewing this side of things. You can find out more about how I approach the requirements gathering side of things here.

SaaS vs Non-SaaS eCommerce Platforms

Over the last few years, there has been a big move towards SaaS-based eCommerce platforms, with Shopify Plus, BigCommerce and Salesforce Commerce Cloud being examples of platforms that have grown a lot in the mid-market and enterprise space. This shift has generally come from reduced maintenance and cost overheads, with PaaS and self-hosted platforms requiring more technical input and support.

Most eCommerce platforms have some level of commerce cloud offering nowadays (with some platforms like Magento being more of a PaaS), varying in terms of how self-sufficient they are from a security, maintenance, scale and upgrade perspective. Salesforce Commerce Cloud was the original leader in the enterprise SaaS space and remains a big contender, with Shopify Plus, BigCommerce, Centra and Workarea being examples of newer players. You then have platforms like Elastic Path and CommerceTools offering a best-of-breed, cloud-based platform to support headless builds.

There are various benefits to using a SaaS eCommerce platform, such as:

  • Clearer (and often lower) pricing – in most instances, costs for the platform would include platform maintenance, upgrades and patching, server maintenance and monitoring, a CDN, SSL certificates etc. Reduced costs are generally from no hosting costs, reduced support retainers, fewer or no upgrades etc.
  • Reduced maintenance overhead – fewer platform bugs and significantly less management of technical issues at a platform level, as all of this is managed as part of the delivery of the service.
  • Less security concerns – the platform would generally manage things like patches and would take responsibility for all other on-going security tasks, which would be managed at a platform level. The codebase would generally be locked down too and customisation would be limited to, again, reduce risk in this area.
  • Built to scale – most of these platforms have been built on top of an auto-scaling or at least highly scalable architectures designed to allow thousands of stores to scale through peaks.

The main disadvantage of cloud-based platforms is usually around rigidity and them either slowing things down (more some of the more enterprise platforms) or not allowing for customisation in certain areas. This is usually a benefit for conventional retailers and I’m a big of simplifying commerce platforms and reducing customisation to keep a platform stable and scalable, however, if it was a really complex retailer this would definitely be something to look at. Cloud-based platforms that do allow for back-end customisations etc also have an approval layer usually, which can slow things down in terms of releases and increase costs.

This is really top-level but well worth looking into – I also wrote this piece specifically about SaaS eCommerce platforms.

Headless Commerce

The headless approach to platform development / separating of the front-end presentation layer has been a big trend in eCommerce over the last couple of years, with lots of retailers opting to use a commerce platform for back-end elements and then integrate a separate framework or a headless CMS to provide a better front-end customer experience. You would essentially have a separate front-end technology stack that would request content / endpoints via APIs, which allows for a more flexible approach to front-end development and a more modern stack.

The term headless is essentially referring to ‘de-coupling’ the front-end of the store from the eCommerce platform and a separate set of solutions to serve content. You’re essentially ending up with a presentation layer and a functional layer and retailers often use additional systems as part of these kinds of setups too, such as a PIM for managing product data and a headless CMS to manage content.

This ‘micro-services’-based approach is essentially basically de-coupling different elements of a technology stack, rather than using a single interdependent application. This approach has become extremely popular at the enterprise level as it allows for the different areas to be developed independently and it simplifies a lot of processes where not all elements are required. Although it’s not for everyone and there are also cons to this approach, it’s definitely getting bigger and even the eco-system on the front-end side of things is massive now.

I personally think that this will become a bigger trend at every level of the market, with retailers wanting to create an implementation comprising multiple specialist areas that are integrated together. eCommerce platforms like Elastic Path, CommerceTools. CommerceLayer and Spryker are examples that are very focused on building out API-first setups, with their build projects often using separate services and reducing the need for areas of the platform when not needed.

I’ve spoken to a number of enterprise-level retailers who have started a new project like this and the older platforms are starting to adapt too. All platforms are now embracing headless at some level and the technology stacks are really varied. I’ll come onto examples of headless builds later on, but it’s a really big consideration now for any build and any platform. This article provides a really good introduction to headless eCommerce setups.

I think we’ll see a lot more of these kinds of setups now and I’ve definitely changed my view on headless over the last few months – having seen it more as a solution for specific cases and more enterprise previously. Some really good examples of headless eCommerce sites at different levels include:

Technical & IT Requirements

It’s important that you map out the technical requirements for the project, as this will likely contribute to the decision making process / impact how you’re architecting things. It may be that you’re flexible here, but it’s worth mapping out how you currently work and at least preferences here. 

This would usually be led by IT and potentially a few other teams and examples of things that would be looked at here include:

  • Business operations – detail around warehouse setup, inventory management, general considerations around logistics
  • Integration approach (detailed via systems diagram and any supporting docs) – current vs desired.
  • Database / API access for extracting data (need to be flexible here in most cases as platforms differ)
  • Approach to payments / order processing and any key requirements (e.g. tokenization for saving payment details etc)
  • APIs for different parts of the platform (e.g. catalog, customer / order data etc)
  • General architecture of the platform and how it impacts different areas (e.g. product catalog or multi-store)
  • Order management aspects (e.g. split shipment, complex multi-channel requirements etc)

One of the most common issues I’ve seen in the past with retailers is choosing a platform that can essentially meet the requirements, but they’ve not done the due-diligence into the way things actually then work. For example, something like bundling may be possible, however, it may need a lot of customisation to work in the way you need for reporting / integrations – which then impacts other areas (maybe pricing needs to be calculated in a different way, which passes the wrong information to third-party systems) and results in more customisation. Things like this often start small and then end up causing problems as you scale so the more time that’s allocated to the technical due-diligence side, the better. If you’re relying on a lot of workarounds, these will generally start to have more of an impact at scale also.

Another key consideration around re-platforming (and definitely one of the biggest) is about how the different technology fits with your existing team and your existing stack. For example, if you have a team of PHP developers and are considering a move to Salesforce Commerce Cloud or Shopify Plus, it’s going to be far more disruptive and have a far bigger overhead than if you moved to a platform that’s more relevant to your team’s experience and vision (e.g. Magento). This needs to be considered early when you’re still at the business phase – this example would be heavily focused on orientation and how you want to work etc, as those SaaS platform examples would be more likely to have a front-end focused team internally.

The same applies with integrations – your team may favour the API route for key integrations, but the platforms you’re looking at recommend a middleware platform or an iPaaS (integration platform as a service) – this is unlikely to be a showstopper as most platforms are pretty flexible, but it’s worth considering upfront.

When you’re approaching this side of things, it’s always good to start with a systems diagram, as this will touch a number of different areas. I’d then suggest building out a section of your specification with key technical requirements and also a supporting document or section that details how you’re currently handling these areas. It’s important to try and keep an open mind here – we’ve done some projects where retailers have gone from very bespoke / customised to very standardised (e.g. Shopify) and there’s been huge hesitation initially, but the teams have ended up really benefitting from it.

Platform Process Requirements

Another consideration is how well the different platforms will fit your existing processes – for example, some of the more enterprise-level platforms, such as Salesforce Commerce Cloud, have approval layers, which can impact the speed at which your team can deploy new features etc. Some platforms are more agile than others and if you have planned development work for the year ahead, you may want to ensure that the platform can meet your timescale requirements.

Assessing your existing systems and solutions

One exercise I’d recommend doing at the start of this process is making a list of all the programs that you’re using that are related to eCommerce and then determine if and how they’ll work with your new eCommerce platform.

In some cases, you may be able to integrate the platform with your existing solutions, but sometimes, you’ll either need to switch to a provider that works better with your eCommerce software or work with your provider’s built-in solution. I’d suggest remaining open-minded at this point, but it’s good to discuss what each of these solutions are doing, how they’re integrated, whether they need to be replaced etc.

For example, with the point of sale (POS), some platforms (such as Shopify) have their own POS and other POS vendors only integrate with certain payment providers etc – there may be variables that impact the combination of technologies. You may also find that some POS vendors have a really strong integration with some platforms and not others, for example, Sitoo and Ebizmarts have really strong integrations with Magento but aren’t as developed with other platforms.

Same goes for email providers – e.g. Salesforce Commerce Cloud is very often combined with Salesforce Marketing Cloud and Magento will likely be paired with Adobe’s email platform more and more. Shopify also has a series of ESPs that are more commonly used with the platform and allow you to get more functionality (through integrations with different apps and core areas of the platform. Shopify Payments is another example like this.

While some solutions integrate with a lot of existing providers or have native capabilities, other platforms aren’t as flexible, and you’ll need to either go with their preferred solution or create a custom integration that’ll work with what you already have.

At this point, you’ll need to determine if you’re willing and able to switch out your existing programs. If you’d rather stick to what you have now, then go for an eCommerce platform that lets you do just that. But if you don’t have any problems with changing providers and migrating to a new system, then you should be fine with a solution that has select integration partners of has such programs built-in.

Some examples of systems that could fall into this category could include:

  • Point of sale system (POS)
  • Order management systems (OMS)
  • Warehouse management system (WMS)
  • Email service provider (ESP)
  • CRM system

The vast majority of these will allow for custom integrations, they just may differ in approach. I’ve not included ERP in the above list as any ERP should really integrate with any platform (it just needs to be defined and planned – e.g. some systems won’t have APIs). It’s also worth noting that going down the middleware or iPaaS route could change this and could also be the best option.

Set a budget for the project

Budgeting for a replatforming project is hard – there are loads of bits that often get missed and there can be tens of line items that need to be factored in. Most companies consider things like licensing fees, set-up costs and development but fail to consider costs for maintenance or the expenses that come with integrations, various third parties, consultants and contingency against different areas.

When budgeting for your eCommerce solution it’s important that you also account for indirect costs and plan for a post-launch roadmap and any increases that could occur.

Here are a few things you should consider:

Costs of the platform itself – Pricing between different platforms will vary greatly. Some platforms have fixed licensing fees, while the majority now charge fees depending on your sales and traffic. Magento Commerce, for example, starts around $23,000 licensing fee but that goes up considerably based on GMV brackets – some of their biggest customers would be paying up to $10m per year. There are GMV tiers, but there are also lots of variables within their quoting and your costs will increase as you enter different tiers. With a platform like Salesforce Commerce Cloud, fees are based solely on your GMV and the targets you set and commit against – with them taking a % of sales that’s usually between 0.5% and 2.5%. Then you a platform like Shopify Plus which is fixed fee and GMV once you exceed a certain level or a platform like Spryker that’s based on developer seats, amongst other things. We’ll go into a lot more detail on the pricing models of the different platforms later on.

There are also eCommerce platforms that offer various editions or deployment forms, so costs will depend on the specific solution that you choose. For example, Magento has both on-premise and Cloud versions of the commerce platform and they also still provide the open-source option. SAP CX (Hybris) also has on-premise and Cloud versions and Oracle still supports ATG but also now have Oracle Commerce Cloud.

Here are some of the core costs models / licensing structures that apply with the different eCommerce platforms :

  • GMV licensing – based on the turnover or estimated turnover of the store (e.g. Salesforce Commerce Cloud) – usually net of tax, shipping, returns etc.
  • Up-front fixed licensing – license paid up-front with no additional costs (e.g. Shopware)
  • Combination of GMV / up-front agreement – an agreement based on where the retailer is at the start of the licensing agreement with tiers and brackets for the cost increasing (e.g. Magento)
  • Based on users / seats – pricing based on number of developer seats (e.g. Spryker)
  • Based on usage – licensing costs based on traffic levels or API usage (e.g. Workarea)
  • Monthly fee – fee paid monthly as part of an on-going relationship (e.g. Shopify Plus or BigCommerce)
  • Combination – a number of platforms combine these as well, with Shopify Plus and BigCommerce both being fixed price with increases in orders or revenue and a platform like CommerceTools being split between monthly fee and usage.

Design, development & integration costs – The CAPEX design and development cost for the build is likely to be one of the highest expenditures for the replatforming project – with most enterprise-level eCommerce builds cost between £100,000 and £5,000,000 if you choose to use an external agency / systems integrator. Obviously, there are lots of edge cases as well, with some website builds coming closer to £20,000,000 and some coming in lower than £100,000.

One of the most important things to consider is how you want your development to be resourced. There are lots of considerations here – with a number of our clients opting to split the project with a combination of in-house and external. We’ve had clients that have outsourced the front-end and resourced the rest internally, we’ve had clients that have outsourced every aspect of the build and we’ve had pretty much everything in between. 

Examples of some specialist resources you could need to bring in on a replatforming project could include:

  • Programme Manager / Lead Project Manager
  • Project Manager(s)
  • Solution Architect(s)
  • Business Analyst(s)
  • QA Testers / QA team
  • Development team (front-end and back-end)
  • UX Designer
  • SEO Consultant
  • Analytics Consultant
  • Integrations Consultant
  • ERP Developer / Consultant (e.g. Netsuite)
  • Other Systems Consultants (e.g. PIM)

I’ve worked on projects that have been fully outsourced to an agency, partially outsourced (agency development and in-house / contracted) and fully in-house. If you’re bringing in agencies you need to consider that you’re likely to pay a minimum of £700 per day and if you’re bringing in platform specialist consultants, it’ll be £500 – £1,000 per day. A lot of contracted project teams are 5-10 people, comprising testers / QA, PM’s, solution architects etc. These teams often move around together on large-scale re-platforming projects.

This is more of a business decision and it’ll come down to future business objectives and the level of skill you have currently and need in-house in the future, as well as budget.

Maintenance – You need to think about how much it’ll cost to keep your store running once you’ve launched. Maintenance fees can include everything from on-going development and dev-ops work to things like platform support, SEO, analytics, data management etc. You need to understand rough costs around support contracts and SLAs before you decide on a platform and suppliers.

Other considerations:

Integrations and/or bespoke solutions – Consider the integrations or bespoke solutions that you’ll require. Naturally, existing integrations or modules will cost less than developing tailored solutions, so you’ll need to factor in such costs when comparing different platforms. Examples of costs that can occur here are CAPEX and OPEX costs for integration platforms, contractors to support complex integrations, the integration T&M itself and various other bits like testing and the initial scoping etc.

Additional migration costs – Also take into consideration the amount of money and time it’ll take to switch to a new eCommerce system. Chances are you’re going to have additional costs around running two platforms in parallel, running more test servers etc, an extra resource for manual work, consultants around things like SEO etc.

List of potential costs when replatforming:

  • BA / scoping / requirements gathering
  • Design and build
  • Platform licensing
  • Larger third parties (e.g search, personalisation, ESP etc)
  • Hosting costs
  • Maintenance retainer
  • Development retainer
  • Platform-level apps and modules (e.g. wishlist app or SEO module)
  • External QA
  • External integration platform and professional services
  • External SEO
  • External PMs, BAs, SAs etc
  • External Analyst

Enterprise eCommerce Platform Comparison

Once you have a solid idea of what you need in an eCommerce platform and how you want your team to be structured, it’s time to do your research on the solutions available to you. 

I would personally say go and do your own research or work with a consultant over just going to Gartner’s Magic Quadrant or an equivalent, but they do offer good insights as well – they just tend to miss some solutions and include some that I wouldn’t say are as relevant sometimes. It depends how you’re working etc, people have different views on the analysts.

In this guide, I’ll be focusing on a selection of platforms that I think are a good fir for the average enterprise retailer and that I’ve either worked with or assessed with clients. This guide is also mostly focused on B2C requirements, although when assessing the different platforms, I’ve also referenced some of the B2B features for some of the platforms (particularly Magento and SAP CX).

There are an increasingly high number of enterprise eCommerce platforms in the market – which has changed from when I first wrote this piece in 2015, when there were just a few. I’m focusing on platforms that I’ve seen as relevant in the market that I cover (mid-market – large-enterprise) and relevant to the average B2C enterprise retailer (I’ve also tried to include some emerging platforms).

Magento Commerce (Cloud & On-Premise)

Despite some reputational damage over the last few years and a lot of movement in their target customer, Magento remains a really solid platform that is proven to scale in different areas. Magento was historically considered a good fit for small retailers and brands, but nowadays that’s not really the case (in my opinion) and instead, it’s more of a leader in the complex B2C and B2B category. Magento 2 wasn’t the easiest transition for them (and now Adobe), but it’s definitely in a better place than it was from a stability perspective and Adobe are only strengthening this base.

Magento has an excellent eco-system around it, both in terms of agencies and technology partners and integrations for other systems – reducing the cost of extending your site, the need for customisation and the time-to-market for new features (which is definitely an issue with other enterprise platforms). Magento do also still have the Open Source version, which is free to use and has a lot of the same core functionality (such as the core PIM features, multi-store offering, customer groups etc), but there are gaps in some areas. Most users of Magento these days will opt to use the Commerce Edition, as it comes with platform support (be it very basic) and a host of strong features that most would consider a ‘must’ or at least worth the initial license fee (instead of relying on third parties and added customisation). Some of the Commerce only features include:

  • Magento Page Builder (enhanced content management and reusable components)
  • Gift cards
  • Category merchandising
  • Scheduled publishing and content staging
  • Customer segmentation
  • RMA
  • The B2B suite (completely independent set of features which add a lot of value for anyone with a B2B / wholesale channel)

These are just a few examples.

The same goes for Magento’s community and eco-system, which is one of the key benefits of using the platform. Magento has a huge developer community and there are lots of great systems integrators all over the world too. Although Magento is still relatively new to the enterprise bracket, it’s definitely proven, with customers like END Clothing, Nobel Biocare, Fornum & Mason, Bulk Powders, Helly Hansen, Bauhaus, Missguided and HP doing large volumes through the platform and extending different areas considerably.

In terms of native features, Magento Commerce offers lots of built-in capabilities when it comes to PIM & merchandising, multi-channel, international, B2B and various other areas. Popular features include the range of native product types (e.g. native support for bundled products and grouped products), customer groups, their native multi-store architecture and lots more. Magento’s market has become increasingly associated with B2B, where it’s becoming more of a leader for these types of businesses looking to grow in different ways but remain agile. Some of the features released as part of the B2B suite include:

  • Custom product catalogs and pricing
  • Quote management
  • Credit limits
  • Purchasing roles
  • Team and user budgeting
  • Advanced customer management
  • Advanced volume pricing

Magento 2 was heavily criticised when it was first released and it took a long time for it to become stable. As of 2.3, Magento is in a much better place and most of the merchants that I work with are mostly happy using the platform and with where their implementation is. I’m still not 100% sold on Magento’s cloud edition, but it’s getting better and people are definitely far happier using it than a year or so ago.

At a glance

Strengths – Magento has lots of powerful native features and it is highly versatile and extensible – even with Cloud. This allows merchants to be more nimble when they want to scale or add new features and functionalities. Magento also has a huge developer community (across agencies and freelance / contract developers), making it easy to get support. Magento’s multi-store features are also very strong in comparison to some of its competitors.

Magento’s quickly becoming a market-leader in the B2B space, which is definitely more in-line with where I’d say the platform sits. Overall, I’d say that Magento has moved up the food chain and is ideally suited to complex B2C retailers and B2B retailers looking to remain agile in the enterprise.

There are also lots of examples of headless Magento stores (e.g. Made.com, Oliver Bonas, Zadig & Voltaire etc) and Magento’s PWA Studio framework is a very positive progression coming out of the platform. This is an area where Magento is fairly strong, despite not offering full API coverage like some alternatives. Integrations with the core Adobe products and the new Adobe Commerce Cloud offering are also fairly interesting for enterprise-level users, but I’ve yet to see a positive example of an implementation that’s managed to deploy all of the products together seamlessly. This is an interesting area to keep an eye on.

Weaknesses – As already touched on, Magento is a big platform that has a pretty serious maintenance overhead, both in terms of costs and time. It’s very common to hear of Magento users getting frustrated with this side of things and the general technical nature of the platform can also lead to certain types of teams and businesses struggling to get the most out of it. The other weakness is that it’s generally not as agile as some of the other platforms, particularly the likes of Shopify and BigCommerce. 

Integrations, partners, and experts – As already mentioned, Magento has a wide ecosystem of developers, experts and agencies. Magento has existing integrations with most commonly used third-party solutions and merchants definitely benefit from this.

There are also plenty of experts and agencies ready to assist Magento merchants in various capacities, so if your business has any special requirements, or if you simply need help setting up, running, or maintaining your store, you can easily find an individual or company that can handle such tasks for you.

Examples of Magento Commerce Stores:  Paul Smith (Magento 2 on-premise), Helly Hansen (Magento 2 Cloud), Bulk Powders (Magento 2 Cloud), Paperchase (Magento 2 on-premise), Made.com (Magento 2 on-premise), END Clothing (Magento 2 on-premise).

Magento Commerce Licensing Cost – Starts from $23,000 per year for on-premise but our average client pays $50k – $100k. We generally tend to opt for the on-premise version and work with someone like Akoova or Sonassi to support the hosting side. The Cloud edition comes at the same cost though.

Examples of Magento Partners – Vaimo, Tom & Co, Gene Commerce, The Pixel, Born Group, Tryzens, Pinpoint, Inviqa, Accenture.

Salesforce Commerce Cloud

Salesforce Commerce Cloud

Salesforce Commerce Cloud (formerly Demandware) is known for being the original enterprise SaaS eCommerce platform, offering a wide range of features to B2C businesses (which will change to include B2B as Cloudcraze develops). Salesforce Commerce Cloud has been extremely popular amongst fashion and lifestyle brands over the last few years, particularly with some of the struggles that Magento has had historically (with Magento 2 in the early days). Salesforce have a lot of market share in the mid-market and enterprise fashion and lifestyle space, having also won a lot of the brands and retailers that have migrated away from platforms like ATG, IBM Websphere and various others in recent times. Notable Salesforce Commerce Cloud clients include Adidas, New Balance, Halfords, Boohoo, Monsoon Accessorize, Ralph Lauren, Gucci and various others. 

The Salesforce Commerce Cloud platform solution has always been positioned to allow for high-growth merchants to trade across digital and physical channels (big multi-channel focus), without worrying about maintenance, servers, security etc. They were the original platform to really offer a fully managed platform with very little maintenance overhead and a guarantee around scale, particularly around peaks. There are a number of other platforms with this type of offering today, but Salesforce Commerce Cloud currently remains the leader at the enterprise level.

Out of the box, Salesforce Commerce Cloud offers native support for different types of products (bundling, different levels of configurable products etc), machine-learning and personalisation (across different areas of the platform), strong merchandising, multi-store support (for international and multi-brand) and strong reporting. Salesforce Commerce Cloud is also often integrated with the other Salesforce products, particularly Salesforce Marketing Cloud which benefits from Einstein (their personalisation and machine learning engine) passing data between the two.

I’ll come onto this later on, but the costs around Salesforce Commerce Cloud are generally very high – in terms of licensing (which can be competitive), but more so the development partners and the on-going costs around new features etc.

At a glance

Strengths – Salesforce Commerce Cloud’s strong focus on omni-channel makes it an attractive solution for modern B2C retailers who are looking for a smooth, end-to-end commerce solution. The SaaS-based nature of the solution also means merchants won’t have to worry about server maintenance or any other associated aspects – which has generally been the biggest appeal for merchants, as well as the proven scalability. Demandware was built specifically for enterprise-level retail and they are very good on the assurance side, as a result of their approval layer for technical releases and various other inputs from them. Since the Salesforce acquisition, the platform has continued to develop, with the introduction of Einstein being a big one for retailers wanting to build machine learning and personalisation into their platform. The recent acquisition of Cloudcraze is the other thing that is intriguing, which is likely to take Salesforce’s commerce offering into the B2B space.

Salesforce have also recently opened up the front-end of the platform and are now more focused on headless builds, which is good. This could also help to make users more agile in some aspects of development.

Weaknesses – For me, the biggest disadvantage with Salesforce is the costs around the platform (most areas) and the lack of agility in places (as a result of the enterprise nature of the platform). As with most of the enterprise-only platforms, Salesforce Commerce Cloud also doesn’t have a huge community, so getting support or development work done quickly can be a challenge – taking a team of developers in-house would also be harder with a platform like Salesforce Commerce Cloud. The integration partners and consultants around SCC are also generally very expensive compared to some of the other platforms.

Salesforce Commerce Cloud being a SaaS solution can also be a disadvantage, because it may limit your freedom and speed when it comes to site customisation and development. This to me is mostly a pro (I’m a big fan of SaaS generally), but it can be a con for some. Since the technology is controlled by Salesforce, there are some limitations on the features you can implement and there’s an approval layer, which can add a time overhead to site changes and releases.

Integrations, partners, and experts – Salesforce Commerce Cloud has the LINK Marketplace, which showcases its technology and service partners. Once again though, it’s not as large or comprehensive as with platforms like Magento. In addition, even some very mainstream solutions will require a custom integration, as Salesforce Commerce Cloud isn’t designed for the masses.

Enterprise Salesforce Commerce Cloud integration Partners – Born Group, Astound Commerce, Greenlight Commerce, Inviqa, Accenture, PWC, Javelin Group.

Examples of Salesforce Commerce Cloud stores:  New Balance, TATE Modern, Adidas, Callaway, Gucci, Clarins, Converse.

Salesforce Commerce Cloud Licensing Cost – The cost of the platform varies, as Demandware charges fees based on the merchant’s forecasted sales. Around a year ago, Salesforce did introduce slightly different pricing to make them more competitive against the likes of Shopify Plus and BigCommerce (and even Elastic Path and Magento in places) – offering as low as 1% for SMB users with single price books, for example. They do seem to be more flexible than when I’ve seen them in sales processes in the past.

In my experience – the GMV-based fee has been between 0.5% and 2.75% of turnover, depending on volumes and commits. On average from what I’ve seen, a Salesforce customer doing £5m per year would be paying around £100k – £200k per year, depending on expected growth. For a retailer doing £25m per year, this would likely be more like £250k – £500k per year, again depending on growth targets etc.  The Salesforce Commerce Cloud fees are based on the retailer’s commits, which can also result in penalty fees if the GMV commits aren’t reached.

The only other thing I’d say here is that often the biggest costs will come from outside the licensing, in comparison to other platforms. On-going development costs can be very high, with small changes generally having much higher estimates etc and integrations requiring more work as a result of the smaller eco-system around the platform etc.

SAP Hybris (CX)

When I originally wrote this piece, it was focused on the on-premise version of SAP Hybris, now we’re looking broadly at the SAP eCommerce platforms, including the newer cloud-based platform, SAP Commerce Cloud and loosely Upscale Commerce, which is very new still. SAP’s commerce platforms all come with multi-site, multi-language, and multi-currency features out of the box, as well as really strong PIM capabilities and various other modules to support complex eCommerce. The SAP Commerce Cloud solution is designed for large retailers and is really only relevant to the top end of the enterprise market, rather than most of the other platforms that are competitive in the mid-market as well.

SAP Hybris has been a leader in the enterprise eCommerce space for a number of years, offering a truly scalable architecture and an enterprise-level set of native features – however, today, it’s mostly relevant to really complex B2C retailers and B2B merchants.

At a glance

SAP’s eCommerce platforms have always been designed for large, complex businesses – Hybris has often been referred to as a commerce framework, given that most implementations are heavily customised to support business logic and bespoke functionality.

SAP Commerce Cloud sits well in the enterprise bracket, with costs usually considerably higher than most of the other platforms looked at here. The platform comes with a host of powerful features as part of the core and optional modules, such as a new drag and drop CMS, built-in personalisation features, advanced rule-based merchandising functionality and a range of product management features. Other notable features include advanced fulfilment capabilities (for implementing things like click-and-collect, partial delivery, multi-warehouse etc), support for complex product types, centralised product and content management for running stores across multiple channels and more.

Strengths – SAP’s built-in multi-site capabilities make it a great solution for retailers with multiple brands or international stores. The same applies to B2B due to native support for key requirements such as customer-specific catalogs and pricing, quotations, customer roles etc. Its centralised content and product management features are also a big plus for merchants who want to unify their digital and physical retail operations. SAP’s various commerce platform options power some of eCommerce’s global leaders, largely as a result of their ability to handle key peaks and scalability in general. Most retailers who move to Hybris do so with an objective around scalability.

Weaknesses – Cost of ownership is generally very high with the SAP platforms, with on-going development, platform upgrades and the licensing costs being very high compared to platforms like Magento, for example. The integration partners also generally come with high rates also. My experience of working with Hybris retailers has also been that remaining agile can be tough – with the overhead required to make customisations or integrate third parties being a lot higher than other platforms.

Integration partners – With a very limited community around the platform, there are fewer developers around and fewer agencies to assist you with implementation and maintenance (again, compared to platforms like Magento or Salesforce). Most of the SAP partners that I’ve been exposed to are large IT companies or very enterprise-focused systems integrators – examples of SAP Hybris development partners include TCS, Greenlight, BORN, Accenture etc.

Examples of SAP Commerce Cloud & Hybris merchants / stores: Benefit, EE, GHD, Mulberry, Aldo, LK Bennett, Dr Martens, Rapha, Barbour, JD Williams.

Costs with SAP Commerce platforms – realistically, license fees with the SAP platforms are going to start in the $500,000 bracket and can very easily range into the millions. SAP have various models for pricing (often different for the different platforms), including pay-per-use, long-term. fixed licensing, and revenue share.

Shopify Plus

Shopify Plus wasn’t previously included in this list due to its focus on SMBs and the mid-market, however, after considerable growth with larger brands over the last couple of years, it’s definitely a competitor in this space now. Although generally considered for more simple projects, Shopify has made huge progress globally in recent times and examples of large retailers using the platform include Staples (Canada), JB Hifi, Fashion Nova, Decathlon (US), MVMT Watches and lots of high volume brands!

Known for its agility, low cost of ownership and ease-of-use, Shopify Plus is a low-maintenance SaaS platform that has become a real contender for larger retailers and brands nowadays. Although there are still a number of gaps in its offering (such as proper, native multi-store architecture, various B2B features and advanced PIM features), Shopify is handling a lot of complexity with some of the larger clients, via integrations with third party applications, custom apps, complex theme logic etc – as well as lots of front-end complexity on headless builds (via their storefront API).

Shopify Plus is particularly popular with high-growth brands, boasting some of the fasting growing DTC companies on the planet, including Kylie Cosmetics, All Birds, Gymshark, Chubbies, Parachute, Brooklinen, Outdoor Voices and lots more. You then now have more traditional brands moving onto the platform, such as APC, Victoria Beckham, Emma Bridgewater, David Austin Roses, Ulla Johnson, Rebecca Minkoff and various others.

The recent growth of the Shopify Plus platform has been very clear to see, with lots of big brands making the move from platforms like Magento 1 and Salesforce Commerce Cloud.

Although Shopify Plus’s primary market remains with simple B2C retailers, they’re moving up the food chain fast, as a result of people extending outside of the platform and compromising in part to gain more control over their platform and remain agile. Lots of the larger Shopify Plus builds will have a broader technology stack, which could include a CMS like Contentful, a PIM, an iPaaS for passing data between different systems and potentially a third party merchandising platform.

At a glance

Strengths – The main selling point of Shopify Plus is the unrivalled agility of the platform and the low cost of ownership, with pricing starting from just $2,000 per month (moves to GMV when a merchant exceeds $8m in a calendar month) and remaining low in comparison to rival platforms. Extending Shopify may not be as endless as with other platforms, however, it’s far more straightforward with far less risk. Although Shopify has some excellent native features and continues to innovate via the platform, in my opinion, Shopify’s app eco-system is what has really pushed the platform forward. Shopify has a huge range of specialist third parties around the platform that allow merchants to quickly deploy new (and regularly improved) functionality via a monthly fee – examples include subscriptions, customer services platforms, personalisation, search, inventory management, sales channels, reporting and lots more.

Shopify’s own Flow, Launchpad and POS are also big selling points – making things easier for merchandising teams (automation and scheduling) and also reducing overheads around retail (multi-channel loyalty, reporting, opening new stores, gift cards etc).

Weaknesses – Shopify supports lots of core eCommerce requirements out-of-the-box (merchandising, promotions, different product types etc) but does fall short in some areas (such as proper multi-store, complex product setups, wholesale / B2B etc) – that said, Shopify’s network of technology partners does help to counter some of these limitations. Some examples of limitations include lack of native capabilities for managing multi-store setups (managing data and configuration at a global level), international in general (fixed price multi-currency etc) and the variants limit (limited to 100 variants for each product). Things like multi-shipment, frustrations with Shopify Payments (eligibility and rigidity), lack of native bundling, limited customisation of the checkout etc are often frustrations for users also.

Shopify Plus Integration partners – like Magento, Shopify Plus have a strong network of integration partners, ranging from single-platform specialist agencies to large consulting firms. Examples of integration partners that are in-line with the enterprise end of the market include We Make Websites, Fostr, BVAccel, Diff, Half Helix, Lemonade, Verb & Visual, One Rockwell and Corra. Some of those partners are long-standing Shopify-focused agencies, whereas the others are larger integrators who have worked more with other platforms and have developed an offering around Shopify Plus.

Examples of Shopify Plus stores – Kylie Cosmetics, Fashion Nova, Protein World, MVMT Watches, Chubbies, Rebecca Minkoff, Bulletproof, David Austin Roses, APC, Pangaia, Brooklinen.


BigCommerce Enterprise

BigCommerce is a SaaS eCommerce platform that has newly moved into the enterprise bracket, as a result of a number of key architectural changes and general growth with bigger merchants. Here, we’re referring to the BigCommerce Enterprise package / offering, which is designed for larger retailers using the platform (with smaller packages for SMBs and startups).

BigCommerce has also really pushed from a marketing perspective and they’ve generally aligned themselves with the enterprise bracket a lot over the last couple of years, with a focus on headless and positioning as an “open-SaaS”. Often compared to Shopify, BigCommerce has a very competitive TCO, even when paired with some of their more enterprise technology partners (which has been a big focus recently), such as Bloomreach.

BigCommerce has a good native feature-set and also has an increasingly strong technology partner eco-system, having allocated a lot of their recent investment money (via VCs and their recent IPO) in this area. BigCommerce have brought in larger and more enterprise-focused integration partners (such as BORN Group, LiveArea, Invite and Space48) and they’ve also grown their technology partners considerably too.

At a glance


BigCommerce Enterprise is very competitive when it comes to pricing, starting from around $1,000 per month and then increasing based on order volumes. Similarly to Shopify, BigCommerce is a very lean SaaS platform that requires very little maintenance but remains relatively extensible with a host of APIs available. The costs for developing a BigCommerce website and then extending it are again very competitive and would likely be far lower than the likes of Magento, Salesforce Commerce Cloud and SAP. That being said, BigCommerce are very focused on the headless market, which can impact this agility and TCO.

The headless offering is also something that has been very good for BigCommerce and is very attractive to larger users. The lean, agile nature of the platform, combined with a strong front-end stack is very compelling when comparing against some of the more established enterprise players.

BigCommerce has a good native feature-set, as briefly touched on earlier – the product management side of the platform is very good, they’ve recently introduced a native page builder, they have native multi-currency support (with support for separate price lists) and they also natively support things like RMA, reviews, custom fields etc. Overall, although not as polished and well documented as Shopify, BigCommerce is more feature-rich out of the box.

BigCommerce has a number of core B2B features, which does often give them an edge over Shopify.


BigCommerce is still quite new to the mid-market and enterprise end of the market and they’re still building out key partnerships etc. Their eco-system is getting better quickly, but it’s a long way behind Shopify in this area. Things like documentation and just the amount of support there is online is also getting better, but again it’s not as strong as Magento and Shopify in this area.

Like Shopify, BigCommerce doesn’t have a native multi-store offering, which is likely the biggest thing that hurts them when competing with the likes of Magento and SFCC (although it’s coming soon). BigCommerce also doesn’t support multi-source inventory, but again this is coming soon.

BigCommerce integration partners

BigCommerce has signed a lot of larger integration partners in recent times, with key partners including Born Group, LiveArea, Greenlight, Space48, American Eagle, Overdose, Matter of Form, Redstage and Tryzens.

Examples of BigCommerce merchants

BigCommerce have picked up a lot of larger retailers in Europe recently and they continue to grow in Australia and North America also – although their client list isn’t as strong as most of the other platforms in this piece. Some of their biggest stores include SkullCandy, Bensons, TRX, Spinning.com, Woolrich, Camelbak, Clarks (AU), Superdry (AU) and Cutter & Buk.


Released in 2016, Spryker is an interesting platform for a number of reasons, not least of which is its developer seat pricing model. Spryker is very much focused on the enterprise market and it’s biggest competitor is likely to be SAP Hybris, with it being seen as more of a platform for highly complex, bespoke development for retailers doing high volumes of orders with high levels of complexity. Spryker is still very focused on the German market, but they’ve developed a really strong reputation there and they have a number of huge, highly complex omnichannel clients. 

I would’ve liked to have seen more growth in the UK for Spryker, but I think there’ll be a lot more to come from them over time. It’s worth noting that they’re relatively similar to CommerceTools in positioning and CommerceTools has gone through significant growth in recent times.

At a glance

Spryker is largely seen as a commerce framework rather than an eCommerce platform or shopping cart, with developers building on top of the platform via existing modules or bespoke functionality. Spryker is also geared towards micro-services, with open APIs allowing for headless implementations (API first platform with no front-end essentially) and integrations with other core parts of a broader platform setup.

There are various different versions of Spryker, with the Commerce Cloud generally being the most relevant when we’ve looked at it. They have a strong offering in both B2B and B2C and they do also have a more mid-market / MVP focused version of the platform in Spryker Now.

I’ve spoken to a few people about Spryker in the past and the key things that have been referenced as being ‘outstanding’ are the underlying architecture (allowing for excellent performance) and the quality of the codebase (very modern codebase built for scaling without compromise).

Spryker costs: There is no revenue or usage element to pricing, and instead, clients pay per developer seat. Licensing costs €1,950 per developer per month, with discounts available for larger setups and different payment structures. SLA-based support pushes the cost up to €2,800 per developer per month. As far as I’ve heard and seen, Spryker builds start from around $500k and go well into the millions.

Examples of Spryker stores: Hilti, Certeo, Tom Tailor, Aldi, Toyota

Spryker Integration Partners: Inviqa, Flagbit, CGI, Netshops

Strengths: A lean, agile framework for rapid development of new channels and stores, with a strong focus on future trends such as micro-services architectures and IoT. Highly extensible and designed for complexity. 

Weaknesses: Very focused on the high enterprise-end of the market and retailers with lots of complexity. Spryker currently has a good footprint in this space in Germany, but aren’t as well-known or well adopted in other markets yet. They also don’t have a big eco-system currently, which limits them I would say.

Getting the information you need to make the best decision when replatforming

Reading up on eCommerce platforms is just a small step when it comes to evaluating different solutions. In order to really get an idea of which platform to choose, conversations with internal stakeholders, solution providers, and outside experts must be conducted. If possible, try to get an actual demo of the product so you can see it in action.

Talking to internal stakeholders

When talking to relevant team members, be sure to cover:

  • The specific things they liked or disliked about each solution
  • The adjustments they’ll have to make to adapt to the new platform
  • Training or resources they need to learn their way around the software
  • Longer-term functional aspirations
  • Additional costs they may incur

Talking to solution providers

Here are some talking points to bring up with the solution providers you’re considering

  • Standard and native features
  • Partner eco-system
  • Total cost of ownership questions
  • The amount of time and work is required to get their software up and running (for different teams and team members)
  • The amount of time, money, and work required to maintain the software (for different teams and team members)
  • Where you can find resources, developers, and expert support for their solution
  • Number of systems integrators that they think are suitable for the project
  • Their existing clients

Talking to outside experts

It’s always recommended that you get input from an outside expert who can provide an objective opinion on the solutions that you’re considering. Points to bring up:

  • How the solution compares to other platforms they’ve worked with
  • The amount of time, money, and work required to get the software up and running (vs other platforms)
  • The amount of time, money, and work required to maintain the software (vs other platforms)
  • Where you can find resources, developers, and expert support for their solution
  • Whether or not they recommend the solution for your business

Compare and evaluate (ideally with your team and external, expert input)

Hopefully, by this point, you’ve gathered ample notes and insights into the solutions that you’re considering. It’s not always easy to get an “apples to apples” comparison, but try to get a side by side view of the different platforms when it comes to general categories such as out of the box features, integrations, customisation, costs, etc.

As previously mentioned, selecting an eCommerce solution should be a team effort. Make sure that all relevant team members are part of this step, and if possible, include a solutions expert in the process so you can get a complete and well-rounded idea of what platform would work best for you.

Need help finding an agency or selecting a platform?

If you’re looking for support in selecting a platform or doing due-diligence on certain ones, I’ve been working in this area for a number of years and am more than happy to either support the exercise or provide advice / guidance. I’ve worked extensively on platform evaluation and have hands-on experience with most of the platforms above. Feel free to email me on [email protected] should you want to discuss a project or just need advice.

Here are some other suggestions for validating the platform fit:

Talk to the platform provider – Consult with your solution provider and ask them how you can find experts who specialise in their platform. Do they have a partner network? Who would they recommend? Be aware that if they’re partner-lead, there may be bias in why they’re recommending certain partners.

Attend their events – Some eCommerce companies hold events to educate and engage their communities. Consider attending these functions so you can network with potential agencies and experts.

Speak to eCommerce consultants and consultancies – Like me, there are lots of eCommerce consultants around that really know the platforms inside and out. I’d just suggest validating their experience on projects like this though and the platforms themselves. 

Ask an expert – I always get asked questions around platform suitability on Magento and there are lots of more knowledgeable people than me. Reaching out to people that know the platform well and asking them questions is another good option.

Referrals – Get in touch with other eCommerce merchants using the platforms you’re considering and ask if they could refer you to experts and partners who can assist you in choosing, setting up, or maintaining the software.

Good luck, and if you need more information on any of the solutions or pointers discussed above, feel free to comment below or get in touch at [email protected].