Deciding to merge multiple WooCommerce stores into one is a financial decision wearing a technical disguise. Unlike merging blog content, where the worst outcome is a lost page, getting store data wrong means real customers losing access to something they paid for, a license that stops validating, or a subscription that bills twice. None of that shows up in a staging environment. It shows up in your inbox, from people who trusted you with their money.
Why Store-Data Merges Carry Real Financial and Legal Weight
A content migration that goes slightly wrong costs you some search traffic while you fix it. A store-data migration that goes slightly wrong costs a customer their purchase history, their active license, or their billing continuity – and they have every right to be upset about it, because they paid real money based on a promise your systems are now failing to keep.
That difference in stakes is why store data deserves its own planning pass, separate from the general content and redirect work, with its own explicit decisions written down before any migration script exists.
Inventory Customers, Orders, Licenses, and Subscriptions First
Before deciding how anything migrates, know exactly what exists on each store. Pull a full export of:
- Customers, with their email addresses as the primary identifier
- Orders, including refunds and partial refunds, not just completed sales
- License keys and their current activation status, if you sell software
- Active and cancelled subscriptions, and which payment gateway each one bills through
If you’re working with Easy Digital Downloads, its own documentation is worth reviewing store by store, because customer, order, and license data can be structured slightly differently depending on which extensions and version each store is running. Don’t assume two stores built on the same platform store this data identically – confirm it for each one.
While building this inventory, flag any customer who appears to have separate accounts on more than one of the stores being merged, matched by email address. Deciding whether those should be linked into one customer record on the new site, or kept as genuinely separate purchase histories, is a judgment call worth making now, with real data in front of you, rather than discovering the overlap mid-migration.
Decide Your Exclusion Criteria Up Front
Not everything in a store’s database deserves to migrate. Before you touch a single record, decide – in writing, for every store – how you’ll handle:
- Obvious test accounts and test orders left over from development or QA
- Abandoned checkouts that never completed as a real sale
- Discount codes and coupons that are expired, unused, or specific to a promotion that’s long over
Deciding this by instinct, one record at a time, during the migration itself is how test data ends up mixed in with real customer records on the new site. Write the exclusion rules down before you start, and apply them consistently.
Look for concrete, checkable patterns rather than relying on memory of which orders were tests. Internal team email addresses, orders with a zero or near-zero total, and orders with no matching transaction ID from the payment gateway are all reliable signals worth filtering on systematically, across every store, instead of eyeballing a list and hoping nothing slips through.
Plan Your Product and Price Mapping Strategy
Every product being migrated needs a confirmed mapping to its equivalent on the new store, decided before any migration script touches order data. This includes variable pricing tiers – a “Pro License” tier on one store and a “Professional” tier on another might be the same product under different naming, or they might genuinely be different offers. Verify each mapping by name and price, not by assuming the tiers line up in the same order across stores.
This mapping becomes the foundation every order, license, and subscription migration script depends on. Get it wrong here and the error repeats across every record that references it.
Document the mapping as a reviewable spreadsheet, the same way you documented the redirect map: old product name, old store, new product name, new price ID, and a column confirming someone actually verified the match by hand rather than assumed it. Before trusting the mapping for a full migration, run it against a small, real sample of orders and manually check that every resulting product and price is correct.
A minimal version of that mapping looks something like this:
| Old Store | Old Product / Tier | New Product | New Price ID | Verified? |
|---|---|---|---|---|
| Store A | “Pro License” – $49/yr | Product X – Pro | price_pro_annual | Yes |
| Store B | “Professional” – $59/yr | Product X – Pro | price_pro_annual | Yes |
| Store C | “Starter Bundle” – $19/yr | Discontinued – excluded | – | Yes |
Notice that two visually different tier names from two different stores map to the exact same new product and price – that’s the kind of match a numeric ID would never have caught, and exactly why the “Verified?” column exists.
Decide What “Reference-Only” Means for Old Subscriptions
Some subscriptions can migrate cleanly to actively bill on the new store’s infrastructure. Others – especially ones tied to a payment gateway configuration that isn’t moving – need to stay on the old system for billing while their record is copied to the new site for reference and support purposes only.
Decide which category applies to each subscription setup before migration, and make sure your support team knows the difference. A customer support agent who doesn’t know a subscription is reference-only might tell a customer something about their billing that simply isn’t true anymore.
The same logic applies to license keys tied to those subscriptions. If you’ve built a license key system for your own products, preserve the existing keys exactly as issued during the merge. Regenerating a key breaks every installation already activated with the original, turning a data migration into a support incident for every affected customer.
Get Explicit Sign-Off Before Any Script Touches Real Data
Because this data carries real financial weight, treat the inventory, exclusion criteria, product mapping, and subscription rules as a document that needs sign-off, not just a document that exists. Whoever is accountable for the business relationship with these customers should read and approve the plan before a migration script runs against live orders, licenses, or subscriptions.
This isn’t bureaucracy for its own sake. It’s the difference between a documented decision everyone agreed to and a technical choice one person made alone, that the rest of the business only learns about after a customer complains.
One Product ID, Four Different Products
For example, imagine four separate stores, each built independently over several years. Product ID 42 on one store is a WordPress plugin. On another, it’s a completely unrelated WordPress theme. On a third, it doesn’t exist at all. Migrating order data by matching on that numeric ID alone would silently attach the wrong product to a real customer’s order on at least three of those four stores. Matching by product name or a stable slug, and verifying the match by hand before trusting it, is the only way to catch this before it reaches a live customer record.
The Pitfall: Starting the Technical Migration Before These Decisions Are Written Down
The most expensive mistake in a store-data merge is writing the migration script before the product mapping, exclusion criteria, and reference-only rules exist anywhere except in someone’s head. Scripts written against undecided rules end up encoding whatever assumption happened to be convenient that day. Those assumptions are difficult to spot in a code review and expensive to unwind once real customer data has already moved.
Unwinding a bad content redirect means editing a config file and waiting for a recrawl. Unwinding a bad store-data migration can mean refunding customers, reissuing license keys, and explaining to someone why their subscription billed incorrectly – all after the fact, on top of the original migration work. The planning pass this post describes is small compared to that cleanup.
Your Checklist for Merging Multiple WooCommerce Stores
Before any migration script runs against real data, confirm you have:
- A full inventory of customers, orders, licenses, and subscriptions per store
- Written exclusion criteria for test accounts, abandoned checkouts, and expired discounts
- A verified product and price mapping, checked by name, not by numeric ID
- A clear, documented definition of “reference-only” for subscriptions that aren’t moving to new billing
- A plan to preserve existing license keys exactly as issued
With store data decisions locked in, the next step moves into technical execution: building and testing the server-side redirects that will actually carry traffic – and checkout links – from the old domains to the new one.