Ecommerce migration and replatforming: the complete playbook

What is ecommerce migration?

Ecommerce migration is the process of moving a store’s data, content and operating workflows to a new platform, host or account. Ecommerce replatforming is a type of migration that replaces the software running the store. Moving a catalog between accounts on the same platform is a migration, even when the commerce engine stays the same.

For an operating retailer, the unit being moved extends beyond the website. An order connects a customer, a payment, a tax calculation, inventory, fulfillment and a record the support team can find. A product connects variants, identifiers, photos, attributes, reviews and the addresses buyers already use. Copying the product names leaves those relationships unresolved.

What does ecommerce replatforming mean in practice?

Replatforming replaces the commerce engine and reconnects the workflows that depend on it. Scope the engine, hosting, storefront, integrations, data model and URLs separately so suppliers price the same changes. A new theme on the existing backend is a different undertaking from replacing the backend, customer accounts and warehouse connection together. The distinction affects cost, responsibility and the rollback plan.

These labels describe change scope, with room for combinations. A retailer can rehost first, then replace its storefront later. A headless project can preserve the commerce backend while rebuilding presentation. Record each dependency separately so the contract never treats an unchanged backend as proof that every storefront behavior will survive.

The migration process, from decision through stabilization

The sequence starts with an inventory and acceptance criteria. Next come platform proofs, entity mapping, a representative import, integration work and a full rehearsal. The cutover follows a rehearsed order: control new writes, move the final changes, reconcile records, switch traffic, test transactions and reopen normal operation. Stabilization continues until named owners accept the results.

How to migrate ecommerce platformsOptimum7 · YouTube

▶

Give each stage an output somebody can reject: an approved requirement list, a mapped URL inventory, an import exception report, a reconciliation sheet or a signed launch checklist. “Migration complete” becomes useful when it names these outputs. The broader ecommerce website development guide explains the build decisions underneath the move; migration adds continuity for the business already trading.

Keep the decision log short and operational. For a product discontinued before launch, record the retirement choice, the old URL, any relevant replacement and the owner. For a customer record with conflicting email addresses, record the matching rule and the exception. These small decisions accumulate into the reliability of the launch.

Why do stores migrate, and what are the real signs you need to?

Replatform when the current implementation cannot meet a required workflow, such as account-specific pricing, at an acceptable operating cost. Other triggers include catalog relationships the data model cannot represent or integration failures that leave orders unfulfilled. Trace the business consequence to its cause before assigning it to the platform.

Adobe Commerce 2.4.6 reached the end of standard support on August 11, 2026, but covered Commerce customers have extended support through August 31, 2027. A support deadline calls for an entitlement and upgrade review. It does not by itself establish that the business needs a different commerce platform. Adobe's lifecycle policy distinguishes the support periods.

The comparison belongs to the individual store. A nightly stock update can be sufficient for a made-to-order catalog and unacceptable for scarce inventory sold across channels. Set the required freshness and oversell tolerance with operations, then test the integration. Buying a new frontend cannot repair a warehouse system that still publishes yesterday's quantities.

Separate a platform constraint from an implementation defect

A slow product page can come from images, third-party scripts, an inefficient query, cache configuration or the hosting environment. Reproducing the delay with an app disabled or a minimal template helps locate the cause. If the platform already supports the workflow, replacing it adds a migration to a problem a smaller change might resolve.

For a B2B store, test a realistic customer account with its price list, payment terms, tax treatment and order approval. A generic demo login cannot establish that those rules work together. Ask the operator who handles exceptions to run the test; the ordinary purchase path can pass while the work that consumes staff time remains broken.

Run the same discipline on operating costs. Name the recurring task, its owner, its measured effort and the likely cause. A high app bill can justify consolidation; a missing core capability can justify replacement. Keep the evidence attached to the particular problem so a platform sales demonstration cannot expand the project without answering it.

Should you replatform, or fix the store you have?

Choose optimization, rehosting, refactoring or replatforming by reproducing the bottleneck and testing the smallest intervention that meets the requirement. These four paths address different causes. A measured hosting limit favors a hosting investigation; an unsupported transaction model puts the commerce engine itself under review.

Each checked cause adds one observation to its route. If the current platform leaves an essential requirement unmet, prove that requirement before choosing a route.

