# Replatforming: A Decision Framework for Ecommerce Teams A replatforming decision goes well when a small group agrees on the problem, the criteria and the order of decisions before anyone compares platforms or agencies. At #10 we use a five-step framework with ecommerce teams. Write down the problem, inventory what the store does today and score the options against weighted criteria. Then choose one of three outcomes (fix in place, replatform now, or plan for next year) and settle the decisions a partner can't make for you. The platform comparison comes late, and it's shorter for it. Most teams start the other way around. Someone sees a demo, a developer gets frustrated, a competitor relaunches, and the conversation jumps to which platform and which agency. That skips the questions that decide whether the project goes well: what exactly is broken, what the store does that nobody has written down, and who gets the final say. A note on the word, since it means two things. In cloud computing, replatforming is one of the standard cloud migration strategies. AWS, for example, lists it alongside rehosting and refactoring among its strategies for moving workloads to the cloud. There it means moving an existing application to a new environment with modest changes, such as handing the database to a managed service from the cloud provider, without rewriting the application code. In ecommerce, replatforming involves something bigger: moving the store, its data and its integrations to a new ecommerce platform. The decision discipline is much the same for both, but this guide is about stores. This guide is about running the decision. Whether a move makes financial sense is a separate question. Our companion piece, [ecommerce replatforming: when it is worth it, and when it is not](/ecommerce-replatforming-when-its-worth-it/), covers it and includes an estimator for the cost of staying versus the cost of moving. ## Who should make the replatforming decision A platform touches every team that handles an order, so the decision needs input from all of them. It still needs one owner. Committees are good at listing concerns and bad at choosing between them. | Role | What they own | The question they answer | |---|---|---| | Owner or GM | The final call and the budget | Is this the best use of the money this year? | | Ecommerce lead | The store day to day | What breaks, and what can't we change ourselves? | | Operations | Orders, inventory, fulfillment | What has to keep flowing on launch day? | | Finance | Payments, tax, accounting | Does it pay back, and do the books still reconcile? | | Marketing and search | Rankings, email, promotions | What do we risk losing, and how do we protect it? | | Developer or agency | What's custom and what's feasible | What will this take, and what should we retire? | Write the owner's name at the top of the decision document. Everyone else is an input, and that's not a small role: the operations and finance answers are usually where the real scope of the project turns up. ## Step 1: Write down the problem, not the solution "We need to move to Shopify" is a solution. The problem statement is the thing that would still be true if nobody had heard of Shopify. Good ones are specific and checkable: - Our platform version stops getting security patches on a known date. - Every promotion takes a developer and two weeks. - We want to sell wholesale, and that means custom code where we are. - We spend more on keeping the store running than on improving it. Then test each statement. If it would go away with a fix on the current platform (a faster theme, a repaired integration, a redesign), it belongs on a fix-in-place list, not in a replatforming case. Only the problems that survive that test count toward a move. ## Step 2: Inventory what the store does today This is the step that most often gets skipped, and the one that most often comes back during the project. A store that has run for years does far more than its homepage suggests, and much of it lives in custom code, extension settings or one person's head. Our own example is the Magento store we ran for six years for a premium California olive oil and wine brand. Before the move to Shopify Plus, the list included wine-shipping compliance checks, a wine club with stored cards and batch allocation orders, order routing between a third-party fulfillment center and pickup at the ranch, dozens of promotion rules with member and non-member pricing, product reviews and a long-running email setup. Each of those needed a decision about where it would live on the new platform, and some needed a decision about whether it should live anywhere. For each item, write down what it does, who relies on it and where it could land: | What the store does today | Where it could land on Shopify | Decide early because | |---|---|---| | Custom checkout rules | Checkout Extensibility and Shopify Functions | Checkout can't be edited directly | | Wholesale pricing | B2B on Shopify Plus, or an app | It affects which plan you need | | Subscriptions | A subscription app | Saved cards move between processors | | Membership or club pricing | A membership app | Discounts and members interact | | Order routing | Locations and Shopify Flow | The warehouse feed depends on it | | Promotions | Built-in discounts or an app | Launch-day promos must work | | Inventory or ERP feed | The existing connector, reconnected | Orders stop if it breaks | Every item ends up as one of four things: a built-in feature, an app, custom work, or retired. Custom work is where to be most skeptical. Some old code can be refactored into an app or a Shopify Function; some of it only existed to work around the old platform and can go. The retired list is worth as much attention as the rest. Moving a feature nobody uses costs the same as moving one everybody does. Our [replatform check](/labs/replatform/) gives you a head start on the list: it reads your store's homepage, tells you what it runs on and flags apps it can see from outside. ## Step 3: Score the options against weighted criteria We only build on Shopify, so we're not neutral about where a store should go. That's exactly why the scorecard puts "stay and fix" next to "move" and scores both on the same criteria. A framework that can only produce one answer isn't a framework. Agree on the weights before anyone scores anything. The simplest method is to split 100 points across the criteria as a group, then score each option from 1 to 5 against each one. | Criterion | Scores 1 when | Scores 5 when | |---|---|---| | Support horizon | Support ends soon, or the upgrade is a rebuild | Supported for years, with a clear upgrade path | | Cost to run | Hosting, patches and upkeep keep growing | Predictable fees and little upkeep | | Team independence | Everyday changes need a developer | The team handles promos, pages and launches | | Channel fit | Wholesale, subscriptions or shops need custom code | The channels you need are built in or one app away | | Integration risk | Several fragile connections to rebuild | Connectors exist and are well understood | | Search risk | Messy URLs, no redirect history | Clean URLs and a complete redirect map | | Disruption | No quiet window, no staff time | A slow season and someone to own testing | One note on the cost criterion. Shopify is a hosted SaaS platform that runs as a managed service, so the cloud infrastructure, security patches and version upgrades are Shopify's job rather than yours. That usually changes the cost-to-run score more than anything else, and it's worth checking against your own invoices rather than taking anyone's word for it, ours included. The scores matter less than the conversation they force. When operations scores integration risk a 1 and the ecommerce lead scores it a 4, you've found a gap in shared knowledge, and it's far cheaper to find it now than in week six of a migration. ## Step 4: Choose one of three outcomes A replatforming decision has three honest outcomes, not two. "Not yet, but planned" is often the right answer, and it's different from "no".
Three outcomes of a replatforming decisionFirst question: is support ending, or is the next upgrade a rebuild? If no, ask whether a move pays back within about three years; if it doesn't, fix in place. If support is ending, or the move pays back, ask whether there is a quiet window before your next peak. If yes, replatform now. If no, plan for next year.Support ending, or is thenext upgrade a rebuild?Does a move pay backwithin about 3 years?Is there a quiet windowbefore your next peak?NoYesYesNoYesNoFix in placeReplatform nowPlan fornext year
A move needs a reason (support ending, or a payback you trust on your own numbers) and a window to do it in. Without the reason, fix in place. Without the window, plan it for next year and start discovery now.
**Fix in place** when the problems that survived step 1 are specific and the platform has a supported future. Put the fixes on a schedule and revisit the decision in a year, or sooner if support news changes. **Replatform now** when there's a clear reason and a realistic window: enough months before your next peak season to build and test, then launch without rushing the last weeks. **Plan for next year** when the reason is real but the window isn't. This is the outcome teams most often skip, and it's the one that saves the most money. Use the time well. Run discovery, clean up the data and retire the features you don't need. Fix the worst problems on the current store too, so the move itself is smaller when it starts. ## Step 5: Decide these before you choose a partner Some decisions belong to you, not to whoever does the work, and making them first is how you choose the right partner. Settling them before you talk to agencies makes proposals comparable, because everyone is pricing the same project. - **What data moves.** Products and customers, certainly. How many years of order history? Product reviews, blog posts, gift card balances? Each one is a line in the scope. - **What gets retired.** The features from step 2 that won't make the trip. - **Who signs off on search.** Someone on your side approves the redirect map and owns watching Search Console after launch. We cover what tends to slip through in [what gets lost in a Shopify migration](/shopify-migration-what-gets-lost/). - **Payments and subscriptions.** Customer passwords can't be carried between platforms, and saved cards move between payment processors rather than in a file. Decide early who talks to the processors and your subscription provider. - **The launch window and freeze.** Pick the quiet period and work backward. For most stores that means launching well before the holiday peak, or after it. Our [Black Friday guide](/black-friday-ecommerce-strategy-guide/) has a timeline that works backward from the sale. - **Who runs the store afterward.** A partner who builds and leaves, your own team, or a partner who stays. Decide it now, because it changes how the store should be built and documented. - **The budget range, including the running costs.** Shopify's plan and app fees sit outside the project and belong in the same spreadsheet. Then, when you talk to partners, ask about their migration approach rather than which platform features they like. You want to hear about a test batch of data on a staging store, a review step and a full import checked against the source. Then a redirect for every old URL, test orders on real phones, a cutover in your slowest hours and someone watching orders and search after launch. That's how our [Shopify migration service](/what-we-do/replatforming-to-shopify/) runs, and it's a fair bar for anyone you talk to, whoever you choose. Most migration best practices come down to the same thing: nothing goes live that your team hasn't checked on a copy first. ## How to sequence the move once you've decided The order of work is what keeps a store selling through a replatform. Teams that choose to replatform often focus on the launch date; the migration process before it matters more. For the olive oil and wine brand, the project ran from January to August 2020 while the Magento store kept taking orders. The sequence we use today looks like this: 1. **Discovery.** The inventory from step 2, turned into a plan with owners. 2. **A test batch.** A sample of products and customers, with their orders, moved to a staging store and checked by your team. 3. **The build.** The theme and apps, plus the integrations, built against the test data. 4. **The full import and the redirect map.** Counts and samples checked against the old store. 5. **Testing.** Real orders through checkout on phones and desktop, plus tax, order routing and the inventory feed. 6. **Cutover.** The domain switch in a quiet hour. 7. **The first weeks after launch.** Orders and integrations watched daily, Search Console too, and fixes made quickly. Plan the launch week itself too. For that brand, launch included activation emails to existing customers and club members so they could set up their new accounts, promotions recreated in the new store and analytics switched on at launch. Small things, but they're the ones customers notice first. The full story is in the [case study](/our-work/mcevoy-ranch/). ## Questions ecommerce teams ask about replatforming ### Who should be involved in a replatforming decision? The owner or GM makes the call, with input from the ecommerce lead, operations, finance, marketing or search, and whoever knows the code. Name one decision owner. Operations and finance usually surface the scope that a storefront-only view misses. ### How long does a replatforming project take? Replatforming typically takes longer than teams expect, mostly because of the decisions, not the data. For our work onto Shopify, smaller stores usually take 8 to 14 weeks. Stores with integrations, wholesale, subscriptions or custom checkout rules take several months, and large or complex stores longer. The olive oil and wine brand's move from Magento to Shopify Plus launched in under eight months. ### When is the best time of year to replatform? After your peak season, or early enough before it that the last weeks aren't rushed. For most retail stores that means working back from the holidays and avoiding a launch in the fall. If the window has already passed, plan for next year and use the time for discovery and cleanup. ### What should we ask a replatforming agency before we hire them? Ask how they run a move step by step, what they've moved before and from which platform, how they handle redirects and Search Console after launch, and whether they stay on afterward. Ask them to name what they'd retire, too. An agency that wants to rebuild everything hasn't looked closely at your store. ### Do we need Shopify Plus, or will standard Shopify do? It depends on the inventory from step 2. Shopify Plus has B2B built in (company accounts, price lists, payment terms and order minimums) and suits stores with several regions or custom checkout rules. On other plans, an app usually covers wholesale. Decide it from what your store does, not from the size of the brand. ### Does the framework change if we migrate from Magento or WooCommerce? The framework doesn't; the inventory does. Magento stores tend to carry custom modules and extensions. WooCommerce stores raise a separate question about whether WordPress keeps the content. See our guides to [Magento to Shopify migration](/magento-to-shopify-migration/) and [WooCommerce to Shopify migration](/woocommerce-to-shopify-migration/). ## Bring the inventory to the first conversation You don't need a finished scorecard to talk to us, or to be sure you're ready to replatform. Run the [replatform check](/labs/replatform/) on your store, write down the problem statements from step 1, and start the inventory from step 2, even if it's rough. Then [talk to #10](/contact/). We'll go through it with you and tell you which of the three outcomes we'd pick, including when the answer is to fix it where it is. Human version: https://nr10.com/replatforming-decision-framework/