WooCommerce Migration Cost: Price the Store, Not the Pages

Do you need your data moved, or your store rebuilt?

What those tools do not do is give you a store. They move rows. The storefront, the theme, the app functionality, the checkout behavior, the URL mapping and everything a plugin used to do all have to be reproduced on the other side, and that is what the tiers below price. This is the same distinction that makes published migration ranges look incoherent: a $200 data transfer and a five-figure replatform are both truthfully called a WooCommerce migration.

A third case is worth naming because it is the cheapest of all. If the complaint is speed or cost rather than capability, staying on WooCommerce and fixing what you have is usually the better trade, and our diagnostic for a slow WooCommerce store works through that before anyone quotes you for a replatform.

PandaCodeGen migration tiers

These are our own planning anchors, not a market rate. Which row you land in is decided by catalog size, how much data has to move, how many templates are genuinely different, and how many connected systems have to keep working. Subscriptions, regulated data and multiple markets fall out of the tiers entirely and get scoped separately.

What each tier covers is set out on our pricing page, the store-side scope is described under WooCommerce migration, and our project work shows what a delivered build contains.

The WooCommerce migration complexity matrix

Complexity is set by how many domains have to move and what evidence each one needs to be accepted, not by catalog size. Every row pairs an inventory with the proof that it arrived intact: counts, field mapping, an exception report and sampled parity. A quote that prices the inventory but not the acceptance evidence has priced half the job.

What is cheap to move and what is expensive

Cost follows the mechanics of what has to move rather than the size of the catalog, which is why two stores with similar product counts can land in different tiers. Anything that maps one to one into the new system is fast. Anything that depends on live third-party state, plugin-owned fields or years of accumulated relationships is where the hours go.

Order history is the line item teams underestimate most. Products and content map one to one. Orders do not, because they carry relationships across customers, line items, refunds and notes, and reproducing those relationships is different work from exporting a spreadsheet. A defensible approach is to migrate active customer accounts and a defined recent window of orders in full, then keep older records in a read-only archive instead of rebuilding them into the new system. Whichever route is chosen, write the window and the archive location into the scope.

Payment work deserves the same treatment. Reconnecting a standard gateway is bounded work: credentials, webhook endpoints, refund tests. Subscriptions, stored payment methods and processors with non-standard integrations have to be rebuilt and tested against real transactions before launch, which is a different order of effort from reconnecting keys.

What WooCommerce exports actually cover

WooCommerce core documents a built-in product CSV importer and exporter for supported core product data, with specific limits and mapping behavior. Woo also documents REST API access. Order and customer export can depend on an extension or a custom/API process. Extension-owned data such as subscriptions, bookings, memberships, add-ons or custom fields needs its own documented path. Export availability is not the same as target-system compatibility.

Why HPOS matters during discovery

High-Performance Order Storage uses dedicated WooCommerce order tables and has been enabled by default for new installations since WooCommerce 8.2, released in October 2023. Older stores may still be on the legacy posts tables, or on HPOS, or running both in sync, and one incompatible extension can block the switch. Before you extract any orders, find out which table is actually authoritative, whether the two are in sync, and which extensions still work.

Payments and subscriptions

Do not assume payment credentials or recurring tokens can be moved as ordinary CSV data. What is possible depends on your processor, your merchant account, whether the tokens can move at all, what your customers consented to, which subscription engine you use, and what security requires. Where you have agreed it, put the provider accounts in the client's name. Before you switch over, test that a payment authorizes, that it captures, that tax and shipping calculate, that refunds and cancellations work, that webhooks fire, and that the numbers reconcile.

Customer data and privacy

Export as little personal data as the job actually needs. Record the basis on which you hold it, encrypt it while it moves, limit who can touch it, keep a record of who did, and delete the temporary copies on a date you have already decided. Decide whether existing password hashes are safely compatible or whether users need a secure reset. The migration plan should say who is the controller and who is the processor, what happens if there is a breach, how long data is kept, and what you tell customers.

SEO and URL continuity

Inventory product, category, content and campaign URLs. Keep useful URLs stable where practical and map changed URLs to relevant successors. Carry across the content as it renders, the titles, the canonicals, the internal links, the status codes and the structured data. Check the sitemaps and analytics still work, watch Search Console afterwards, and keep the conditions that let you roll back. Rankings, traffic and recovery timing are not guaranteed. We work through the same ground in will migrating hurt my SEO, and the measurement side is covered in Core Web Vitals explained.