For example, suppose a store's inventory integration fails under a repeated import, but the platform accepts the required stock updates. A controlled change to the connector fixes the test. That gives refactoring one observed cause. Check upstream stock accuracy separately.

Compare the complete cost of staying and moving

The “stay” option includes supported upgrades, maintenance and the cost of the unresolved requirement. The “move” option includes rebuilding current behavior, migration work, overlap, staff training and operation afterward. Compare them over the same period and with the same business requirement. A monthly platform subscription and a one-time project quote describe different quantities.

Include the work that a successful move would retire. If a connector is replaced, identify the support contract that can end and the date it can end. If the old application must remain available for historical invoices, retain its access and security costs. Savings only begin when a particular obligation ends.

Use a proof of concept to settle uncertainty

Ask a shortlisted implementation to handle the requirement that is hardest to reproduce: a configurable bundle, a negotiated B2B order, a partial return against a legacy order, or a multi-location inventory update. Define the expected result first. The output should include the test record, observed behavior and unresolved exceptions.

Keep the test small enough to abandon. A proof becomes a disguised migration when the team imports the full catalog and builds presentation before checking the decisive workflow. Put a stop condition in the test brief. If the destination cannot support the requirement, end that route while the cost remains bounded.

A small retailer can face a difficult migration because subscriptions or customization connect every order to external systems. A larger retailer with consistent data and a limited integration boundary can have a more predictable move. Use the failed requirement, dependency map and available operating capacity to judge risk.

Which platform should you migrate to?

Choose Shopify or BigCommerce when the proposed managed service can run your required workflows; evaluate Adobe Commerce when its extensibility justifies the operating responsibility. Choose headless only when separating the storefront solves a specific delivery problem. In every case, the deciding evidence is a completed business task on the proposed implementation.

Give every candidate the same test basket: your hardest product, an account with negotiated terms, a return against an old order and a stock change from the warehouse. Include the staff member who handles exceptions. A polished demo of an ordinary purchase cannot tell you whether the business you already operate will survive the move.

Shopify and Shopify Plus: test the managed workflow

Shopify deserves a place on the shortlist when you want a managed commerce service and can express the required catalog, checkout and account behavior through its supported configuration, applications and APIs. That can move infrastructure work away from the merchant. It still leaves your team responsible for data quality, application choices, integrations and the buying experience.

Use the Orders workspace below to test the operator's side of the move. Ask support to find the imported customer, item and fulfillment status, then follow the payment and timeline. Ask a merchandiser to check the corresponding product and variants. Count the systems they must open and the identifiers they must copy. Those steps matter more than how quickly an implementation team can import the first product.

Shopify · Orders workspaceShopify docs · Nov 2026

Verify that the same order links its line items, fulfillment, payment and customer history.

Where the migration can become harder

A managed backend does not guarantee a direct equivalent for a custom source workflow. Write down the proposed replacement for negotiated pricing, special payment terms, subscriptions, bundles and checkout changes. Identify the exact plan and applications in the proposal, then test them together. Request a supported solution for the exact combination your store needs.

For an external catalog, Shopify's productSet behavior makes synchronization design important: supplying a list can remove existing entries omitted from that input. Trial a product with several variants and update just one price through the proposed connector. Verify that the other variants remain purchasable and that warehouse identifiers still agree.

Shopify Plus and multiple brands

Distinguish upgrading an existing store from consolidating brands into a new organization or store structure. For the latter, list which catalogs, prices, customer records, domains and integrations remain separate. Run an order for each brand through the shared warehouse and verify that staff cannot see or alter the wrong brand's customer data. Ask the supplier to price and support that exact arrangement.

BigCommerce: preserve the difference between a variant and a choice

BigCommerce is another managed-service option to evaluate when you want the commerce backend operated for you while retaining responsibility for catalog configuration and connected systems. Its product model deserves a close look for stores that combine stocked variations with customization. The important question is which choices create a separately tracked item, and which simply change how the same item is prepared.

Consider a shirt offered in sizes and colors with an optional embroidered message. The size/color combination identifies inventory; the message needs to reach fulfillment without manufacturing a new stocked SKU for every possible text. BigCommerce distinguishes variants from modifiers. Test how the selected importer and storefront carry that distinction all the way into the order, price adjustment and warehouse instruction.

BigCommerce · Hoodie variantsBigCommerce Help Center · Nov 2026

XL

