You have a plan to replatform your ecommerce system, and you should give yourself a pat on the back... it's actually a good plan. You did your research and weighed your options carefully.
You know you're not out of the woods yet - the implementation hasn't even started - but if you have not prepared sufficiently for these nine "gotchas," your whole project could be torpedoed before launch. Keep these points in mind; your blood pressure will thank you.
If you have more than 500 SKUs, work with a 3PL for fulfillment, use any kind of ERP or sell (or want to sell) through third-party marketplaces like Amazon...tackle your product integration first.
If your company has 10 products with no size or color variations, sure, you could manually update all your product info in a new platform. But what happens when you have two hundred, a thousand, ten thousand, a hundred thousand products or SKUs?
If your product list is too big to manually enter within two workdays, you will need to create maps between spreadsheets or systems, test the import process and clean your dirty data. Then again. And again. And maybe again. This can take more time than you might think.
While porting over properly formatted product and inventory data usually "takes three clicks," the prep to get you there can take weeks or months. Don't underestimate the time required to do this. I've watched skilled implementers burn 16 hours trying to make something simple work, and it's rare to have just one issue.
Customizable products? Resizable products? Multiple warehouses? Deal with products first.
If you already have a gift card program, if you have store location(s) and an online presence, or if you want to integrate gift cards in any way...start investigating early.
Not all payment gateways are compatible with all gift card systems, and if you're mixing online and offline gift cards or physical and electronic cards, you'll need to decide which system controls the program and make sure it works across all channels. Because there are card balances held "on the books," you'll need to get your accounting team involved.
Don't wait to kick off the conversation. It can be trickier than it sounds, and may impact your selection of some core systems like payment gateways, POS systems and even ecommerce platform.
Transitioning from an older or proprietary platform to an open source or enterprise platform is a lot like renovating an old house (and it's not as simple as they make it look on HGTV). If you are connecting any systems you currently use with your new platform, you are at risk.
Some older ecommerce systems are held together by duct tape and hope, but look fine from the exterior. They may even operate effectively within certain circumstances. This is where a thorough discovery process by your replatforming team and someone with in-house institutional knowledge are key to success.
The gotchas you can find here may be incredibly subtle, but put a really damper on your plans. Can your warehouse system only accept TSVs, while your new system only exports CSVs? Sure, you can work around most any "mold in the walls" issues, but that takes time, and time is a fleeting, consumable commodity when replatforming.
There are ways to mitigate surprises in replatforming, but there is always a risk that a simple connection between two systems could require a much more extensive fix than expected. Exploration/sandboxing is necessary, especially if you are keeping some legacy systems and connecting them with new systems.
As part of your ecommerce replatforming plan, you probably already mapped out every system that connects to every other system... but you won't know - truly know - if they will all play nice until you try it. You can't always take the extension/plugin/platform developer's word for it, either: what they call "integration" is not necessarily what you call integration.
Your new ecommerce platform may not integrate with other current systems that you use - ERP, credit gateways, pick-and-pack systems, shipping modules, etc. No ecommerce platform is 100 percent system-agnostic with what it can connect to, but many have the flexibility to work with extant systems. The risk is putting all your eggs in an ecommerce platform before confirming that it will work with all the backend systems you need to keep.
Like an online dating profile, a sales pitch from any platform or SaaS vendor is likely to be their best foot forward. When possible, see a live demo with a real client's site to make sure it works the way you expect it to.
Case in point: "Yes, our payment gateway is 100 percent compatible with your new platform... we even have an extension for it."
Problem: "We thought you understood that all your customers would be redirected to a different site to complete their payment."
You'd rather have that conversation nine months before launch instead of nine days.
One of the first decisions in an ecommerce replatforming project is deciding the deadline... but the often-overlooked gotcha is every holiday and busy season between now and then.
Launching a new platform immediately before a large traffic event, big planned sale or critical sales period (think... Christmas) is generally not recommended, even with thorough testing and quality assurance (QA). If you know at the outset that your current site won't survive the holiday season intact, then it may be worth the risk, but proceed with caution.
Likewise, anticipate work slow-downs, inability to reach key decision-makers for key decisions and generally slower progress over the holidays. Working with a foreign development team? Better know their holiday schedules, too. Not every country celebrates the same holidays on the same dates (even Christmas).
Timing isn't everything, but it can derail your project if it's not considered carefully.
For the most part, you can conduct a thorough QA before your new platform goes live...but you can't test everything.
Sometimes real-world conditions can't be replicated in a development (dev) environment, and some problems don't rear their heads until the new platform is live. If you're working with a good development team, they can confirm settings are good to go, or set up sandbox implementations so you can get as close as possible, but you do need to have some contingency plans in place for launch in case something hits the fan.
Potentially untestable elements:
Do you have a completely separate team working on replatforming? Probably not, which means the team who maintains your current site, pushes growth initiatives, implements design, development, etc., will be distracted by the replatforming process.
Don't underestimate the operational strain that focusing on a major future project can put on current projects unless your team's time is carefully structured. That double-digit year-over-year (YOY) growth may slow when your star employees are spending 50 percent of their time prepping for the new platform.
That may help you grow significantly in the mid-to-long-term, but be aware that your quarterly stats may suffer unless you're precise in your team time management.
Even for intently goal-oriented people, it's possible to get caught up in the exciting possibilities that come along with a replatforming project. When moving from a limited system to a shiny new system with massive potential, it can be easy to put too much focus on the technology versus focusing on business solutions.
Replatforming opens up new possibilities for features, plugins and cool gadgets, but getting caught up in expanding the platform (before it's even launched) can distract from achieving the core business goals. Trying to add every new idea ahead of launch is a surefire way to experience delays, so think in terms of phases (even if "phase 2" is a week after launch).
It can be a great thing to press the pedal to the floor and barrel full speed ahead in a project, but one of the biggest gotchas in replatforming is not creating a "bus manual."
Simply put, a bus manual is the document the team can refer to if the person/people who know everything about the project get hit by a bus, win the lotto or are abducted by aliens. Constructing the document during the process adds only 5-10 percent to the overall time/attention burden, but it can save hours upon hours in the end.
One of the biggest opportunities ‚Äö and risks if it is not done ‚Äö with a new platform is to document the process and how to do basically everything from adding a product to troubleshooting the shipping integration to looking up an order for customer service purposes.
If you don't create a manual, you'll be inventing the wheel every time you need to do something post-launch (and you won't have any spare time for that immediately post-launch). Likewise, a manual will pay off in security, efficiency and cost savings in the short term and for years into the future. Skipping documentation is a real, but controllable, risk.
Don't let any of these gotchas get ya!
In a world full of unknown unknowns that come out of nowhere, these nine items are plannable and avoidable, so now they're knowns. While these aren't the only gotchas, they are the most universal and any one of them can sink your project or deal it a major setback.
Start early, plan thoroughly, and work with someone who has done it before. If something is going to break, break it with months of leeway. If a system just isn't going to work for you, find out before you build your whole project around it.
And most of all, keep your eyes open for potential problems lurking in dark corners. "I told you so" is a phrase that doesn't belong anywhere near your replatforming project.