The success, or failure, of an eCommerce project can rest on quite a number of variables – the project team, stakeholder buy-in, the integration partner selected for the build, the platform selected, and the requirements definition and project planning. All of these things, and more besides, all need to come together in order for an eCommerce project to be successful.

The other obvious issue that can result in a project not being considered a success is the failure to fully understand the cost of the initial replatforming project and also the cost of ownership for the new platform. I’ve worked with several merchants who have failed to consider all costs when planning a replatforming project, overlooking things like maintenance retainers, BAU development costs, costs of all third parties, training costs, costs of external support (e.g. SEO, Business Analyst, replatforming consultant etc).

A project that is on track, with the right resources in place and a committed stakeholder team behind it, can still founder if the initial project plan fails to take into account all of the costs associated with the launch and the on-going operations. This can also lead to compromise in various areas.

In this article, we walk through the process of identifying the true total cost of ownership for a typical eCommerce replatforming project, with some platform-specific examples to give a realistic picture.

Why understanding all costs and the longer-term TCO is important

Back in 2012, Forrester Research produced a report for Demandware, which looked at TCO in eCommerce projects, and one of the key findings from that report was that almost half of all eCommerce projects assessed had a TCO that was higher than predicted, often significantly so. At the enterprise level, this issue would undoubtedly lead to some awkward project meetings, where additional budgets were hammered out, but the projects would, on the whole, survive. For smaller or newer retailers, however, going way beyond the projected budgets before the site is even launched could spell disaster, with sites being scrapped before they have even started trading. If a project does make it to launch, insufficient funding going forwards could mean that it doesn’t achieve the goals that were originally set, rather than realising its full potential.

How to assess the TCO

The most basic step in performing a comprehensive TCO analysis is to divide costs into initial, or CAPEX, costs, and ongoing, or OPEX, costs. For many retailers, it is obvious that a significant portion of their budget will be swallowed up by the start-up costs of a project. What they tend to underestimate, however, is how much the project will cost going forward, once it has been launched.

Initial, CAPEX costs

Costs incurred in the pre-launch stage of an eCommerce project will typically include:

  • Platform evaluation and selection consultancy (if applicable)
  • Evaluation and selection of agency partners / RfP support (if applicable)
  • Discovery costs
  • Design and build costs (not necessarily fixed fee, so contingency often needs to be factored in)
  • Data import (if not part of the build cost)
  • Third party integration costs – e.g. iPaaS setup or managed integration by a third party (if not part of the build cost)
  • Third party search and merchandising solution (licensing, integration etc)
  • Third party module / app costs
  • SEO discovery & consultancy around the project (input into the functional spec, creation of project plan, management of SEO data migration and redirects)
  • External / contracted team members (e.g. BA, solution architect, supporting developer, project manager, QA etc)
  • Hosting & hardware costs (if applicable)
  • External platform training
  • Pre-launch testing

As can be seen, it’s easy to focus on the costs of the platform itself, the agency costs and the hosting costs, and to ignore less clear-cut costs such as staff training, testing, and pre-build evaluation processes. Obviously, these costs could vary enormously, depending, for example, on how many staff needs to be trained, and whether or not that training was carried out in-house or by using agency personnel. Similarly, if the initial project scoping and requirements definition is not comprehensive, the costs of third-party tools and API integrations could easily be overlooked, only becoming apparent during the build phase.

I once worked on a large build (that took around one year) and I’d imagine that the external project team to resource the build (minimising impact to the current site) was one of the highest, if not the highest CAPEX cost. This is something that should always be considered as bringing in experienced contractors can add a lot of value to the planning and delivery phases, as well as bringing another perspective and minimising risk / impact on the existing platform.

Ongoing, operational costs

Unfortunately, it is often the ongoing costs of an eCommerce project which people don’t consider upfront. I’ve worked with lots of retailers who have faced unexpected costs after going live that haven’t been budgeted for and this will generally come down to research and planning. These typically include:

  • Maintenance retainers / BAU development costs
  • Support retainers
  • Integration platform (iPaaS) costs (if applicable)
  • Ongoing hosting fees
  • Payment-related fees
  • On-going module costs (if using a platform like Shopify Plus)
  • Annual license fees for third-party apps and integrations
  • Fees for SEO retainer
  • PPC fees and other paid advertising costs
  • Maintenance of social media accounts to support the eCommerce store
  • Ongoing staff training
  • Third party personalisation solution (e.g. NOSTO or Monetate)
  • Email service provider (e.g. dotmailer or Emarsys)
  • Fraud tools / provisioning (e.g. Kount or sygnified)
  • Third party monitoring tools (e.g. New Relic, Pingdom, Shoppimon etc)
  • Third party returns solution (e.g. Intelligent Returns)
  • Other third parties (e.g. address validation, shopping feed management etc)

Time and people costs

Consultants / external team member costs