SKU 621E68891BB26_9206$35.50

2XL

SKU 621E68891BB26_9207$37.00

Verify that each size retains the SKU and default price shown in the capture after import.

What to test before choosing it

Import a small product family with one unavailable variant, a price difference and an optional customization. Compare the storefront selections with the control-panel records. Place an order, change its status and check the external fulfillment payload. A correct product page can conceal a modifier that never reached the system responsible for preparing the item.

Keep catalog and payment-history work separate. Creating a destination product does not transfer the ability to refund a charge made through the old payment arrangement. Name the historical-order path, the payment provider's responsibility and the support process for legacy returns. The official API reference distinguishes order records from transaction and refund resources; confirm the current interfaces used by your implementation.

For a multi-storefront proposal, ask who maintains channel assignments, pricing and domain behavior. Have a merchandiser change one item in the proposed setup and check every affected storefront. Compare the operational result and full quote with the same test on Shopify. Use the failed workflow to narrow the shortlist.

Adobe Commerce and Magento: decide what control is worth operating

Adobe Commerce and Magento Open Source warrant evaluation when your requirements depend on an extensible commerce implementation and your team can operate the resulting code, extensions and environments. Their commercial packages and operating responsibilities differ. Confirm the edition, hosting arrangement, support entitlement and named maintenance team before comparing them with a managed-service quote.

An existing Magento investment changes the question. Inventory the business rules that already work: configurable products, customer-specific treatment, tax logic, warehouse connections and extension-owned records. Decide which rules still earn their cost. Preserving every customization can carry old complexity forward; discarding one without a replacement can remove a workflow the business relies on.

Adobe Commerce · Products gridAdobe docs · Nov 2026

Check attribute set, stock and website assignment by SKU; matching product totals can hide errors.

A useful evaluation goes beyond the product count

Build one configurable product with its child SKUs, differing stock and the intended website assignments. Test it under the required customer and tax conditions. Then change stock through the real integration boundary. If an extension changes the price or eligibility, trace where that rule lives and how the destination will reproduce it. Reconciling a row count cannot establish that the same products can still be sold.

For an upgrade or a move between Magento implementations, check the supported migration-tool mapping independently from theme and module compatibility. A tool that transfers core records does not recreate a custom storefront or certify third-party extensions. Request a supported dependency list, an environment plan and a rehearsal using the mapping version intended for launch.

Include maintenance in the platform decision

The proposal should name who applies security updates, tests extensions, monitors jobs and restores service after a failed release. Review the lifecycle policy for the exact installed version and entitlement. An entitlement that buys more time is useful, but it does not resolve an unsupported module or reduce the work needed to move away later.

Headless and composable: choose the service boundaries

Headless separates the customer-facing storefront from the commerce backend. Composable extends that choice across services such as content, search and checkout. Neither term identifies a single vendor or admin. A store can keep the same backend and replace only its presentation, so this route may involve less database movement and more integration work than a conventional replatform.

WooCommerce is the concrete backend example here. Its real product editor below still owns a product's type, price and tax settings; a separate storefront must read and represent those settings correctly. Showing a different frontend does not remove the underlying WordPress, WooCommerce and extension responsibilities. The same ownership question applies when another commerce engine supplies the APIs.

WooCommerce · Product data editorWooCommerce docs · Nov 2026

The backend still owns product type, price and tax settings. A separate frontend must display those settings and complete the same purchase correctly.

Choose separation for a delivery requirement

A distinct storefront can be justified when several experiences share commerce services, or when frontend releases need an independent cadence. Write down the requirement first. If a theme change meets it, a new application boundary adds ownership without solving an additional problem. Include the full team and monitoring obligation in the comparison.

Use three concrete failure tests. Change a variant's price in the backend and measure when the storefront and checkout agree. Expire a customer's session and complete recovery without losing the cart. Make a required service unavailable and check that the buyer can recover safely and that any accepted payment has a usable order. Assign one owner to each failure across the boundary.

For a WooCommerce-backed implementation, inventory plugin-owned subscriptions, memberships and custom fields separately from core products. Confirm which fields the chosen API exposes and which behavior still runs in WordPress. The product API and review API describe distinct resources; test reviews and recurring orders through their own supported paths.

Compare the operating obligation before you sign

Put each proposal against the same failed workflow and the same operating period. The comparison names what the service runs, what your team still owns and the test that could disqualify it.

