Ask anyone leading a digital commerce business what’s most frustrating about digital transformations and they’ll tell you it’s the process of replatforming from one commerce solution to another. Just the thought of undergoing a project of that complexity, cost and effort can elicit a long, drawn-out sigh from those in the room. While it can feel like a daunting and disruptive task (because it can be!), when a replatforming project is done well it can unlock growth opportunities that weren’t possible when you implemented your current platform eight years ago. I’ve learned that with the right approach, you can ensure your replatforming journey is a smooth one.
As the former VP of Ecommerce at Tommy Hilfiger, I know first-hand what this kind of endeavor entails, having worked on a multinational replatforming effort spanning multiple brands and shifting several disparate solutions to a single, updated platform. As “easy” and quick as many vendors claim it may be to migrate to a new solution, there are many aspects of the process — regardless of the platform — that no one tells you before you embark on the journey. By sharing the invaluable lessons I learned from my own experience, I hope to save others from potential headaches and pitfalls — because the reasons things go wrong are often really predictable and avoidable.
So, here are the top 10 things I wish I had known before beginning my ecommerce replatforming project:
Your biggest challenge heading into this project won’t be selecting a platform vendor, it will be gaining buy-in from your C-Suite and key stakeholders. In the past, projects like this required approval and involvement from a far smaller team of decision-makers, yet as the complexity and scale of replatforming efforts have grown considerably, it is now a much bigger endeavor (and investment) than it once was. Getting all your stakeholders on board and involved in the process from the very beginning is vital to success — if you don’t, you risk significant slowdowns or re-evaluations of the budget and goals when they become aware later on. In fact, over 70% of transformational change efforts fail due to a lack of sufficient communication and organization-wide buy-in.1 Granted, it isn’t always easy to gain a consensus on the project, but here are some tips to help you quickly get everyone on board:
Among the most critical decisions you’ll make in your replatforming project is selecting the right partner to help you through the process, and the right one will take the time to get to know your business and your unique needs inside and out. But it also goes the other way — you should plan to interview the system integrators (SIs) at the same time you’re meeting with platform providers so you really get to know your partners on the project. The SIs are so integral to the success of the project that you’ll want to consider not just the software, but the software and the SIs together. You’re not hiring a firm, you’re hiring individuals from that firm. So be selective!
To keep the project progressing smoothly and to avoid unnecessary holdups, it’s important to designate one (and only one) person on your internal team as the dedicated decision-maker for the project. This person doesn’t need to be involved in every single decision, but ultimately the decision-maker can make determinations in cases where there’s a 50/50 split or when a quick answer is needed. They will also be the primary point of contact for questions from your SI team, so be sure they understand that when conflicts arise, they always have one ultimate decision-maker to land on a solution.
Aside from your primary decision-maker, there are two additional roles to take note of who will have the greatest impact on your project. These are the Business Analyst on the SI team and your Project Manager. The Business Analyst can translate exactly what you need into requirements for developers, and a great one will be the difference between getting what you want and getting something that kind of resembles what you want. Having a great internal Project Manager will also help your team manage the numerous moving parts and requirements along the way. They’ll know the bounds of what they can handle themselves, what needs to be escalated, and can help to convey the tradeoffs of different moves — whether it’s worth pushing something to a second phase, or whether to push the timeline back to get something done now.
It’s important to recognize that “out-of-the-box” capabilities mean different things to different platforms and, in most cases, a one-size-fits-all approach will not, in fact, work for everyone. Your business is unique and you will undoubtedly have particular needs and requirements that need to be supported by the new platform. If there are “out-of-the-box” functionalities that you want to customize to your individual business needs (or to remove completely), ask early on how difficult it is to make those or other changes.
While these modern platforms are sophisticated — far more sophisticated and flexible than when you last went through this process seven or eight years ago — it can still be time-consuming to change or remove a built-in functionality. It’s important to be very, very specific on what your needs are and to see them reflected in a demo to gauge how your vendor will handle your specific requirements. You may find that some capabilities are worth the extra time and effort, where others you might do without. Using the “MoSCoW” method can help you prioritize your wishlist of capabilities:
Your replatforming project not only requires scoping for your commerce solution, but you also need to ensure you’re attaining complete system alignment among all your existing systems of record. A great way to get started with this is to hold a kick-off meeting involving all of the stakeholders who will be touched by this project, which in most cases will be a large group stretching across marketing, finance, distribution, customer service, legal and so on. Each of these stakeholders works with systems of engagement or record that need to be taken into account and assessed in terms of what will change or need to be re-integrated. This is also a great time to ask them what current issues they have with their systems or tools and see if there are ways to incorporate improvements during the replatforming process.
You’ll want to work closely with your SI to help you outline exactly what will be needed from each of the stakeholder groups over the course of the project and to establish clear expectations. There’s no way around it — you’re going to need help and input from each one of them, sometimes a lot of it. So be upfront and precise about what will be needed, and send them something nice at the end of the project to show your appreciation.
As I mentioned earlier, it’s critical to ensure your replatforming project remains closely aligned to your underlying business objectives, from start to finish. In many instances, it is the IT department driving this type of technology initiative when they are often oblivious to the broader needs and goals of the business. As much as we evangelize “customer-centricity”, it’s surprising how often that gets lost when it comes to technology selections and implementations. Yes, in the first phase of your replatforming journey you may have to make tradeoffs between functionalities that benefit your users and those that benefit the customer — this is a challenging transition and you need to ensure your team sees the immediate benefit of replatforming. But that doesn’t mean you should lose sight of the business goals and customer benefits ultimately driving the change in the first place.
The key here is to ensure the business objectives stay top of mind — even if this means creating posters outlining your project goals and plastering them to the walls. It’s easy to get bogged down in the gritty details, but having something to point to, literally, when your team is struggling for the right direction or grappling over various alternatives will help keep things moving toward the right end-goals.
While the initial instinct might be to complete the project as quickly as possible to lessen disruption and prove ROI faster, speed isn’t always a good thing and can jeopardize what you get as an end result. On the one hand, if things start moving more slowly than originally anticipated, you can always opt to scale back scope and push certain features out to a later time to keep your launch date. But in many cases, the best move is to simply push out your launch date to avoid backing yourself into a corner and sacrificing the functionality you’re going to wish you had.
When it comes to budgeting out a timeline, it can help to create a work-back schedule from your ideal (yet flexible) launch date. Include allotted time and target completion dates for important milestones, with smaller actionable checkpoints along the way. Two areas in particular that always end up taking a surprising amount of time are handling the catalog execution from your current system (and then loading it into your new system), and connecting the new platform to your company’s other systems, like your ERP, for example. You’ll also want to note any dependencies — tasks that can’t be completed until others are done — and factor those into your timing. With your major milestones, checkpoints, and dependencies mapped out, you can start assigning individual tasks to your stakeholders and project leaders so everyone knows exactly what is needed of them during each phase.
Even with a detailed work-back schedule, it’s important to remember these projects are complex and often take longer than you think. Whatever amount of time you initially budget for, it likely still won’t be enough, and that’s okay. The bottom line is you’re better off going into it with a flexible time frame to allow for a thorough execution that will maximize the impact of your new platform while also allowing for inevitable hiccups.
This brings us to my next point…
Replatforming often turns out to be more complicated than you may have first expected. Your existing systems might prove to be more technically complicated than was originally thought, or you might run into certain capabilities that require custom implementations. There will be things that run smoothly and then there will be those headaches that pop up unexpectedly and bring things to a screeching halt. This is precisely why it is important to set realistic expectations with your stakeholders from the get-go and make sure everyone understands there will be inevitable delays and bumps in the road — especially those stakeholders who don’t have a technical background. They will be eagerly awaiting the ROI from this project that’s costing a pretty penny and may be surprised to learn the kinds of challenges and bugs that can arise along the way, even as you approach go-live. It is critical to establish transparency and manage expectations from the start — and then remind them again, and again, and again — in order to keep confidence high and avoid frustration throughout the project.
You will likely be met with some resistance to change, because, after all, we as humans inherently hate change. As obvious as it may be to you that your organization needs a new, modern solution, there will be those who think the old ways are “just fine” and may push back. No matter how impeccably the new platform implementation goes, it will only be as successful as its adoption across the business. Establishing a change management strategy will help to get employees on board (and literally on-boarded) with the new platform. Here are some tips to get you started:
During the replatforming process, you will likely have to balance keeping functionality exactly like it was in your old platform or adapting to the way the new platform does it. While your SIs will have done their own round of testing, you will still want to conduct your own UAT (User Acceptance Testing) to ensure everything is running smoothly from a user experience standpoint.
Bonus item, but one that cannot be overlooked!
Nothing can be more disappointing and embarrassing than getting to the end of your replatforming project and going live just to find out that the system cannot tolerate the load. Or you go live and initially things seem fine, but when you reach peak periods the system falls over. Conducting a thorough, realistic performance test can help you avoid these pitfalls.
So there it is, the top things I wish I knew before embarking on replatforming ecommerce operations from my past life as a practitioner. What are the top things you wish you knew?
If you have questions or concerns about replatforming or want to see how VTEX can help? Reach out: [email protected].