How to migrate a live store

The old store can usually remain available during build and test, but no provider should promise universal zero interruption. Agree in advance how long you can stop writing to the store, what checkout does during that window, and who signs the cutover off. Seven steps, and the reconciliation either side of the switch is what proves nothing was lost.

• ✓
  Record a baseline and freeze target schema and feature scope.
• ✓
  Run an initial export and test migration on an isolated environment.
• ✓
  Reconcile counts, money totals, samples and exceptions.
• ✓
  Test storefront, account, transaction, refund and operational journeys.
• ✓
  Plan the final data delta, content freeze and customer communication.
• ✓
  Cut over with monitoring, rollback triggers and named decision-makers.
• ✓
  Reconcile post-cutover orders, inventory, payments and analytics.

The old store can usually remain available during build and test, but no provider should promise universal zero interruption. Agree in advance how long you can stop writing to the store, what checkout does during that window, and who signs the cutover window off in the accepted plan.

Ownership and accounts

Client content and business data remain client property. Custom deliverables transfer after full payment under the signed agreement. PandaCodeGen retains reusable internal tools, templates and pre-existing code. Third-party components retain their licenses. Domain, hosting, repository and business accounts can remain under client control when agreed. The general version of this question is covered in do you own your website.

Is the migration worth it?

Possibly not, and it is worth saying that plainly before quoting anyone. If your only real problem is that the store is slow, and the catalog is small, better hosting and a serious look at what your plugins are doing can buy back most of the speed for a fraction of a rebuild. If that is genuinely the whole issue, do that instead and keep the money.

Where a rebuild starts to make sense is when speed is only the symptom you noticed first. The pattern worth watching for is a store carrying a long list of extensions, each with its own renewal, each one a candidate to break at the next update, with caching layers papering over the weight underneath. At that point you are not paying for a slow site, you are paying a maintenance tax and carrying the risk that a routine update takes checkout down. That is a different problem from speed and hosting does not fix it.

Compare WooCommerce repair, optimization, headless WooCommerce and full replacement across the same capabilities. Count everything: building it, moving the data, what your providers charge, fees on every payment, maintenance, security, support, your own team's hours, and what it costs to leave later. Only claim a business benefit if your own data shows it. Nothing here automatically produces a ranking, a conversion lift or a payback date. If speed is the trigger, start with diagnosing a slow WooCommerce store before assuming a rebuild. If the question is architectural, compare the two operating models in WooCommerce versus a custom website. Work that goes beyond a storefront belongs under custom engineering.

What a fair quote contains, and what to question

A quote you can act on describes the whole job, including the parts nobody enjoys scoping. Read it as a list of deliverables rather than a total.

• ✓
  Design and build scope stated template by template, not as a theme reskin.
• ✓
  Catalog, content and media migration with a documented URL disposition and redirect map.
• ✓
  Metadata, canonicals, structured data and URL structure listed as things you are owed, with evidence you can check them against.
• ✓
  Test coverage across devices, browsers, checkout and every named integration.
• ✓
  Launch support, a monitoring window and a written rollback plan with named owners.
• ✓
  A performance target that names pages, profiles, method, exclusions and remedy.

Question a quote where any of the following appear.

• ✓
  Redirects, analytics handover or Search Console access listed as optional extras.
• ✓
  An hourly estimate with no ceiling, no point where you can stop, and no agreed way to handle changes.
• ✓
  A quote that is really just someone running an import plugin. It copies your records and leaves your URLs, templates, payments and sign-off untouched.
• ✓
  An ongoing retainer required before any build work can begin.
• ✓
  A ranking, traffic or revenue promise, or a performance claim with no named pages, method or exclusions.
• ✓
  Nothing in writing about who holds the domain, the code, the hosting and the provider accounts once it is live.

Payment, refund, support and performance

A common payment option is 30 percent at onboarding and 70 percent at the delivery milestone, and another written schedule may be agreed. Refund is tied to failure to deliver the signed scope, not a preference change after starting. Starter includes 15 business days of launch defect support; Growth and Scale include 30. A 90-plus Lighthouse target applies only when the contract names representative pages, profiles, environment, three passing runs per page and profile, exclusions and remedy. For the inputs behind a build or transition figure, see what a website costs and what drives migration cost.

Frequently asked questions

Primary sources

• WooCommerce product CSV
• WooCommerce product migration
• WooCommerce order and customer export
• WooCommerce REST API
• WooCommerce webhooks
• WooCommerce HPOS