Shortlist the implementation that passes the indispensable workflows with an operating model you can sustain. Ask each supplier for the same scope, exclusions, recurring obligations and launch acceptance.

Shopify migration and Magento migration: the common routes, and what breaks on each?

A Shopify migration or Magento migration needs a route-specific entity map, extension inventory and URL plan. An importer transfers only its documented records and fields. The destination still needs a working implementation of the rules that used those records on the source store.

Maintain a route checklist alongside the shared launch checklist. Shared checks cover inventory totals, order flow and URLs. Route checks cover the source's particular models and extensions. This avoids assuming that a successful product import proves customer history, refunds or store credit will work.

Magento 2 to Shopify migration

Begin with an extension and customization inventory. For each item, identify the data it owns, the business behavior it supplies and its proposed destination. A bundle configuration can affect pricing, fulfillment and returns simultaneously. Treating it as descriptive product metadata can produce an attractive page with an invalid order.

Run an example through the whole chain, including cancellation or refund. Establish a crosswalk from old product and customer identifiers to destination identifiers so integrations can translate references. Preserve source identifiers in a controlled reference field or migration record when supported. Export the existing redirect inventory as well as currently active product URLs.

One developer-led destination path is Shopify's productSet mutation for the product record, with bulk JSONL imports when volume warrants asynchronous processing. Start with a single trial record, inspect returned user errors, and read the resulting product back before scaling. A completed product operation proves only that product job. Customer profiles, historical orders, reviews and subscription contracts need separately named transfer jobs with supported methods.

WooCommerce to Shopify migration

For a developer-led transfer, begin by reading one representative source product through WooCommerce's REST API. Its product documentation distinguishes a variable product's attributes from its variation references. Fetch the variation records too; the parent alone cannot describe each purchasable combination. Reviews are a separate entity in the review API. Keep plugin-owned subscriptions and memberships on a separate inventory.

WooCommerce migration · Variation identityWoo developer docs · May 2026

Map each variation’s SKU and destination ID alongside its parent.

Next, choose the destination path and write down its included entities. A supported merchant importer or migration application can be sufficient if it documents the records you need. A developer can use the productSet path above for catalog work. For that path, create the parent/options and intended variants in a development store, inspect errors, and retain the new identifiers before attempting related orders or reviews. Product creation alone covers neither of those jobs.

Consider a hypothetical blue shirt in size Small: source product 101, variation 301 and SKU SHIRT-BLUE-S. The destination needs the parent product, Color=Blue and Size=Small option values, and a purchasable variant carrying that SKU. Record the destination IDs against 101 and 301 in the migration crosswalk. Place a test order for that exact combination, then confirm its line reaches fulfillment under SHIRT-BLUE-S. Use the field names required by your selected importer.

Finally, trial the customer, historical-order and review jobs with their own supported methods. Map the review's old product reference to the destination product; map an order line's old variation reference to the new purchasable variant. Stop when a required entity lacks a supported path. Resolve it before a full import. Move buying guides and other useful WordPress pages through the content/URL plan separately.

Migration from Magento 1 to Magento 2

Adobe's Data Migration Tool configuration distinguishes supported source/destination editions and uses mappings for store customizations. This is a migration between implementations with different structures. Plan theme, module and integration compatibility independently from the transfer of core records.

Keep the configuration and mapping rules under version control while excluding credentials. The rehearsal should exercise the same mapping version intended for launch. If a late field change requires a new rule, repeat the affected import and reconciliation checks before accepting the release.

Magento migration · Configurable product childrenAdobe docs · Nov 2026

Check the parent ID separately, then compare each child SKU’s attributes and source quantities.

WooCommerce to Magento migration

A WooCommerce to Magento migration replaces the commerce data model and moves responsibility for a new implementation into the operating plan. Test variation attributes, tax calculations, fulfillment references and customer-order associations. Assign the team that will patch and maintain the destination before deciding the software's license terms make it cheaper.

Start with the product relationships the source already uses. A WooCommerce variable product and its variation records need an explicit destination attribute set and configurable parent/child structure. Decide which values identify a purchasable item and which are descriptive content. Preserve the source IDs in the crosswalk so historical order lines still point to the intended item.

WooCommerce to Magento · Attribute selectionAdobe docs · Nov 2026

After selecting variation attributes, match the generated child SKUs to the source records.