The amount of external resource needed to support a replatforming project varies from merchant to merchant, based on things like other projects happening, the size of the team, the skill-sets of that team, the delivery timescales and the complexity around the project. Examples of external resources that are often needed for replatforming projects include:

  • Contract Solution Architect
  • Contract Business Analyst
  • Contract QA Tester
  • Contract Project Manager
  • Consulting SEO Consultant or some form of technical SEO input
  • Consulting Analytics Consultant
  • Broader eCommerce Consultant / Project Lead
  • Integration Consultant (e.g. Netsuite developer)

All of these roles can vary between £450 and £700 per day in my experience, depending on location, contract length, the technology you’re working with (e.g. costs will be higher when working with Hybris, Adobe Analytics, SAP etc), level of experience etc.

Time costs for your existing team

The other consideration here, at all levels, is the time overhead for your team. When selecting an eCommerce platform, there are some systems that are going to require a huge amount more time from your team to maintain the system and the skill-set / size of team requirement would like change too. This is something that should be considered in a TCO assessment as well.

A good example would be a B2C retailer choosing between SAP Hybris (both on-premise and cloud) or Shopify Plus – the amount of time required to maintain and optimise the store over time isn’t comparable.

TCO comparisons between different eCommerce platforms

It can be quite complicated to try to compare TCO figures across different eCommerce platforms. Magento Open Source, for example, looks at first glance to be a relatively cheap option, since there is no initial licensing cost or monthly licensing fee, compared with Magento Commerce, which starts at $2,000 a month (cloud starter). However, the build costs for a project using Magento Open Source could work out higher, as third-party tools (with on-going costs) may be needed to provide functionality which is included as standard in Magento Commerce. Likewise, Magento Open Source can appear to be less expensive than Shopify Plus, until you account for the fact that with Shopify Plus, there are no hosting or platform maintenance costs, as the platform is licensed on a SaaS basis, and is a fully hosted offering.

Magento’s Open Source edition has long been favoured by smaller merchants because it is free to download, and it can be hosted relatively cheaply, starting at just $100 a month or so. Magento 2 Open Source is a very different beast with very different associated costs, which has contributed to the growth of platforms like Shopify Plus. Historically, a Magento Open Source or Community build could be achieved for $20,000, whereas now, builds start from around $60,000 and maintenance costs and the costs of on-going development work are considerably higher. This comes as a result of the platform being a lot more complex and agencies not being able to make the same margins as with Magento 1. I generally don’t recommend Open Source to small retailers anymore – I only tend to recommend Magento (generally Commerce these days too) to retailers who have the budget to get the most out of the platform.

The Magento Cloud Starter plan costs $2,000 per month and progresses upwards from there, based on a number of factors but mostly GMV. In comparison, Shopify Plus starts from $2,000 per month for merchants turning over less than $800,000 per month. For merchants turning over more than this, fees rise in line with earnings, up to a maximum of $40,000 per month. Magento’s rebadging of the Enterprise edition to Magento Commerce, with the associated switch in pricing structure, suggests that they’re trying to move more in-line with platforms like Demandware / Salesforce Commerce, whose pricing is based around GMV.

The different pricing models across the different platforms can make a TCO more difficult and less accurate, particularly with GMV-based models. With something like Salesforce Commerce Cloud where the billing is solely based on GMV and you could incur penalty fees if you don’t achieve the agreed targets, you’re best off basing the costs on the agreed licensing fees and adding contingency.

Third-party apps can account for significant ongoing costs and again, it can be difficult to compare these costs across platforms. Firstly, an app may be required in one platform to deliver functionality which is not provided out of the box, but in another platform, that same functionality may be provided natively. Secondly, Magento’s third-party extensions are typically purchased via a one-time license, whereas apps for Shopify Plus typically involve a monthly license fee, which sometimes varies according to usage and things like catalog size. It’s important to work out these costs, and to map out a three to five year cost analysis, to be able to compare platform costs accurately.

When it comes to ongoing maintenance costs, Shopify Plus has a clear advantage over any on-premise solution, including Magento’s on-premise version (which is a lot less of a focus for them these days). Because Shopify’s codebase is locked down and controlled by Shopify, they are responsible for all maintenance upgrades and security patches. With Magento, particularly Magento’s on-premise versions, the costs for this essential work have to be taken into account by the retailer.

Conclusion

The devil is in the detail when it comes to preparing an accurate TCO model for an eCommerce project. All elements of the initial build need to be covered, along with all predicted costs that are likely to be incurred once the site is live.

Typically, a TCO model would cover 3 – 5 years, in order to gain a clear and accurate picture across the expected lifespan of the implementation. The various costs may differ wildly at the individual level, but it is only by looking at the final TCO figure that a real cost comparison can be made. For the ultimate success of any eCommerce project, project owners would be well advised to put time and effort into a thorough TCO assessment.

—

For more detailed guidance on TCO for specific platforms and on RfP management you can read the following posts: