Time and again I have seen how e-commerce operators go into a platform replacement project completely unprepared for the most fundamental questions, which leads to problems at kick-off, during execution and in the end result in terms of time, quality and cost. Here I thought I would share some tips (the list could of course be endless) based on many years of experience running platform migrations in e-commerce.
I will try to explain the common problems that arise and what you should think about to avoid them, or at least minimise the negative effects.
The cliché is that a project is successful if the buyer considers it successful. That is usually how both the e-commerce operator and the platform vendor think. But the best projects are the ones where both come out satisfied, and the real stakeholder, the customer, shows their appreciation through purchases and transactions.
1. Appoint a project manager on the buyer's side
A problem I often see is that as an e-commerce operator you are not a particularly experienced buyer. How often do you actually procure and implement a new e-commerce platform? Every four years on average, perhaps? Not uncommonly, you put the operational head of e-commerce in as project manager from the buyer's side, and often that person is sharp on e-commerce but quite rarely on running projects. On top of that, the head of e-commerce often has their usual job to do: warehouse issues to handle, campaigns to launch, reports to deliver, content to produce for product copy, and so on.
By appointing an experienced project manager with domain knowledge who has time to work with the project on the buyer's side, you will save time and money. But above all, you can feel more confident that the end result actually delivers on the goals you set in terms of revenue and margin from the e-commerce operation. They can coordinate internal colleagues and external vendors, and make sure that everything that should happen actually does. It is a big advantage if the project manager also actually has experience of both e-commerce and e-commerce projects from before.
2. Have your product data in good shape
One thing I have spent a lot of time on is analysing the conditions for running an e-commerce project in the best way. What needs to be in place? In what order should different activities be done to work optimally? What are the causes of projects running into trouble?
One thing I have noticed as a constantly recurring problem is disorder in the product data. It can be that you do not have the product categories properly structured, that you really need to redo the product model, that you have perhaps not even enriched your products with images, copy and attributes necessary for customer conversion. If you do not have this when you start the technical implementation of a new e-commerce platform, the developers cannot work efficiently, and the end result of the project is shrouded in mystery until launch.
It is hard to build a product page if you do not know what should be shown on it, what the images look like, how many images there are, how long the descriptions are and so on. It is like coding blind. And it rarely turns out well, and leads to everything taking longer plus lots of emergency hacks at the end when you finally get real data. A slightly silly comparison: starting an e-commerce project without good product data is like shooting a film with a half-finished script. It rarely turns out well.
3. Test, test, test
It sounds like an open door to say you should test your e-commerce during development, but it is an enormous problem that as the buyer you do not test during the course of the project. My experience is that you often do not have time (see point 1 above), and that as the buyer you do not think it is worth testing something that is not yet fully finished and production-ready (see point 2). I have also encountered buyers who do not even feel they have any responsibility for testing: "we are paying good money to the vendor to do their job without mistakes." But buying and implementing a complex e-commerce solution is not the same as buying finished software off the shelf.
It is more the rule than the exception that the buyer only starts to properly test two or three weeks before go-live in a large platform project. That is a really bad time to discover fundamental issues in, for example, order integrations, product display, business logic, price structure and so on. If you are a couple of weeks from launch, the focus has to be formal final verification, without any big surprises.
Testing is hard. But it becomes easier and simpler if you start early. Or, put another way: the more you ignore it, the more expensive and worse it will be in the end.
4. Sort out with the vendor how go-live should work
The vendor wants to sell a project and can in the early sales and project phases be a bit afraid to complicate things by talking about go-live and what happens after go-live. Many times I have sat and realised that the partnership and the contract end in the same second you go live on Tuesday at 08:00. But what happens on Wednesday, then? How should bugs be handled? And if you decide that go-live should be a phased rollout over a month in different markets, how should that cost be handled? Do we have a warranty period in the contract? What can I demand of the vendor after go-live if I as the buyer have not tested and quality-assured during the project?
You avoid a lot of headaches (and endless negotiation meetings with finger-pointing) if you sort out what applies here before you even start the project. If both parties additionally have a pragmatic and solution-oriented mindset about solving problems in partnership, the journey will be so much easier.
Last final words: fixed-price projects are a really good foundation for really many problems and frustration on both sides, however smart it sounds on paper.
5. Think through what actually needs to be migrated
Everything must come along. Or?
Ask yourselves the question: "What needs to be migrated?" not ask "what does not need to be migrated?" are the foundation of an efficient e-commerce operation, but junk data is meaningless and often directly harmful.
Summary
Order and structure is, and has always been, the foundation of a successful project. As a buyer, you need someone who helps you structure the project, who also has the time and knows what is needed for successful e-commerce. Someone who ensures that everything needed is in the contract with vendors, and who knows what is unnecessary, too time-consuming, or what you can skip in that MVP launch. Someone who makes sure you actually carry out the activities that are really needed and can steer and guide your vendor of the technology project.
They call us project managers.