After creating the test family, compare its stock, tax treatment and storefront selections with the source. Place an order for one variation and check the exported warehouse SKU. Keep plugin-owned subscriptions and memberships on separate transfer jobs with explicit destination implementations and support ownership.

BigCommerce migration routes

For BigCommerce to Shopify, classify each source choice before creating destination options. Size Small can identify a stocked variant, while an engraving message can be a modifier on the same fulfilled SKU. Treating every modifier as a new stock variant changes the inventory model. Prove how the chosen destination implementation retains the message, price adjustment and warehouse SKU on a test order.

In the reverse direction, BigCommerce's documented V3 product path can create a product with its variants array. Create and read back that catalog sample first, retaining destination identifiers. Keep historical orders as a separate job: its archived official order reference distinguishes Orders V2 record operations from V3 transaction and refund resources. Recheck the supported current interface and validate historical currency, totals and status. A catalog transfer cannot establish that the destination can refund an old payment.

How much does an ecommerce migration cost, and where does the money go?

In a worked ecommerce migration budget, 360 hours at $125 an hour comes to $45,000 in labor, $54,000 in planned first-year spend and $63,000 in funding with a $9,000 reserve. Replace the example rates and allowances with written supplier quotes that specify quantities, deliverables and exclusions.

The planned one-time spend includes labor and $3,000 for overlap and training. Add the $6,000 first-year software allowance to get planned first-year spend. Hold the contingency separately so the team can track what it actually spends.

A real infrastructure price has a narrow scope

Amazon Lightsail pricing lists a Linux/Unix bundle with public IPv4, 1 GB of memory, 40 GB of SSD storage and 2 TB of transfer at $7 per month. Two months at that listed rate equal $14 before taxes and other resources. A small isolated rehearsal might use such infrastructure if its resource requirements fit.

That price covers the named infrastructure bundle. It excludes migration labor, ecommerce software, extra resources and production capacity planning. A hosted-platform project can use a different rehearsal environment entirely. Keep the line connected to a named environment and measured requirements so a cheap server price never becomes the project's total estimate.

Use effort scenarios to challenge a quote

Use those scenarios to ask what an estimate contains. A quotation for data migration should name entities, source access, mapping, trial imports, exception repair and the final update. A quotation for an integration should name the operation, direction, expected freshness, error handling and acceptance transaction. “Connect ERP” leaves the work ambiguous.

Hidden costs have owners and end dates

Budget staff time for product decisions, account exceptions, training and acceptance. Identify the overlap period for old hosting, applications and support contracts. Confirm the notice required to end each agreement. Historical order access can keep a legacy system operating after the storefront has moved.

Keep potential lost contribution separate from implementation spend. Model it with your own order volume, contribution per order and assumed disruption period. A hypothetical loss is a risk scenario with its own probability and response plan. Avoid adopting a universal traffic-loss percentage as the budget for every store.

Compare proposals against an entity-by-entity scope, named acceptance transactions and an explicit support window. Ask for written treatment of migration exceptions and post-launch fixes before using the total in a business case.

How long does a migration take?

An ecommerce migration with 360 hours of work takes 16 weeks in this planning example. The team delivers 30 hours per week for 12 weeks, with 4 additional weeks for approvals and acceptance on the critical path.

Delivery capacity means time available for this project after routine operations, meetings and other work. A developer employed full time can have limited migration capacity. Adding people also does not make every task parallel: a customer import can depend on an agreed account model, and an integration test can depend on a usable destination environment.

Each bar is a capacity calculation with explicit waiting assumptions. It assumes the stated work can be staffed at that rate and the additional waits sit on the critical path. Real tasks can overlap; a dependency schedule can shorten or lengthen the calendar result. Estimate from the actual work breakdown before setting a launch date.

Put acceptance and external access on the critical path

A missing sandbox credential can block integration work while the storefront looks finished. Request environments, payment test access, warehouse test records and required approvals during discovery. Name the person who can unblock each dependency. Track the deadline after which a delayed dependency changes the launch plan.

Reserve time for operators to test the job they perform. Customer support should locate a migrated order, confirm its status and handle the agreed return path. Warehouse staff should receive and process a destination order without manual interpretation. A successful developer test does not substitute for operator acceptance.

Rehearse the cutover as a timed sequence

