Ecommerce replatforming checklist: 9 phases from audit to post-launch

Replatforming means moving your online store from one ecommerce platform to another, along with its products, customers, orders, URLs, and every app and integration plugged into it. Most projects run through the same nine phases:

1. Audit

2. Platform selection

3. Planning

4. Data migration

5. SEO migration

6. Integrations

7. Testing

8. Launch

9. Post-launch QA

This checklist covers each phase, who owns it, and the tasks teams most often find out about too late. The biggest one is customer service. Your support team answers the “where’s my order” and “why can’t I log in” questions on launch week, and their help desk, macros, and help center are wired to the old platform, so this checklist gives that workstream its own section.

Signs it’s time to replatform

Replatforming is expensive and risky, so it’s worth ruling out the cheaper fix first. A slow site might need image optimization and fewer apps. A clunky checkout might need a redesign on the platform you already have. Replatform when the limit is the platform itself:

• You’re paying developers to build workarounds for features that come standard elsewhere, like multi-currency, B2B pricing, or subscriptions.

• Your platform version is reaching end of life, or security patches have stopped.

• Peak traffic slows or breaks the site, and hosting upgrades haven’t fixed it.

• Total cost (licenses, hosting, apps, and developer hours) keeps rising faster than revenue.

• You can’t launch a new storefront, region, or channel without a separate build.

• Integrations with your ERP, order management system, or customer service platform need constant manual fixes.

If two or more of these sound familiar, start the audit below. If only one does, check whether an upgrade or a single new tool solves it.

The ecommerce replatforming checklist at a glance

The phases overlap. Data mapping usually starts while you’re still finishing platform selection, and SEO prep should begin the day you have a URL structure on the new platform.

Phase 1: Audit what you have and define requirements

Before you compare platforms, write down exactly what your current store does. Teams that skip this step end up discovering missing features after launch, when they’re hardest to fix.

• Apps and plugins. List every app, plugin, and custom script on the current site, what it does, and who uses it.

• Integration map. Map every integration: ERP, order management, warehouse or 3PL, payments, tax, shipping, email and SMS marketing, reviews, loyalty, subscriptions, returns, search, analytics, and customer service.

• URL inventory. Export a full list of URLs and pull your top landing pages by organic traffic and revenue from your analytics and Google Search Console.

• Performance baselines. Record current conversion rate, average order value, page speed, organic sessions, and checkout completion. You’ll need these to judge whether launch went well.

• Team interviews. Talk to each team that touches the store, including merchandising, marketing, finance, fulfillment, and customer service.

• Prioritized requirements. Sort what you need into must-haves, nice-to-haves, and things you can drop.

Ask your support team what customers complain about

Your support ticket history is one of the best requirements documents you have, and it’s easy to overlook during a replatform. Ask your customer service leader to pull the top contact reasons from the last 12 months. If 20% of tickets are about order tracking, the new platform needs clean, reliable order status data. If customers keep asking how to change a subscription, self-service account management should be a must-have. The support team can also tell you which workarounds agents use today that the new platform should make unnecessary.

Phase 2: Choose an ecommerce platform

With requirements in hand, you can compare platforms against your own must-haves.

• Total cost of ownership. Add up licensing or subscription fees, transaction fees, hosting, apps, implementation, and ongoing developer time over three years. A platform with a low monthly fee can cost more once you add the apps you need to match your current feature set.

• Architecture. A hosted SaaS platform handles hosting, security, and upgrades for you. A headless setup separates the storefront from the commerce engine, which gives you more design and channel flexibility but needs a front-end team to build and maintain it. Open source gives you full control and full responsibility.

• Integrations. Confirm there’s a supported, maintained connector for each system on your integration map, and find out who maintains it.

• Data portability. Ask how customers, orders, and subscriptions get imported, and what doesn’t transfer.

• Scalability. Ask for proof the platform handles your order volume on your busiest day of the year.

For smaller brands

Prioritize a hosted platform with a large app ecosystem and a migration path your team can run without an agency. Fewer custom integrations mean fewer things that break at launch. Check whether the platform has native tools or a vetted partner for importing customers and orders. If you’re moving from WooCommerce to Shopify, our WooCommerce to Shopify migration guide walks through that move step by step.

For mid-market and enterprise brands

Run a formal evaluation with weighted scoring against your must-haves, and involve IT, finance, and operations in the scoring. Ask vendors for reference customers in your category and at your order volume. Budget for a systems integrator, and plan the ERP and order management connections first, since they usually take the longest.

Phase 3: Plan the timeline and manage migration risk

Most replatforming problems trace back to timing and ownership: launching at the wrong moment, or finding out mid-launch that nobody owns the thing that just broke. Planning covers both.

• Pick your launch window around your calendar. Avoid your peak season and the weeks right before it. Google recommends scheduling a site move during a period of lower traffic when you can.

• Build a risk register. List what could go wrong, how likely it is, how bad it would be, who owns it, and the fallback plan. Revisit it weekly.

• Set a content and code freeze. Pick a date after which no new products, promotions, or site changes go live on the old platform, so the final data export matches what customers see.

• Plan a rollback. Know what you’d do if launch fails, and how long you’d keep the old platform running in parallel.

• Assign one owner per workstream. Data, SEO, integrations, testing, and customer service each need a named person who can make decisions.

• Pad the schedule. Data mapping and integration testing almost always take longer than planned.

Phase 4: Data migration

Data migration in ecommerce covers far more than products. Map each data type from the old platform’s fields to the new one before you move anything, and run at least one full test migration before the real one.

• Products. Titles, descriptions, variants, SKUs, images and alt text, categories, attributes, inventory, and pricing rules.

• Customers. Names, emails, addresses, marketing consent status, customer groups, and tags. Keep the email marketing consent field accurate, since you should only send marketing emails to customers who opted in.

• Orders. Historical orders let customers see their purchase history and let your team handle returns on older purchases. Import order matters: Shopify, for example, says to import products first, then customers, then historical orders, and to turn off new order notifications first so staff don’t get an email for every imported order.

• Passwords and accounts. Customer passwords are stored as one-way hashes, so they usually can’t move between platforms. Shopify says outright that you can’t migrate customer passwords from another store with a CSV and that you’ll need to invite customers to create new ones. On BigCommerce, customers imported without a password go through password reset. Plan the reactivation email campaign before launch.

• Subscriptions. Recurring orders are the riskiest data you’ll move, because mistakes turn into missed shipments or failed charges. Customer IDs and product IDs usually change on the new platform, and payment tokens may need to move if you’re also changing payment gateways. Ordergroove, for example, has merchants send ID mapping files, pauses order placement if the payment gateway is changing, and tells merchants to plan for roughly 60 to 90 days. Talk to your subscription provider early.

• Gift cards and store credit. Balances need to carry over exactly. Test redemption before launch.

• Loyalty points. Confirm balances, tiers, and history migrate, and that your loyalty app connects to the new platform.

• Reviews and user-generated content. Make sure reviews stay attached to the right products after product IDs change.

• Redirects and URL data. Start from the URL inventory you built in Phase 1 and add any URLs created since. You’ll need the full list for the next phase.

After each test migration, compare record counts between old and new, and spot-check a sample of customers and orders by hand.

Phase 5: SEO migration checklist

You need this phase even if you keep your domain. A new platform usually changes your URL structure (Shopify, for example, puts every product under /products/ and every category under /collections/), and Google treats changed URLs as a site move. Your templates, metadata, and structured data change too. Google says to expect temporary ranking fluctuation during a site move, and that it can take a few weeks or more for new URLs to replace old ones in results on a medium-sized site. You can keep that dip short and shallow with careful prep.

• Build a redirect map. Match every old URL to its closest new equivalent: products to products, categories to categories, and blog posts to blog posts. Don’t send everything to the homepage.

• Use permanent redirects. Google recommends server-side 301 or 308 redirects and short redirect chains.

• Keep redirects for at least a year. Google’s guidance is to keep them as long as possible, generally at least one year.

• Carry over on-page SEO. Title tags, meta descriptions, headings, image alt text, and structured data for products and reviews.

• Check canonicals and indexing settings. Staging sites are often set to noindex. Make sure that setting doesn’t ship to production.

• Submit a new XML sitemap in Google Search Console, and keep an eye on crawl errors and the Pages report for several weeks.

• Update internal links so they point straight to new URLs.

• Annotate your analytics with the launch date so traffic changes are easy to read later.

• Protect your top pages. Test redirects for your highest-traffic and highest-revenue URLs by hand before launch.

Phase 6: Integrations

Each integration on your Phase 1 map needs a plan: reconnect it, replace it, or retire it.

• ERP and order management. Confirm orders, inventory, and fulfillment status sync in both directions, and test edge cases like split shipments and partial refunds.

• Payments. Set up gateways, test each payment method, and confirm fraud rules carried over.

• Tax. Confirm tax calculations match for every region you sell into.

• Shipping and 3PL. Check carrier rates, label creation, and tracking number sync.

• Marketing. Reconnect email and SMS platforms, confirm flows still trigger (abandoned cart, post-purchase, win-back), and reinstall tracking pixels.

• Reviews, loyalty, returns, and subscriptions. Make sure each app supports the new platform and that data lines up with the new product and customer IDs.

Don’t forget your customer service stack

Customer service sits downstream of almost every system above, so it breaks quietly when they change. Here’s what to check:

