Ecommerce Replatforming: 4 Crucial Considerations When Changing Platform

Posted by Guest Writer 13 Aug 14

In this guest post, we're delighted to welcome ecommerce and digital marketing consultant James Gurd. In his 12 years in ecommerce, James has worked with leading UK brands such as Sweaty Betty and House of Fraser, co-hosts #ecomchat, which is a weekly Twitter chat for ecommerce knowledge sharing, and regularly contributes to Econsultancy. 

devWhen I started to write this blog, I realised that to boil down all the key decision criteria that must be reviewed when planning an ecommerce replatforming into one post would provide no detail and a long, not very useful list. Instead, I’ve focused on a few of the areas that, in my experience, often get overlooked in the heat of battle and given my perspective on what needs to be considered. I hope it’s useful reading.


Solving, not moving problems

A replatform project usually only arises because there is a problem to solve, for example a retailer outgrowing the capabilities of the current platform. When the breaking point is reached, it’s essential to have a clear focus on the goals of the projects and desired outcomes to avoid letting the excitement of change cloud judgment.

A common issue I’ve seen in projects of this size is solving one problem but creating a new one to replace it. For example, solving functional issues like supporting multi-currency but creating scalability problems by moving to an inflexible hosting solution.

This is where project governance comes into play. Governance concerns the project controls that will be used to steer the project and ensure it sticks to an approved (but constantly evolving) project plan. A project without a clearly defined governance policy carries a significant risk of derailment.

A few key tips:

  • Set up a project 'Steering Board'
This should have a C-suite level sponsor and include the senior representative from all key stakeholder groups e.g. ecommerce, marketing, buying, customer services, IT, finance etc.
  • Allocate a dedicated project manager
An experienced PM is worth his/her weight in gold. They will create a project plan, set milestones, create issue logs and manage reporting. For complex projects consider using a matrix with a senior PM managing multiple workstream project managers. A large project may be too much work to place on one person.
  • Use experienced business analysts
The BAs will map and document the core business processes and requirements, feeding these through into the IT team in a suitable format. They are skilled in requirements gathering and using project management tools to capture the information.
  • Make sure you have a customer champion
Somebody needs to push the business side of the story and make sure both commercial and end user requirements are catered for. For example, ensuring the IT teams understand ecommerce good practice implications of the requirements to help with solution design.
  • Monitor, review, adapt
I’ve never seen a replatform project go like clockwork. It’s a complex, multi-person project that requires an agile approach to adapt as you learn.  Make sure you have the cycles in place to do this.

Of course in a small business, it’s unlikely the resource/budget would justify specialists in each area. A degree of pragmatism is required to ensure these disciplines are covered within the project whilst making delivery achievable.

Building in flexibility and control

It’s common to start a replatform project with a clear idea of scope, only to unearth requirements during discovery that fundamentally challenge this version of the truth.

In a traditional waterfall approach, this can hammer the project plan because there is little flexibility in the delivery process. However, following an agile methodology accepts change as an integral part of the process. It’s essential the style and methodology for project delivery is agreed when setting governance rules and that it has been scrutinised to ensure it is the best fit with the project goals.

This therefore requires adequate control mechanisms, such as weekly scrum meetings between the developers and PMs. These mechanisms are put in place to ensure progress is monitored constantly and any exceptions are flagged and escalated for prompt action. In other words, risk is managed. Risk is an inevitable part of the project, so the challenge is to put processes in place to reduce the likely impact if something exceptional happens.

A few key tips:

  • Make sure there is one version of the truth – one person to monitor overall progress and report to the business
  • Agree which tools to use for project management and stick to them
  • Build contingency into the timeline – don’t leave no space for creep
  • Agree the assessment criteria for prioritisation – makes it much easier to review and decide what goes in and when. 

Getting the right IPR ownership

In my experience, this isn’t thought about enough when nailing down the contracts. The platform choice has a big impact on your IPR (intellectual property rights). If you go for a vendor platform, then the source code isn’t yours to own. So the platform isn’t your asset: it’s effectively on loan either as a hosted solution or via license. You should own all the customer data and content that sits on the platform but the underlying applications and code belong to the vendor. If you then decide the vendor isn’t right for the business, you have to find another platform to migrate your data to.

So think carefully about IPR ownership. Do you need to own the IPR for your ecommerce platform? If so, your options narrow significantly.  

If you don’t, make sure that the contracts are unambiguous on the ownership of data and access to that data. For example, if your platform vendor is providing the hosting and database storage, how is your data protected and how do you retrieve it?


Blanket statements like “SEO friendly ecommerce solution” often dismay me. It usually means that the site is built on accessible code that satisfies the core compliance requirements like W3C and WCAG but in reality, making your site truly SEO friendly requires a lot of planning and technical consideration.

The most obvious example is URL management. URLs are the primary driving force for search engines indexation. Without a URL you won’t have a webpage surfaced for search queries. Most platforms I’ve worked with don’t generate SEO friendly URLs out the box, you have to put rules in place to rewrite and publish. For example, product category pages have system-generated identifiers instead of keyword rich URL strings.

Ecommerce teams need to map out all the different types of URL and define the URL structures that the site should support.  The example below is a table I put together for CrowdShed, the startup I launched with some good friends earlier this year.


This includes parameter handling, such as session IDs and when canonical tags should be used to handle duplicate content. It also requires a detailed knowledge of faceted navigation and how to use URL variations to control the breadth of indexation. So if a user visits the Dresses category page and then refines by brand=Biba, does that generated a unique URL that is submitted to search engines for indexing with customised meta data?

Some of the key areas of SEO that need to be thought through include:

  • URL structure
  • On-page optimization (Page titles, meta description, H1 tags)
  • Canonical tag
  • Pagination controls
  • Handling URL parameters
  • 301/302 redirects
  • 404 error page
  • XML and HTML sitemaps
  • Robots.txt
  • HTaccess file
  • Meta robots tags e.g. noindex
  • Media alt tags
  • User generated content e.g. follow rules on blog comments
  • Breadcrumb trail
  • Markup e.g. events, authorship
  • Local content e.g. store pages

I can highly recommend downloading the Econsultancy SEO Best Practice Report, not because I was the lead author but for the amazing insights from experienced SEO specialist on all key areas of SEO. The section on Technical SEO from Verve Search & SEMetrical is a must read for anyone serious about making their ecommerce platform architecturally sound for SEO.

Comments and questions

So what do you think? Is there anything you don’t agree with? Please do drop by with comments and suggestions to stoke the fires of debate.



New Call-to-action  


Top Posts