Measure the initial import, final changes, reconciliation, redirect deployment and smoke tests. Establish what happens to orders placed during the transition. A controlled write pause, supported incremental transfer or queued event process needs its own tested procedure. Specify the point after which the new system becomes the authoritative order record.

Include cancellation steps in the rehearsal. If reconciliation fails before traffic switches, the team should know how to resume the source operation. If orders have already entered the destination, returning traffic to the source requires a plan for those orders. Restoring yesterday's database can erase valid business activity.

Choose a launch window with the operating team, considering order patterns, supplier availability and support coverage. Treat a date as conditional on passed acceptance tests. A failed refund or inventory reconciliation test justifies revising the date even when every design review has finished.

Ecommerce migration SEO checklist: how do you protect your rankings?

Preserve useful URLs and content where possible. Redirect a changed URL directly to its relevant replacement with a permanent 301 or 308. Return 404 or 410 when a page is gone and has no suitable replacement. Google advises keeping redirects generally for at least one year. These measures preserve the conditions for search processing; a migration still can produce ranking fluctuations while pages are recrawled and reindexed.

Build the source URL inventory from more than a storefront crawl. Include sitemaps, Search Console landing pages, analytics entrances, old redirect rules and business-owned campaign links. Record the destination and treatment for each important address. A crawl can miss an orphan page that still receives valuable visits or external links.

What to check before, during and after the move

1. Before the move: Export the URLs that drive search visits or sales. Keep a copy of the title, main content, canonical, indexability and product markup for each priority template. Include linked images or documents that will move.
2. In rehearsal: Crawl the old-to-new URL map. Check that preserved pages return 200 and changed URLs reach the intended 200 page directly. Compare product and category content, structured data, canonicals and, where used, hreflang with the baseline.
3. At launch: Retest public product, category and editorial URLs for staging blocks. Publish and submit the sitemap of new canonical URLs. For a move between domains or subdomains, check whether Search Console’s Change of Address tool applies after redirects are active. Path-only changes, HTTP-to-HTTPS upgrades and switches between www and non-www on the same domain do not use the tool.
4. After launch: Use Search Console URL Inspection on a sample of high-value destinations. Track indexed pages, crawl errors and clicks by page group so a category loss cannot hide behind healthy sitewide totals.

Use Google’s site-move guidance to check which steps apply when the public URL changes. For a backend move with stable URLs, prioritize response codes, indexability and content parity on the existing addresses.

Build a redirect map with explicit retirement decisions

Give every row the source address, destination, expected response, reason and owner. Test the final destination after following the redirect, including its canonical, indexability and content. A status checker that reports only the first 301 can miss a chain ending on a staging URL or a removed product.

Map a discontinued item to a replacement only when the replacement serves the same need closely enough to be useful. An unrelated destination can disappoint the buyer as well as confuse search processing. Keep a genuine missing page accessible and helpful to a person while returning an accurate status code.

Update internal links to point to final destinations. Preserve existing legacy mappings when the source already redirects an older address to the current one. Test those original addresses against the destination directly so a new migration does not add an unnecessary extra hop to every old link. Google's redirect documentation explains permanent and temporary treatments.

Control indexing and content changes independently

Check each template for accidental staging restrictions, canonical hosts, language relationships and sitemap output. Keep private staging environments appropriately protected. At launch, confirm the public destination is crawlable and the pages intended for search can be indexed. A copied noindex instruction can survive a visually successful release.

Separate required migration changes from optional rewrites and taxonomy redesign. If categories, copy, templates and URLs all change together, a later traffic decline becomes harder to diagnose. Preserve a baseline of high-value pages, then record each intentional change and the reason it belongs in the launch scope.

Choose phased or all-at-once rollout from the system boundaries

Google's site-move guidance distinguishes a small pilot from the eventual switch. It recommends moving small or medium sites together and allows larger sites to move in sections. A phased release also needs coherent checkout, accounts, inventory and orders across both systems. Plan a coordinated switch when running both would produce inconsistent business records.

A category pilot can test templates and redirect logic without representing every condition in a complete migration. Preserve that limitation in the launch decision. A quiet category does not exercise the subscription engine, localized pricing or the busiest warehouse integration unless those behaviors are deliberately included.

Traffic recovery has no universal deadline

