Ecommerce replatform: ensuring ROI in migrations

The time has come for your business to consider migrating to a new ecommerce platform. Perhaps your current platform is driving less ROI than it used to. Maybe your ability to innovate is constrained by the limitations of your existing platform. Or perhaps your competitors can adapt to changes in the market faster than you can. We have created three quick growth packages to help you solve these problems – find out more now. 

Whatever your reasons, here’s what you’ll need to consider to ensure business value from your ecommerce replatform project.

Ecommerce replatforms: the risks  

Ecommerce replatforms are risky projects. They inevitably touch business-critical systems and key customer touch points – inside and outside the business. Your existing platform has likely grown with your business, and a great deal of your current processes and business logic will have been ‘baked in’. This can make it particularly hard to predict the cost and potential return of your project with precision. 

For these reasons, it’s always worth considering whether a competitive advantage can be found by innovating and extending functionality on your existing platform, rather than moving to a new one.

But for the purposes of this article, let’s assume you’ve already established a strong business case that justifies the move to a new platform. Now let’s take a look at some of the ways YOU can approach the migration to mitigate risks and maximise the potential for a strong return on your investment.

The risks of ‘lift and shift’ migrations

Approaching an ecommerce replatform as a straight port of an existing platform’s features to the new platform is often viewed by both clients and agencies as a lower-risk option. This approach is sometimes referred to as a ‘lift and shift’.

In reality, approaching a migration in a 'lift and shift' way can increase the risk of a poor return on your investment.

By focusing on the like-for-like migration of features, you can miss the opportunity to take advantage of the benefits of the new platform. If mimicking a feature on your old site doesn’t give you a genuine, measurable advantage over your competitors, it may be better to adapt that feature to work in the context of your new platform, saving budget, and enabling you to innovate in other areas.

Likewise, it may be that there’s an opportunity to drop existing features from your future platform completely if they no longer hold the business value which they did when first implemented.

Customising a new platform to support existing backend processes can also be costly. That’s why it can be more cost-effective and less risky to learn as much as possible about the platform, and to identify where you can shape business process within your organisation to fit the new technology. 

Again, the trick here is to identify those processes that add the most value to your business, and to prioritise the delivery of those processes, adapting your current set-up to reduce costs and retain budget to innovate in new areas.

So instead of thinking in terms of a ‘lift and shift’ of features you’re going to port over to the new platform, it’s better to think in terms of the key business processes and business value you want to bring to the new platform. 

Forget MoSCoW

MoSCoW (Must have, Should have, Could have, Won’t have) has become a widely used prioritisation technique that many businesses use when starting a platform migration project.

When businesses are faced with a large backlog of requirements, MoSCoW can be an effective mechanism for capturing and documenting the high-level needs across the organisation. It also highlights the need to manage expectations about what can and can’t be delivered.  

However, I believe MoSCoW is an ineffective vehicle for communicating the real value of a feature to the business. It’s also a tool that can lead to misalignment between the business stakeholders and the delivery team. The reasons for this are rooted in the way MoSCoW is used in the real world.

In general MoSCoW tends to be written with features in mind rather than objectives. The capturing of requirements in a MoSCoW document is a cross-departmental effort and reviewing an entire business’ interactions with a platform in this way is by its very nature reductive.

This can result in competition across departments to ensure their key features are included. Also MoSCoW challenges the business to compromise very early in the specification process and this leads to a tendency for the ‘musts’ to be summarised to ensure their inclusion as top priority.  

An example I regularly see is ‘promotions’ being considered as a high-priority, single line item. This often comes with minimal exploration of the goals of those promotions or the specific mechanisms that are required. So you are left with something that must be delivered but without communicating either the strategic goals of these promotions, or the detail of the individual promotional mechanisms.  

This can then result in significant misalignment with regards to scope between the stakeholders and the delivery team, with the potential impact on budget and timescales this brings.

Another of the traps I’ve seen businesses fall into when using MoSCoW is where the features described are written from either the perspective of the old platform, or, in cases where there is a prefered new platform, in the language of the new system. In both of these cases what is missing is the ‘why’, i.e. what specifically the business now needs. 

Again the outcome of this, is misalignment in the build phase with features delivered that do not meet the business' needs.

MoSCoW can be a useful tool when looking at platform selection, but its reductive nature and tendency to formalise expectations early into delivery mean it’s best used carefully.

There are other prioritisation and requirements-capturing techniques that more effectively align the features that add most value to your business with the related effort required to deliver the migration, as we'll now explore.

Uncover value with story-mapping

In Agile project delivery user stories are often used to capture, at a high-level, what the system should do, what value a feature has, and who the feature benefits. A basic example for an ecommerce site may be something like this:

• In order to easily find the specific product I am looking for (value)
• As a customer of myecommercesite.com (who benefits)
• I would like to be able to search the site by product name (behaviour of the system)

A user story is primarily a reminder to have a conversation. Initially, you do not need to capture the full acceptance criteria; you just need to find out what the feature delivers and why it’s needed. Only when a digital team is close to committing to the delivery of the feature do you have a conversation between development team and business users to confirm the details and business logic needed to complete the feature.  

Story-mapping was described by Jeff Patton in 2008. To summarise his description, you need to first identify valuable user outcomes for the system. From there you derive activities, tasks, and user stories that deliver those outcomes. 

If you were to use this exercise to extend the ‘search’ story example above you may get something that looks like this:

If you then start to flesh out this map for a simple ecommerce system you may start to see something that looks like this:

Story maps are built in workshops that should involve the entire business. Since they’re collaborative in nature, and often cut across departments and business functions, story-mapping workshops are a more effective way of creating a shared understanding of what needs to be delivered by the migration. 