• Help desk order data. Your agents see order details in the help desk through an integration with the commerce platform. Reconnect it to the new platform and confirm agents can see both new orders and migrated historical orders. If historical orders don’t come over, agents will be blind on every return or warranty question about an older purchase.

• Customer history. Customer records in your help desk are usually matched by email or a platform customer ID. If the platform customer ID changes, confirm conversation history still attaches to the right person.

• Help center articles. Search your help center for links to old URLs, policy pages, and screenshots of the old checkout or account pages. Update them before launch.

• Macros and saved replies. Agents’ canned responses often include links to order tracking, returns, and account pages. Every one of those links needs checking.

• Order and shipping notifications. Rebuild transactional emails and texts on the new platform (order confirmation, shipping confirmation, delivery, and refund). Confirm reply-to addresses route to your support inbox.

• Returns and exchanges portal. Reconnect your returns app and test a full return, from request to label to refund.

• Subscription management. Customers will contact support if they can’t find their subscription after launch. Make sure agents can look it up and make changes on the new setup.

• Chat and AI on the storefront. Reinstall the chat widget on the new theme, and reconnect any AI agent to the new order, product, and subscription data so it can still answer questions and take action.

• Agent training. Walk agents through the new admin, the account reactivation flow, and the known issues list before launch day.

Phase 7: Pre-launch testing

Test on a staging site loaded with your real migrated data.

• Full purchase flows. Place test orders with every payment method, discount type, gift card, and shipping option. Include guest and logged-in checkouts.

• Account flows. Test account activation, password reset, order history, and subscription management from the customer’s side.

• Devices and browsers. Check mobile first, then the browsers your analytics show customers using.

• Page speed. Compare against your Phase 1 baselines.

• Redirects. Crawl the old URL list and confirm each one lands on the right page with a single redirect.

• Integrations. Confirm test orders appear in your ERP, 3PL, marketing platform, and help desk.

• Customer service dry run. Have agents handle mock tickets for order status, returns, and login problems using the new setup.

• Accessibility. Check navigation by keyboard and screen reader, color contrast, and form labels.

Bugs at checkout cost you sales directly. In Baymard Institute’s survey of US shoppers who abandoned an order during checkout, 17% said the site had errors or crashed, and 18% left because the site wanted them to create an account. Test guest checkout as thoroughly as the logged-in flow.

Phase 8: Launch day

Launch day is mostly about confirming that everything you tested on staging still works with real customers and real traffic.

• Run the final data export and import after the code freeze.

• Switch DNS, confirm SSL is active, and remove any noindex settings.

• Place live orders with real payment methods and refund them.

• Confirm the redirect map is live and spot-check top URLs.

• Send the account reactivation email in batches so a flood of password resets doesn’t hit your support team all at once.

• Watch error logs, checkout conversion, and payment failures every hour.

• Keep a war room open with one person from each workstream, including customer service.

Staff up support for launch week

Expect a spike in contacts. The most common will be login and password questions, missing order history, “where’s my order” for orders placed just before the switch, and subscription questions. Schedule extra agent coverage for the first week, post a short FAQ on the new site about account reactivation, and give agents a known issues list that you update every day.

Phase 9: Post-launch QA for the first 30 and 90 days

Post-launch QA for an ecommerce replatform runs longer than most teams plan for. Problems with SEO, subscriptions, and integrations often take weeks to show up.

First 30 days

• Compare conversion rate, average order value, and checkout completion against your baselines every day for the first two weeks, then weekly.

• Check Google Search Console for crawl errors, 404s, and indexing changes, and fix broken redirects as you find them.

• Confirm the first subscription renewal cycle processes correctly.

• Reconcile orders, payments, and inventory between the platform and your ERP.

• Review support ticket volume and contact reasons each day. A spike in one reason usually points to a specific bug.

First 90 days

• Track organic traffic to your top landing pages against pre-launch levels.

• Ask high-value referring sites to update their links to your new URLs.

• Retire the old platform only after you’ve confirmed you no longer need its data, and keep a full export archived.

• Run a retrospective with every workstream, including customer service, and document what you’d change next time.

How Gladly fits into a replatform

Gladly connects to the systems that tend to change in a replatform, so your customer service setup comes along with the move. Gladly integrates with commerce platforms including Shopify, BigCommerce, and Magento, along with subscription tools like Recharge, Ordergroove, and Skio, returns apps like Loop, and loyalty programs like Smile.io.

Gladly organizes conversations around each customer, so agents see their full history in one place, with order details pulled from the commerce platform. With the Shopify and BigCommerce integrations, Gladly can look up orders, cancel orders, and process refunds for customers, which helps absorb the spike in order questions on launch week. If you’re on Shopify, our Gladly Shopify integration setup guide walks through the connection step by step.

Whatever platform you land on, treat customer service as its own workstream from the first audit to the 90-day retro, and launch week gets a lot quieter.