Google describes a few weeks or more for medium-sized sites to begin reflecting new URLs, with larger sites potentially taking longer. This describes processing, with ranking variation possible. A quoted fixed recovery date or guaranteed loss percentage needs evidence for the particular store and scope.

“Google Search traffic fell to a trickle.”

Dana Hooshmand, first-person domain-move account, updated December 2023

Hooshmand describes a niche reference site's search-traffic collapse and eventual recovery after moving from a .net domain to .com. The cause remained unresolved. His first-person account is a caution about uncertainty in one domain change, with no measured estimate for ecommerce replatforming.

Diagnose a decline by page group and mechanism: unavailable destinations, blocked indexing, changed content, canonical choices, measurement errors or demand changes. Compare affected products and categories with their source baselines. Fix observed defects while retaining the change log, so the next intervention has a testable reason.

How do you move the data (products, customers, orders, reviews) safely?

Treat products, customers, orders, reviews and consent as separate migration entities, each with its own field map and reconciliation test. A product import cannot establish that a customer's order history is correct. Counts must be paired with relationships, monetary totals and representative records that operators can use.

Define the source of truth for each field before cleaning data. Product dimensions might come from a product information system, inventory from the warehouse and selling prices from the commerce platform. Resolve disagreements with the business owner. A migration can copy an inconsistency perfectly while making it harder to discover afterward.

Use a reconciliation report with source count, destination count, expected exclusions and unresolved exceptions for each entity. For orders, compare totals in the original currency and explain voided, refunded or excluded records. Matching counts can conceal duplicated rows or missing relationships, so inspect records alongside aggregate totals.

Customer passwords and logins depend on the destination

Customer profiles and authentication credentials have different migration paths. Password hashes can remain usable only when the destination and importer support the source format and verification process. Otherwise, plan an account activation or password-reset flow, or a supported passwordless sign-in experience. Never request a customer's existing plaintext password for migration.

The OWASP password-storage guidance explains secure hashing and the handling of legacy hashes. A reset or rehash strategy must fit the actual authentication system. Test identity matching, expired links, delivery of account messages and access to historical orders. Tell support staff which sign-in method customers will encounter on launch day.

Reviews require more than a star average

Carry product associations, dates, attribution and any supported verified-purchase status with the review. Confirm that the chosen export/import mechanism supports the data the business intends to retain. Reviews stored by a separate service can require an identifier remapping there, even when the commerce catalog transfer succeeds.

Compare a selection of product pages with their source versions, including a product whose handle changed. Confirm that reviews belong to the correct item and that structured ratings agree with the rendered review information. Preserve the original export in controlled storage so a later mapping correction can be traced.

Control sensitive exports and the final changes

Use scoped access and protected transfer/storage locations for migration files. Limit who can retrieve customer and order exports, define retention and remove temporary access when the work ends. Confirm the handling of payment tokens with the relevant provider. Treat each provider's supported transfer process as a dependency; a customer CSV does not establish payment portability.

Adobe's official configuration documentation includes TLS connection options for its migration tool. The operational lesson is to secure the transfer path as well as the destination. An isolated test environment should still have controlled access and appropriately handled records. Use synthetic or minimized records where a test does not require real personal data.

After the initial import, identify new orders, stock changes, customer edits and other writes that must reach the destination before it becomes authoritative. Run the agreed final-update process, then reconcile it independently. Keep the source available under controlled access for the agreed support period without allowing uncontrolled edits to diverge from the destination.

Will AI shopping agents still find your store after you migrate?

A platform move can affect product retrieval through changed URLs, crawl permissions, visible facts, structured data and merchant feeds. None of those alone guarantees an AI recommendation. Google's AI features require an indexed, snippet-eligible page and apply the established search requirements; a new commerce license provides no assurance of inclusion.

Before launch, compare the old and new product's title, brand, variant identity, price, currency, availability and purchasing conditions. Inspect the raw HTML response as well as the rendered page. A browser can display information after scripts run that another retrieval path receives differently. Google can render JavaScript, so crawler behavior requires a qualified test.

Partake Foods · product and variant dataNovember 4, 2026 · public Shopify product

Shopper view · six-box option selected

Raw response HTML · JSON-LD

ProductGroup: Crunchy Chocolate Chip

Brand: Partake Foods

6 Boxes: 34.99 USD · InStock

12 Boxes: 65.99 USD · InStock

Nested variants: 2 Product offers