It’s worth reiterating that user stories should be used as a reminder to have a conversation and to drive out further details as delivery progresses. So the map itself becomes a dynamic tool that can then be used throughout the build of the new platform.

One of the most powerful features of a story map is that it allows you to understand what the minimum, go-live version of your new platform looks like, allowing you to use this to plan releases. This is done by viewing the full story map and slicing it horizontally to give you a view of what needs to be in each release. For example:

So story maps are not only an effective way of capturing and understanding the needs of your new system; they’re also a tool to help you continue to understand requirements and plan delivery during the migration itself.

Minimise risks, maximise returns

Now you have a story map that gives you a view of your system, there are decisions to make as to how the business value is best delivered in your ecommerce replatform.

At each point on the map you should ask yourself:

• Does the new platform deliver this value with no customisation?
• If the platform does not provide the value without customisation, can I adapt my business processes to work in the way that’s required by the new platform?
• If processes cannot be adapted, and customisation is required, does the return for that feature justify the investment?

Businesses should retain budget for delivering custom features that will give them an advantage over their competitors. The aim of asking these question is to minimise the amount of customisation needed to implement what are often commodity features. The custom development of platforms can be both risky and expensive. So, to minimise this risk, your business should be looking for the cheapest and easiest way of delivering the value, rather than the feature.  

An example of this in an ecommerce context is promotions. A business may run a particular 3-for-2 promotion on their current system that’s not possible on the new platform. There may be internal resistance to changing the mechanism, and this could mean custom development is needed on the new system. However customising promotion modelling can be costly, and there is a  risk that customised development will not deliver the required return-on-investment.

In this example it’s important to remember that the value the promotion gives to the business is not the promotion mechanism itself. The value is in the impact on the end customer’s behaviour and the resulting increase in conversion or basket size. So, in this situation, is it better to spend budget on changing the system to adapt the business process around promotions to fit with the new platform? 

The answer will depend on the individual business, but the decision between platform customisation and business process change should be a conscious one that is rooted in an understanding of the real value a feature aims to deliver. We have integrated this choice into our three new quick growth packages- get in contact if you want to learn more. 

Release light, release early

When a business undertakes an ecommerce replatform there is a temptation to launch with as many features from the new platform as possible. In this situation there’s a risk that the development budget will be consumed by delivering the fully-featured release, and that the business is then unable to enhance features that could make a big difference after go-live.

By approaching a migration using the planning techniques discussed above you should now have a view of what features are most important to your business. This should lead to an understanding of the features that justifiably require custom development, and the areas where business process changes is needed to support the new platform's ‘out-the-box’ features. 

To continue to minimise the risks of platform migration your business should consider going live with the lightest possible implementation of their new platform. This could mean going live with a limited feature set, or with simple initial implementation of a wider feature set.

After all, it’s only when business users and customers begin to interact with a new platform that you really learn which features provide the biggest return and where custom development to adapt functionality can add the most value.

Obviously this has to be done without disappointing users of the system. You have to ensure that basic features expected to be on the platform are available, and that there is no service interruption to users.

However, very often these types of features do not give a business a competitive advantage; they are commodity features and hence should be delivered as economically as possible.  

By seeking to release early and retain budget you can then capture real feedback and analytics from business users and customers. This then enables the business to identify features that are likely to have a high impact, and where there is supporting data to justify further investment.  

This approach is particularly relevant when delivering platforms that involve rich frontend user experiences. When businesses plan to update user experience and design as part of a platform migration project, design decisions made prior to release are often subjective, and aren’t rooted in real user data. User experience design and build can be costly, so releasing ‘light’ versions that allow you to test assumptions and the gather real-time user data can help maximise the return of any further investment.

Fuel innovation with your ecommerce replatform

As I’ve highlighted, many features in your new platform could be considered commodity features. Commodity features are those that your customers or users simply expect to be there. This could be a wishlist or store locator on an ecommerce platform, for example, or the tagging of popular content on a content management system (CMS).

If features like this are missing, or are poorly implemented, this will result in disappointed customers. However, spending the significant proportion of your delivery budget on rich implementations of this type of feature is unlikely to give businesses a significant advantage over their competitors.

During and after the platform migration a business should always try and find ways to innovate and uncover features that give them an advantage over the competition.

As described in the Kano Model for product development, these features ‘delight the customer when there, but do not cause any dissatisfaction when missing, because the customer never expected them in the first place’.

Innovation often requires experimentation, so the business should be looking to retain budget and resources to test and validate innovative ideas against real users, and must be prepared to develop, adjust, or drop these ideas once feedback is gathered

So for a business to take full advantage of their platform migration they need to find ways minimise the effort spent on non-differentiating features while retaining enough budget to experiment and innovate in areas that will genuinely differentiate them from their competitors

Key takeaways

Returning to our initial premise, viewing an ecommerce replatform as a simple ‘lift and shift’ exercise can have a significant impact on the success of a migration project. For businesses looking to take full advantage of what can be a costly and risky exercise, I recommend that you:

• Avoid reducing your migration project to a list of fixed requirements (e.g. a spreadsheet or MoSCoW document)
• Map user journeys through your system to uncover the features that deliver the most value
• Capture the ‘what, for whom, and why’ in user stories and use them to drive conversations during delivery
• Reduce risk by appropriately balancing technical implementation against business process change
• Find a way to release your new platform as early as possible, and learn from what real users tell you
• Reduce spend on commodity features so you can find ways to innovate later

About the author

Stephen is a project manager and coach with a track record of delivering complex ecommerce, content, and innovation projects for global brands. A passionate advocate for continuous improvement and self-organisation, Stephen also trains delivery teams and business stakeholders in Agile and Lean approaches.