Key Takeaways
- ECommerce replatforming refers to the process of migrating an online store from one eCommerce platform to another.
- This can be done for a variety of reasons, including outdated technology, limitations in functionality, or a desire to improve the user experience.
- Replatforming involves careful planning and execution to ensure that data is transferred accurately and that the new platform is optimized for the specific needs of the business. It can also involve significant investments in time, resources, and cost.
- Replatforming eCommerce websites can lead to improved performance, increased sales, and a better overall customer experience.
- URL map
- Every old URL, before launch
- Passwords
- The data that cannot move
- Open orders
- Finish them on the old system
- Dip
- Expect one. Plan the recovery
Introduction
ECommerce replatforming is a challenging process. It involves assessing the current eCommerce platform and making decisions to migrate to a new one. It is important for businesses to understand the implications of replatforming prior to taking any action.
A website and associated data that needs to be replatformed can severely limit the ability of businesses to compete within their market. To remain competitive, eCommerce retailers must assess their existing platforms and weigh the costs of replatforming versus staying put.
An effective migration process requires planning and an understanding of the potential risks associated with changing platforms. This article outlines when it may be time for businesses to consider replatforming and details the steps needed for a successful eCommerce platform migration.
What Is eCommerce Replatforming?
Ecommerce replatforming is an increasingly popular process of migrating a business’s online store from its existing platform to a newer, more efficient one. It is a complex and potentially risky venture for any business.
Replatforming requires careful consideration and planning in order to ensure a smooth transition with minimal disruption to the customer experience. To understand why eCommerce replatforming may be necessary and how to go about it, it is important to first consider the advantages of moving away from an existing platform and the steps involved in the migration process.
The Benefits of a New eCommerce Platform
Replatforming can provide several benefits for an online store for both your customers and your employees. These include improved scalability, better website performance, enhanced experience, greater flexibility with design features, access to new technologies and tools, as well as improved security measures.
By switching platforms, businesses can also benefit from reduced costs associated with hosting fees or subscription plans. They can also take advantage of specialized features that may have been unavailable on their previous platform provider.
Plan Carefully to Avoid Damaging Your eCommerce Store
Despite these potential advantages, however, businesses must be careful when considering replatforming due to its inherent risks. Migration requires significant time and resources as well as expertise in order to properly transfer data without any loss or corruption.
If not done correctly or thoroughly tested prior to launch date, the new platform could cause major disruptions in operations which would ultimately affect customers negatively.
The platform options, named
Naming platforms is more useful than another abstract evaluation framework, with the caveat that this market moves and a shortlist should be checked against current capability rather than reputation. The hosted commerce platforms, Shopify Plus and BigCommerce among them, remove operational burden and constrain you to their model of a transaction, which is an excellent trade for most consumer stores and a poor one where the commercial rules are unusual. Adobe Commerce, formerly Magento, gives extensive control and expects you to resource running it. Composable options such as commercetools assemble services behind your own integration layer, buying flexibility and billing you for owning the joins. Salesforce Commerce Cloud tends to appear where the organisation already runs Salesforce. A custom or heavily extended platform remains the right answer where a specific commercial mechanism is the reason customers stay. The criterion that discriminates fastest is not scale but how unusual your pricing, entitlement and approval rules are, because that is what hosted platforms handle least well.
Rule out the cheaper explanations before committing. A migration is the most expensive way to discover that the catalogue data was the problem.
When Replatforming Is the Wrong Answer
The most useful question a replatforming guide can raise is whether the platform is really the constraint, because in a meaningful share of cases it is not and the project will disappoint expensively. Three patterns recur. The first is a data problem wearing a platform problem's clothes: search is poor, recommendations are irrelevant and the catalogue is inconsistent, none of which a new platform fixes, because it will import the same attributes and produce the same results faster. The second is a process problem, where the complaint is that everything takes three weeks and the cause is an approval chain rather than software. The third is a single missing capability, which is sometimes obtainable as an integration or an extension for a small fraction of a migration. The honest test is to write down the three outcomes that justify the project and then ask, for each one, what would have to be true for the current platform to deliver it. If the answer is a fortnight of data work, do that first.
Write down the three outcomes that justify the project. If any of them could be reached without changing platform, reach it that way first.
3 Options When Replatforming eCommerce Sites
A company may decide to change platforms and host them in the same place, or they may change hosting locations during replatforming from their first eCommerce site.
- SaaS (Software as a Service): SaaS is a cloud-based eCommerce platform that is offered as a service by third-party providers. With SaaS, the provider hosts and maintains the platform, and users access it through a web browser. This type of platform is often subscription-based, and the provider typically handles updates, backups, and security.
- On-Premises: An on-premises (sometimes called "on-premise" or "on-prem") eCommerce platform is installed and runs on a company's own servers and infrastructure. This type of platform provides more control and customization but requires more technical expertise and resources to maintain. Companies that choose an on-premises platform are responsible for all maintenance, security, and updates.
- Cloud: A cloud-based eCommerce platform is similar to SaaS in that it is hosted by a third-party provider and accessed through a web browser. However, cloud platforms typically provide more flexibility and scalability than SaaS platforms. Cloud platforms can be public, private, or hybrid, and are often used by larger organizations or those with complex eCommerce needs.
Each platform type has its own advantages and disadvantages, and the choice depends on the specific needs of a business. SaaS is often the most cost-effective option for small businesses, while on-premises and cloud platforms are better suited for larger organizations with more complex needs.
What Is eCommerce Migration?
ECommerce migration, a part of eCommerce replatforming, is the process of moving an online store from one platform to another. The motivation for doing so can include a number of factors, such as wanting to upgrade technology, consolidate online stores to one platform, or transition away from a platform that no longer suits the business’s needs.
In any case, eCommerce migration requires careful planning and execution in order to avoid disruption.
ECommerce migration allows businesses to take advantage of powerful features and capabilities that may not have been accessible before due to outdated technology or unsupported platforms. This enables them to boost efficiency and productivity while providing customers with a better overall experience.
Why Do ECommerce Businesses Replatform?
Replatforming an eCommerce business is a strategic decision that requires careful consideration. There are several reasons why an eCommerce business might choose to replatform its existing system:
To Improve the Customer Experience
Replatforming can provide customers with a more user-friendly site, with faster page loads and improved navigation capabilities. It can also enable businesses to offer features such as personalized recommendations and product reviews, which can increase sales and loyalty.
To Remain Competitive
In the fast-paced world of eCommerce, staying ahead of the competition means leveraging technology to meet current market needs. Replatforming allows businesses to take advantage of new features such as mobile optimization and social media integration to reach more potential customers.
To Stay Up-to-Date
As technology evolves, so do consumer expectations for online shopping experiences. Replatforming ensures that businesses stay up-to-date with the latest trends in eCommerce, allowing them to remain relevant in an ever-changing marketplace.
To Reduce Costs
Replatforming can help reduce infrastructure costs associated with hosting, maintenance, and software upgrades by moving away from legacy systems to cloud-based solutions or Software as a Service (SaaS) models. This helps businesses save time and money while improving customer service levels.
Reconnecting the integrations, in the right order
Rebuilding integrations is usually the largest engineering line in a replatforming and it is scheduled as though it were one task when it is a series of separate negotiations with separate counterparties. Start with an inventory of everything the current store exchanges data with, which will be longer than anyone expects: the accounting or ERP system, the warehouse or fulfilment system, product information management, tax calculation, shipping rate and label services, payment gateway, marketplaces, email and customer data platforms, review collection, and any EDI trading partners. For each one establish three things. Who owns the connection, because a partner-supplied connector means their release schedule is now on your critical path. Whether it is bought or built, since a bought connector for the old platform is worthless and may not exist for the new one. And what it would cost to operate without it for a week, which is the question that produces a defensible reconnection order. Then reconnect in that order rather than in the order the integrations were originally built.
Order the reconnection by what you cannot trade without for a week, not by which integration was built first or shouts loudest.
SEO Migration: Where Replatforming Actually Destroys Value
More replatforming projects are judged a failure on search traffic than on anything else, and the cause is almost always the same: URLs changed and nothing told search engines where they went. A platform migration rewrites URL structure by default, because every platform has its own conventions for products, categories, filters and pagination, so a store with forty thousand indexed URLs can arrive at launch with forty thousand new ones and no relationship between the two sets. The old URLs continue to be requested for months by search engines, by links on other people's sites, by email campaigns and by bookmarks. Every one of those that returns a 404 instead of a redirect is a lost visitor and a lost ranking signal, and the damage compounds because rankings that took years to earn are reassessed from nothing.
The URL map, which is the deliverable that matters
Before launch you need a complete list of every URL the old site served, each paired with the single best destination on the new one. Build it by crawling the live site rather than by exporting from the platform, because a crawl finds what is actually reachable including the pages nobody remembered. Then add every URL that has ever received traffic or a link, from search console data, analytics and your log files, since many valuable URLs are no longer linked from anywhere and are still earning. Map each to a specific page, not to the homepage: a redirect to the homepage is treated as a soft 404 and wastes the signal entirely. Where no equivalent exists, choose the nearest category rather than the front door.
| Before launch | Why | How it is verified |
|---|---|---|
Crawl the old site | Establishes the real inventory of reachable URLs, including ones nobody knew about | Compare the crawl count against the platform's own export and explain the difference |
Add historic URLs | Pages with links or past traffic still carry value even when nothing links to them now | Pull from search console, analytics and server logs, then deduplicate |
One-to-one 301 map | A permanent redirect passes the signal; a redirect to the homepage discards it | Every row has a specific destination and the map has no blanks |
Preserve canonical intent | New platforms generate filter and pagination variants that compete with each other | Check canonicals on a sample of category, filter and paginated pages |
Carry hreflang across | Multi-market stores lose the wrong-language penalty protection if these break | Validate the return tags in both directions, not just outbound |
Sitemaps and robots | A staging robots.txt shipped to production is the classic catastrophic launch error | Read the live robots.txt after go-live, before anything else |
Keep the redirect chain short | Chained redirects lose signal and slow crawling, and migrations create them easily | Re-crawl the map and assert every entry resolves in one hop |
Expect a dip, and plan how you will read it
Even a well-executed migration usually sees a temporary decline while search engines recrawl and reassess, and the useful preparation is deciding in advance what would count as normal and what would count as a problem. Agree before launch which pages and which queries you will watch, capture a baseline, and set a date at which an unrecovered position becomes an investigation rather than patience. Without that agreement the first bad week produces panicked changes that make diagnosis impossible, which is how a recoverable dip becomes a permanent one.
Crawl the old site before anything is switched off. You cannot build the map afterwards.
Crawl the live site before anything is switched off or reconfigured, because the inventory of URLs cannot be reconstructed afterwards.
A redirect to the homepage is read as a soft 404 and throws the signal away, so every row in the map needs a specific destination.
The URL map is the deliverable that decides whether traffic survives
Every URL the old site served, crawled rather than exported, joined to historic URLs from search console and server logs, mapped one to one with no blanks and no chains, and verified against the new site before any traffic arrives. That is the work, and it cannot be done after launch.
Data Migration: What Moves, and What Turns Out Not To
The second place these projects fail is the discovery, usually late, that something everybody assumed would move cannot. Products, categories, content and media are the easy part and they are what gets scoped. The difficult items are the ones with security or financial state attached, and each of them has a standard answer that is much better known to specialists than to the people writing the plan.
Passwords cannot come with you
Customer passwords are stored as one-way hashes, and a new platform almost never uses the same hashing scheme, so they cannot simply be imported. The options are all imperfect: force a password reset for the whole base at launch, which costs you some customers and a support spike; implement a shim that verifies against the old hash on first login and rehashes, which works and requires the new platform to allow it; or let people sign in with a wallet or social identity instead. What matters is deciding early, because a forced reset for a large base is a communications project rather than a technical one.
Saved cards need the gateway, not the platform
Stored card details are held as tokens by the payment gateway and those tokens are usually specific to the merchant account and the integration. Moving them is a gateway-to-gateway migration that the gateways have to cooperate in, it is governed by card-scheme and PCI rules, and it takes weeks of lead time where it is possible at all. If you are changing gateway as well as platform, assume saved cards do not survive and plan for customers re-entering them. For a subscription business that assumption is existential rather than inconvenient, so establish it before choosing a gateway.
Orders, and the difference between history and open work
Historic orders are usually migrated as records for customer service and reporting, and they do not need to be functional. Open orders are different: part-shipped, awaiting payment, on backorder or in a returns window. The clean answer is almost always to finish open orders on the old system and start new ones on the new, which means the old platform stays available to staff for a period after launch rather than being switched off on the day. Trying to migrate in-flight fulfilment state is where teams lose orders.
The balances people forget
Store credit, gift card balances, loyalty points and subscription schedules all represent money or entitlement you owe customers, and all of them live in places that do not export cleanly. Subscriptions are the hardest because they combine a schedule, a payment token and a customer, so all three problems arrive together. Reconcile every balance before and after, to the penny, and keep the before figures, because the first customer to report a missing gift card balance will not be the only one.
List every item of data with money or identity attached, and get a specific answer on each before the plan is signed.
Ask what every plugin on the old platform stores. That question finds the balances and entitlements no export will include.
Reconcile every balance to the penny before and after, and keep the before figures, because the first complaint will not be the only one.
The Cutover: How Launch Weekend Actually Runs
Launch is a sequence with dependencies, and the two things that make it survivable are a content freeze and a rollback you have tested. The freeze is the unpopular one: from some point before launch, nobody changes products, prices or content on the old system, because every change after the final data export has to be reapplied by hand on the new one. Agree the freeze window with merchandising rather than announcing it, and make it as short as the data volume allows. Then lower the DNS time-to-live well in advance, so that when you do switch, the change propagates in minutes rather than a day, which also means a rollback propagates in minutes.
The order of operations
Final data export and import with the freeze in force. Deploy the redirect map and test a sample of it against the new site before any traffic arrives. Check the live robots.txt and the sitemap, in that order, because a staging robots file reaching production is the error that costs the most and is fixed in seconds if noticed. Switch DNS. Then place a real order end to end, including payment capture and the confirmation email, and confirm it arrives in the order management system and the accounting system. Only then tell anybody it is live.
What to watch in the first week
Server errors and 404s by URL, which is where an incomplete redirect map shows up first and is still cheap to fix. Checkout completion rate against the old baseline, hourly rather than daily, because a broken payment path is the one failure that cannot wait. Crawl activity and indexation, which will be noisy and should trend the right way. And the support queue, read rather than counted, because customers describe faults nobody instrumented.
Test the rollback before launch day, with the people who would run it. An untested rollback is a hope.
Agree the content freeze with merchandising rather than announcing it to them, because an unagreed freeze is a freeze somebody quietly breaks.
ECommerce Migration and Replatforming Checklist
It's time to take a look at an eCommerce replatforming checklist. It will cover everything from assessing existing infrastructure and technology platforms to creating a plan for transitioning data, content, and customers. It also includes tips on how to minimize disruption during the migration process. By following this checklist, businesses can ensure that they complete the migration as efficiently and effectively as possible.
The key benefit of migrating or replatforming is that businesses can take advantage of new features and technologies while improving customer experience. This checklist provides users with the essential steps required when making this transition, allowing them to take control of their eCommerce journey and achieve greater success in their new online store endeavors.
Consult Your Team
Ensuring a successful eCommerce migration and replatforming project begins with consulting your team. Establishing what the business needs are, understanding existing customers, and improving experience should be the primary focus of any team working on the project.
It's important to look at factors such as user experience, scalability, cost-effectiveness, and data security before making a decision on which platform to use.
It's essential to ensure that the new platform is able to meet all current and future requirements for customers and products. Team members must consider how migrating will affect existing customers and whether or not changes need to be made to enhance the customer experience.
By communicating regularly with everyone involved in the project, teams can identify potential issues early on and address them quickly. With careful consideration of all these aspects of eCommerce migration and replatforming, teams can ensure they make the best possible decision for their business.
Determine What Your Current Platform Is Missing
It is important to assess what your existing eCommerce platform is missing before making the decision to migrate and replatform. Although migrating to a new platform may seem like an appealing option, it’s important to consider the time, effort, and cost of migration.
To determine what features or functions your current platform is missing, you should analyze any user feedback that has been collected on the existing platform. This will provide insight into what features customers are expecting from your store, as well as any areas that need improvement.
You should also research other similar online stores and their platforms to gain more insight into potential features that could benefit your own store.
When assessing potential new features for your eCommerce website, think about how they could potentially increase customer engagement and loyalty, improve website speed and usability, or enable promotional activities such as discounts or loyalty programs.
Create a Request For Proposal
The process of creating a request for proposal (RFP) is an essential part of eCommerce replatforming and migration. An RFP allows businesses to evaluate the cost, timeline, and quality of services from vendors. Through a structured project management approach and clear expectations, businesses can make informed decisions about which vendor to choose.
When crafting an RFP for eCommerce replatforming or migration, companies should consider the following items: budget, timeline, service level agreement, security requirements, technical specifications, and resources needed.
To ensure that all parties have a thorough understanding of the project scope and objectives, businesses should provide detailed information in the RFP. This includes outlining any legal requirements such as privacy policies and data processing agreements.
ECommerce companies should include all relevant details such as project milestones or quality assurance criteria to ensure that the vendor's product meets standards. ECommerce stores should also include information on payment terms and conditions, such as when payments are due and how they will be calculated based on milestone completion or other factors.
Consider Each Platform
When considering eCommerce platforms, it is important to evaluate the current system and decide what capabilities should be migrated to the new platform. The eCommerce platform should support current processes and enable future growth.
It is important to understand how integrated the existing system is with other systems. Consider whether any customizations need to be ported over and if any data needs to be transformed for compatibility. Also consider what features can be enhanced on the new platform that is not available on the existing one.
The new platform should have robust scalability, reliability, and security capabilities. It should also provide a seamless user experience that drives customer loyalty and increases conversions.
Evaluate the features that are available on the new platform such as payment options, fulfillment methods, analytics tools, and marketing integrations. Also, consider how easy it will be to manage product catalogs and migrate store data and content updates on the new platform.
Watch For Hidden Costs
When migrating and replatforming an eCommerce website, it is important to be aware of hidden costs that can arise. These maintenance costs could include additional search engine optimization (SEO) efforts, unexpected website code modifications, or additional development team support.
Organizations should take a holistic approach to the migration and replatforming process by taking into consideration all potential costs before beginning. A comprehensive cost analysis can help identify any areas where extra work may be needed during the migration.
This could involve additional SEO efforts to ensure that the new site is properly indexed by popular search engines or coding tweaks to ensure the existing website's portability. It may also require additional resources from a development team if more complex changes are needed on the new eCommerce site platform.
Organizations should build in a budget for unexpected costs and plan for contingencies in their eCommerce migration strategy in order to minimize any financial surprises down the road. Taking a proactive approach will help organizations better manage their budgets and avoid potential frustrations associated with unanticipated expenses during the transition process.
Prioritize Your Integrations
The modern world is a complex place, especially when it comes to eCommerce migration and replatforming. Business owners must prioritize their integrations to ensure a successful transition. The truth is that the hidden costs of migrating from one platform to another can be significant and unpredictable.
To avoid potential pitfalls, savvy business owners will take time to assess what third-party applications and custom solutions are necessary for their new system before embarking on the process of replatforming.
It's important to consider the impact that third-party applications have on the migration process. For instance, if your current platform relies heavily on them for critical functions such as shipping or payment processing, you'll need to make sure that those third-party apps are compatible with your new eCommerce platform.
Any custom solutions developed for your current platform must be ported over or re-created in order for them to work after the migration.
Hire an Integration Team
When it comes to eCommerce migration and replatforming, an important step is to hire an integration team. An integration team should have the expertise and experience needed to ensure a successful migration process. They will be responsible for overseeing the eCommerce data migration and ensuring that all migrations are complete and accurate, as well as CRM or ERP integration.
The integration team should include both technical and non-technical personnel who can assist in areas such as project management, business analysis, quality assurance testing, data mapping, and new eCommerce site training. Having the right people on board is essential to ensuring that the entire process is completed successfully.
In addition to hiring an experienced integration team, it is also important to make sure that they have access to the necessary tools and resources they need to make the transition as smooth as possible. This includes access to clear documentation on how the eCommerce platform works and what processes are required for a successful migration.
By providing them with these tools, you can ensure that your eCommerce platform is migrated correctly without any disruptions or delays.
Design the New eCommerce Site
The design and development phase of the new eCommerce website requires careful planning in order to ensure a successful transition for your business. It is important to consider the interface, usability, content, and overall appearance of the site. High-end website design is a must to stand out from the competition.
It is essential to ensure that all eCommerce data is migrated correctly from the old site to the new one. The following checklist will help you ensure a smooth transition:
- Design a unique look and feel for your eCommerce website that meets customer expectations while maintaining brand recognition.
- Incorporate user-friendly navigation and an intuitive checkout process into the design of the website.
- Make sure all existing data is migrated correctly from the old system to the new one by testing functionality with sample orders and customers.
It is also important to think about security when designing your new eCommerce website. Ensure that your site has up-to-date encryption protocols in place to protect customer information and transactions.
You should also consider implementing fraud prevention tools to protect against malicious activity on your site. With careful planning and execution, you can create an effective, eCommerce sales platform that has all of the features necessary for success.
Conduct an SEO Audit
A key part of the eCommerce migration and replatforming process is conducting a thorough SEO audit prior to migration.
The purpose of this SEO solution is to review and evaluate the performance of your current website against best practices and competitor websites. An audit should analyze all aspects of your website’s SEO including its technical setup, content quality, keyword research, search engine visibility, and other factors that influence how well it ranks in search engines such as Google.
It's vital to know where you are with SEO on your previous platform so that you can transfer your current rankings to the new one. If you lose traffic, it's vital to find out why so that you can address the problem on your new eCommerce site platform.
Determine How Data Will Be Migrated
Once the SEO audit is completed and any necessary changes have been made, it’s time to determine how data will be migrated when replatforming an eCommerce store. This is a crucial step as it can help reduce costly errors and ensure that the replatforming process runs smoothly.
Data migration should be approached with caution, as there are several types of data that need to be migrated such as product pages, customer order information, inventory information, and other essential store data.
It’s important to ensure that all of the necessary data is transferred properly and accurately so that no information is lost or corrupted. To achieve this, businesses must consider which methods are best for their particular situation and plan out the migration process accordingly.
There are typically two approaches to migrating eCommerce store data: manual data migration or automated data migration. Manual data migration requires manually transferring each piece of information from one platform to another, while automated data migration involves using software tools to automatically move large amounts of stored data without any manual intervention.
Businesses should carefully evaluate their needs and resources before deciding which approach would suit them best. Automated tools may be more cost-effective in some cases but may not be suitable for more complex stores with intricate databases. Ultimately, businesses must make sure they select a method that meets their individual requirements while ensuring accuracy and reliability throughout the migration.
Test, Fix, Repeat
The concept of 'test, fix, repeat' is a common one in the world of eCommerce replatforming. This method allows for the continual optimization of a new platform's performance while ensuring that any issues encountered during the migration are identified and addressed quickly.
To ensure that this process is as effective as possible, a comprehensive eCommerce replatforming checklist should be used to audit the store's performance before and after the migration. Such a checklist will help ensure that any issues are identified and fixed early on in the migratory process.
To make sure that no issues go unnoticed during an eCommerce migration or replatforming project, it is wise to use a performance auditing tool to track changes in the store's performance over time. This can help identify trends or potential problems that should be addressed before they become more serious problems down the line.
It is important to remember that eCommerce migrations and replatformings require both preparation and maintenance if they are to be successful. Having a clear plan in place for testing, fixing, and repeating throughout the entire migration is essential for achieving desired results with minimal disruption to the customer's experience.
Launch Your New Platform
The time has come to launch your new eCommerce site. As soon as the platform is live and operational, it's important to keep track of any issues that may arise.
Once you have completed these steps, it is time to begin the next stage in your eCommerce journey—go live! Utilizing effective launch strategies can help ensure a successful transition and make sure that customers are able to quickly start using your product or service without incident.
To maximize success, establish metrics and performance indicators before launch day that will give you an accurate picture of how well your new eCommerce store site is performing after launch. Finally, monitor customer feedback closely in order to ensure customer satisfaction and loyalty moving forward.
Why B2B Replatforming Is a Different Job
Consumer replatforming advice transfers badly to trade selling, because the things a B2B store cannot be wrong about are exactly the things a consumer platform treats as edge cases. Customer-specific price lists have to arrive intact and be verifiable, since a customer charged list price rather than their negotiated rate is a commercial incident rather than a bug. Credit limits, terms and outstanding balances have to be consistent with the accounting system on day one. Order history is a working tool rather than a record, because reordering from it is how a great deal of trade buying actually happens, so migrating history as read-only data quietly removes a feature. Account hierarchies and per-user permissions have to be rebuilt rather than imported, since no two platforms model them the same way. And any punchout connections into customers' procurement systems have to be re-established with each of those customers individually, which is a scheduling problem measured in months.
Verify a sample of real customers' prices on the new platform against the old, before launch. It is the single most valuable test available.
Pick ten real trade customers and check their prices on the new platform against the old before launch, line by line.
Worked Example: An Online Fabric Retailer Sold by the Metre
The pattern holds generally: the core catalogue migrates fine, and the damage comes from whatever was added around the edges over the years.
An online fabric retailer replatforms and meets three problems nobody scoped
Around 4,000 fabrics sold by the metre with a minimum cut, plus haberdashery sold as units, a trade account base, and eleven years of indexed pages.
The URL problem, found in time
The crawl turned up 61,000 reachable URLs against the platform's export of 9,000, the difference being filter combinations that had been indexed for years and were earning real traffic. Mapping those properly took three weeks nobody had budgeted and was the reason the migration did not lose its long-tail traffic.
The unit problem, found late
Fabric is sold in fractional quantities with a minimum and an increment, which the new platform supported for weight but not for length. The workaround adopted in a hurry was selling in units of ten centimetres, which worked and made every price on the site look wrong to customers until the display was corrected.
The password decision
Eighteen thousand accounts, no way to carry the hashes, and a trade base that logs in rarely and would not tolerate a reset email going to spam. They implemented verification against the old hash on first login rather than forcing a reset, which cost development time and avoided losing dormant trade accounts.
What went wrong anyway
Gift card balances. They were held in a plugin on the old platform with no export, and the figure was reconstructed from order history over a fortnight while affected customers were handled manually. Small money, disproportionate goodwill cost, and entirely predictable had anyone asked what the plugin stored.
What they would do differently
Inventory every plugin and what it stores before choosing the new platform, not after. The core data migration went to plan; everything that hurt was held by something bolted on to the old system.
Conclusion: Migrating eCommerce Platforms
Migrating to a new eCommerce platform is a complex process, requiring careful consideration of all aspects of the migration. It is critical to have a comprehensive checklist in order to ensure that all requirements are met and that the transition is successful. The checklist should include an assessment of current needs, a request for proposal, an SEO audit, data migration plans, and extensive testing and debugging.
With the right approach and planning, the eCommerce replatforming process can be a smooth one, allowing for further growth for any business.
Ultimately, with due diligence exercised through each step of this checklist, businesses will find themselves on the path to success with their new eCommerce platform. With proper preparation and the right implementation strategy, any organization can make the most out of its replatforming project while minimizing risks along the way.
A New eCommerce Platform with Integration in Mind
When it's time to replatform, why not do a little future-proofing while you're at it? The Clarity eCommerce Framework—CEF—was built with APIs in mind. That means you'll start with a robust platform that can add any (and all) software that you want to work with. This includes ERPs, CRMs, supply chain, inventory, shipping, payment hubs...the list is endless. In other words, you get to choose the perfect add-ons for your business instead of being stuck with ones that will simply make do. We'd like to show you exactly why CEF is an excellent choice during a complimentary demo and discovery session. It's a no-pressure meeting where we'll help you create a plan for your replatforming project. Get in touch today!
When it's time to replatform, why not do a little future-proofing while you're at it?
The Clarity eCommerce Framework—CEF—was built with APIs in mind. That means you'll start with a robust platform that can add any (and all) software that you want to work with. This includes ERPs, CRMs, supply chain, inventory, shipping, payment hubs...the list is endless.
In other words, you get to choose the perfect add-ons for your business instead of being stuck with ones that will simply make do.
We'd like to show you exactly why CEF is an excellent choice during a complimentary demo and discovery session. It's a no-pressure meeting where we'll help you create a plan for your replatforming project. Get in touch today!
Frequently asked questions
What does it mean to replatform?
Replatforming is the process of migrating a digital platform, such as a website or an eCommerce store, from one technology to another. This can be done for various reasons, including upgrading outdated technology, improving performance, or adding new features.
Replatforming typically involves transferring data and content from the old platform to the new one and may require redesigning or customizing the new platform to meet the specific needs of the business. It can be a complex and time-consuming process, but successful replatforming can result in significant benefits, such as increased efficiency, better user experience, and improved business outcomes.
What is an example of replatforming?
An example of replatforming is migrating an eCommerce store from one platform to another. For instance, a business may choose to replatform from Magento to Shopify because Shopify offers more user-friendly features or better integrations with third-party tools.
Replatforming involves transferring product data, customer information, and other essential elements from the old platform to the new one. The business may also need to redesign the storefront to match the new eCommerce platform's layout and functionalities.
Replatforming can be a significant undertaking that requires careful planning and execution to ensure a smooth transition and avoid any negative impact on the business.
What does it mean to replatform a website?
Replatforming a website means migrating the website from one technology platform to another. This could involve moving the website to a new content management system (CMS), a new web hosting service, or a new server architecture.
Replatforming a website often requires extensive planning and preparation to ensure that the transfer is smooth and that all website functionality and content are preserved. Replatforming a website can result in improved website performance, better user experience, and more features and capabilities.
What is replatform vs refactoring?
Replatforming and refactoring are two approaches to improving a software system, but they differ in their objectives and methodologies. Replatforming involves migrating an application or website to a new site platform or infrastructure while preserving its functionality and features. It aims to address issues related to outdated technology or limited capabilities by moving to a more modern and capable platform.
Refactoring, on the other hand, involves making changes to the code structure and design of the application or website to improve its performance, scalability, or maintainability. It aims to address underlying technical debt and improve the overall quality of the system. While both approaches can lead to better outcomes, they involve different levels of complexity and investment.
Will we lose search traffic when we replatform?
Some, temporarily, almost always. A permanent loss is avoidable and comes from one cause: old URLs that return a 404 instead of a redirect to a specific equivalent page. Build the URL map from a crawl of the live site plus every URL that has ever had traffic or a link, map each to a particular destination rather than the homepage, and verify the map against the new site before any traffic arrives. Then agree in advance which pages and queries you will watch and what a normal dip looks like, because the alternative is panicked changes in the first bad week that make diagnosis impossible.
Can customer passwords be migrated to a new platform?
Not directly. Passwords are stored as one-way hashes and platforms use different hashing schemes, so there is nothing to import. Three options exist: force a reset for the whole base at launch, which costs customers and produces a support spike; build a shim that verifies against the old hash on first login and rehashes, which works if the new platform permits it; or move people to wallet or social sign-in. Decide early, because a forced reset across a large base is a communications project.
Can saved cards be migrated?
Only with the payment gateway's cooperation, because the card details are tokens held by the gateway and usually tied to the merchant account and integration. It is governed by card-scheme and PCI rules and takes weeks of lead time where it is possible at all. If you are changing gateway as well as platform, assume they do not survive. For a subscription business that assumption decides which gateway you choose.
How long does an eCommerce replatforming take?
The variable that dominates is not the platform but the state of your data and the number of integrations. A catalogue that is clean and a store with two integrations is a different project from a catalogue with a decade of inconsistency and eleven connected systems. Two schedule items are routinely underestimated: building and verifying the URL map, and re-establishing any punchout connections into customers' procurement systems, which has to be arranged with each customer individually.
What does eCommerce replatforming cost?
Licence and implementation are the visible half. The costs that surprise people are data preparation, which is usually the largest single line and is proportional to how messy the current catalogue is, rebuilding integrations that the old platform had accumulated, and running both systems in parallel for a period after launch so open orders can be finished on the old one.
What is the difference between replatforming and a redesign?
A redesign changes how the store looks and behaves on the same platform. Replatforming changes the platform underneath, which may or may not change the design. Doing both at once is common and makes diagnosis much harder, because when conversion moves afterwards you cannot tell which change caused it. If the current platform is genuinely the constraint, replatform first and redesign afterwards.
How is B2B replatforming different?
The things a trade store cannot be wrong about are the things consumer platforms treat as edge cases. Customer-specific price lists have to arrive intact and be verifiable, because a customer charged list price instead of their negotiated rate is a commercial incident. Credit limits and outstanding balances have to agree with the accounting system on day one. Order history is a working tool rather than a record, since reordering from it is how much trade buying happens. Account hierarchies and permissions have to be rebuilt rather than imported. And punchout connections must be re-established with each customer individually, which is measured in months.
Do we need a replatforming agency, or can we do it in house?
In house works where you have people who have done it before and can be taken off other work for the duration, which is rarer than it sounds. The parts most often bought in are the URL mapping and post-launch search monitoring, the data migration for the items with money or identity attached, and the integration rebuild. The part to keep in house regardless is the decision about what the new platform must do, because nobody outside the business knows which of your current oddities are requirements and which are just history.
Related resources
Clarity runs the parts of a replatforming that decide whether it worked the URL map, the data, the cutover.
A complete URL map built from a crawl plus historic traffic and links, redirects verified one-to-one with no chains, the data nobody can migrate handled deliberately rather than discovered late, customer-specific pricing and credit verified against the old system before launch, and a cutover with a tested rollback. Building and migrating commerce platforms since 2007.
Get A Free Demo