Shipping / return-policy keys: absent from this JSON-LD

The captured page's ProductGroup contains two nested Product variants. Its six-box offer is $34.99 USD and its twelve-box offer is $65.99 USD; both state InStock. The product page response contained both offers when captured on November 4, 2026.

Shipping and return-policy keys were absent from the captured JSON-LD. Policies can also appear in page text, another page or a merchant feed. Check the page, policies and merchant feed together before concluding that an engine lacks the information.

Preserve variants and agreement across representations

A simplistic parser can read ProductGroup and miss the offers inside its variants. A migration test should follow the actual schema structure, checking the selected variation and its associated price. Compare the destination's page, structured data and feed for the same variant and currency, then change stock in a controlled test to confirm updates propagate.

Google's product documentation describes product variants and the complementary roles of page markup and merchant feeds. Follow the requirements of the relevant destination channel. The editorial work in writing product pages that AI answers can quote helps keep comparison facts understandable outside a particular template.

Crawler permissions need the correct agent name

OpenAI distinguishes OAI-SearchBot, used for search, from GPTBot, associated with model training. Those permissions are independent. A migration that copies a blanket bot restriction should be reviewed against the merchant's actual intent. OpenAI's crawler documentation describes the individual roles and notes that search can take about 24 hours to reflect a robots.txt change.

Inspect crawl instructions together with CDN and application behavior. An allowed agent can still receive a challenge, an error or an incomplete response. A robots rule alone proves neither retrieval nor inclusion. Record the exact URL, time, response and agent used for a reproducible access check.

Special AI files cannot substitute for accessible products

Google states that AI Overviews and AI Mode have no additional technical requirements or special optimization requirement beyond the established search practices. A proposed llms.txt file can be evaluated as an optional publishing experiment. It cannot replace indexability, accurate product information or the channel's supported feed requirements.

The published product-page research explains why product facts deserve a separate review, while the agentic commerce overview connects those facts to shopping workflows. Keep visibility tests separate from purchasing integration: a cited product and an executable checkout are different outcomes.

After launch, repeat a stable set of real buying questions in the engines you can access. Save the exact prompts, dates, visible answers and cited destinations, including empty citation results. Responses vary, so a single absence should trigger investigation and repeated observation, without becoming a claim that the migration caused a permanent loss.

How do you verify the migration worked (the first 90 days)?

Accept the launch against transaction, record and crawler tests, then monitor commerce and search separately through a defined 30/60/90-day stabilization plan. Those dates are review checkpoints. Assign an owner at each checkpoint and investigate search and commerce changes separately.

Start with a launch record containing the released version, import/mapping version, cutover time, reconciliation results and outstanding issues. Record who owns each exception and the condition under which it can be closed. Keep the original baseline so changes after launch can be compared with a known source.

During the launch window, separate a payment failure from a reporting failure. Compare the payment provider, commerce order and fulfillment event for the same transaction. If the records agree but analytics misses the purchase, fix instrumentation. If the money was captured and no usable order exists, the commerce incident takes priority.

Use explicit incident and rollback criteria

Set the stop conditions before launch with the business owner. Examples include an inability to accept the required payment method, failed order delivery to fulfillment or an unreconciled stock transfer that can create overselling. Assign the person who can pause traffic or writes and the person who can approve reopening.

A rollback needs a reconciliation procedure for activity received after the switch. Capture destination orders and payment references before restoring any source operation. Know which system can fulfill or refund those transactions. Returning the web traffic is only one part of returning the business to a coherent state.

Keep search and revenue measures distinct

Use Search Console to monitor indexing, clicks, impressions and affected page groups. Use the store's operational records and analytics for order flow, conversion and revenue measurement. Annotate promotions, stock changes, consent changes and tracking releases. A whole-site traffic total can conceal a category failure or a tracking break.

For AI visibility, retain the same prompt wording and distinguish a citation to an old URL from a recommendation of a different product. Resolve the old address to see what the buyer encounters. Fix a broken destination as a URL defect even if the assistant's answer has not yet refreshed.

The migration closes when its acceptance criteria have owners, evidence and an operating home. Hand over mapping rules, integration configuration, access inventories, redirect files and the recovery procedure. Retire temporary exports and accounts according to the agreed policy. The team maintaining the store should be able to diagnose a failure without reconstructing the project from messages.

Ecommerce migration questions, answered