WordPress/WooCommerce to Marketplace Migration Checklist

Last substantive review: August 2026.

A WordPress or WooCommerce migration becomes materially harder when the destination is a marketplace. You are not only moving pages, products, customers, and orders. You are introducing seller identities, listing ownership, commissions, payout controls, disputes, moderation, and transaction states that may not exist in the current store.

This checklist is for an established company that needs to preserve a working business while adding marketplace operations. It is written for the person accountable for launch risk: a product leader, engineering leader, operator, or founder. Use it to expose decisions before implementation, define evidence for each launch gate, and give the cutover team an executable runbook.

The central rule is simple: do not select dates, tools, or migration scripts until you know which business records must survive, how money will move, and what would make you stop the launch.

1. Confirm marketplace readiness before choosing a platform

A WooCommerce store usually has one merchant of record, one catalog owner, and a relatively direct order lifecycle. A marketplace may have many sellers, multiple fulfillment responsibilities, a platform fee, seller payouts, seller-specific refunds, and moderation. Write the future operating model before comparing platforms.

Define the operating model

• Who may sell, and who approves a seller?
• Who owns each listing, price, inventory record, and customer relationship?
• Who is responsible for tax, refunds, disputes, cancellations, support, and prohibited goods?
• Does one checkout ever contain items from multiple sellers?
• When does a seller become eligible for payout?
• Which actions must staff be able to override, and which overrides require an audit trail?
• Which countries, currencies, languages, and legal entities are in scope at launch?

Write non-negotiable launch constraints

Record the maximum acceptable checkout interruption, the recovery point for orders and money records, the staff available during cutover, contractual launch commitments, and any seasonal blackout periods. These are business constraints, not engineering preferences.

Choose the destination against requirements

Compare three realistic paths: extending WordPress and WooCommerce, adopting a dedicated marketplace platform, or building a headless or custom marketplace. Score each path against the same requirements: seller model, transaction flexibility, payments, search, content control, integrations, observability, data portability, operational burden, and total cost of ownership.

Keeping WooCommerce may be sensible when the current order model remains dominant and marketplace behavior is narrow. A dedicated marketplace platform may be sensible when its transaction and seller primitives closely match the operating model. A custom or headless build may be justified when differentiation depends on workflows the packaged options cannot represent safely. No category is automatically the mature choice; the fit depends on the operating model and the team that will own it.

Gate: Do not begin field mapping until the operating model, platform decision, scope exclusions, and launch constraints have named approvers.

2. Build a source data inventory

Start with evidence from production, not a generic migration template. Inventory WordPress core tables, WooCommerce records, custom post types, custom fields, plugin tables, media storage, external systems, analytics identifiers, and manually maintained spreadsheets. The WooCommerce product CSV can help with catalog extraction and field mapping, including custom metadata, but it is not a complete marketplace backup.¹

Domain	Inspect	Decide
Content	Pages, posts, authors, categories, tags, redirects, SEO fields	Move, rewrite, merge, archive, or intentionally omit
Catalog	Products, variants, attributes, inventory, price history, media	How each record becomes a listing and who owns it
People	Customers, admins, vendors, roles, consent, addresses	New role, authentication path, and privacy basis
Commerce	Orders, line items, coupons, tax, refunds, disputes, notes	Operational record, read-only history, or transformed transaction
Money	Charges, fees, transfers, payouts, balances, external IDs	Authoritative system and reconciliation method
Integrations	ERP, CRM, support, fulfillment, tax, email, analytics	Replace, reconnect, or retire

For every source, record its owner, export method, timestamp semantics, record volume, retention rule, personally identifiable information, and known quality problems. Save a checksum or immutable export reference for each migration rehearsal so later differences can be explained.

3. Create the field map and identity crosswalk

Build a field-level map before writing an importer. Each row should identify the source field, destination field, transformation, default, validation rule, collision rule, privacy classification, and disposition when the source is invalid. Include hidden plugin metadata; operationally important facts often live outside standard WooCommerce fields.

Create an immutable crosswalk for source and destination IDs. At minimum, cover users, sellers, products, variants, orders, refunds, media, coupons, and payment-provider objects. Never rely on a title, email address, or slug as the only join key. Keep the source ID on the destination record where the platform permits it, and store the complete crosswalk outside the application as a controlled migration artifact.

Reconcile meaning, not only counts

A matching row count can hide bad ownership, truncated descriptions, shifted timestamps, wrong currency units, and lost relationships. Test representative records and edge cases. Reconcile totals by currency and status, verify seller-to-listing ownership, compare orders with line items and refunds, inspect transformed rich text, and sample media at its final public URL.

Gate: Every in-scope field has a documented destination or an approved reason for exclusion. Critical financial and ownership records reconcile by relationship and amount.

4. Plan identity, authentication, consent, and privacy

Treat a user migration as a security and customer-communication project. WordPress password hashes may not be usable by the destination authentication system. If the new system cannot verify the old hashes securely, plan a password reset or magic-link activation instead of exporting passwords into an improvised compatibility layer.

Decide whether a buyer and seller can share one account, how duplicate emails are resolved, how administrators receive elevated roles, and whether social-login identities can be preserved. Test inactive, suspended, deleted, guest, and duplicate users. Define what happens to historical orders when a user is not migrated.

Map consent and privacy data separately from profile data. Preserve the evidence needed for marketing consent, suppression, deletion requests, retention holds, and regional privacy obligations. Minimize what is copied into development and rehearsal environments. Use redacted or synthetic data when production personal data is not required.

Prepare customer communications for activation, password reset, profile changes, and support escalation. A technically correct import still fails operationally if legitimate users cannot understand how to regain access.

5. Design Stripe Connect and seller payouts before onboarding

Stripe Connect is not a single payment setting. The account type, charge type, responsibility model, and funds flow determine where balances sit, how fees are collected, who manages refunds and disputes, what appears on statements, and which webhook events the platform must process. Stripe documents direct charges, destination charges, and separate charges and transfers as distinct models.²

Make the commercial decisions explicit

• Which legal entity operates the platform, and which party is merchant of record?
• Will a charge belong to the platform or a connected account?
• Can one payment fund more than one seller?
• When is the platform fee earned?
• Who absorbs refunds, disputes, negative balances, and payment-processing fees?
• What event makes funds available for payout?
• Which countries and capabilities must seller accounts support?

Do not assume every seller must create a new account. Account reuse and migration depend on the current Connect configuration, the destination platform configuration, countries, capabilities, and Stripe eligibility. Stripe supports reuse of verified information in eligible networked onboarding flows, while some configuration changes can require new accounts or renewed onboarding.^{3 4} Confirm the exact path with Stripe and the destination platform before contacting sellers.

Inventory seller payment readiness

For every seller, capture the platform user ID, Stripe account ID, country, requested capabilities, onboarding status, requirements currently due, payout eligibility, external-account status, and any restrictions. Decide how incomplete sellers appear in the marketplace and whether their listings can be visible or purchasable.

Test the full money lifecycle

Cover successful and failed onboarding, authentication requirements, payment failure, delayed payment, partial and full refund, cancellation before capture, dispute, transfer failure, payout failure, negative balance, and webhook retries. Stripe distinguishes events on the platform account from events on connected accounts; configure and test the relevant Connect webhook endpoint instead of assuming the platform endpoint sees every event.⁵

Reconcile the application ledger to Stripe charges, refunds, fees, transfers, and payouts. The record that drives customer-facing status must be traceable to the provider objects that moved money.

Gate: Finance, operations, product, and engineering have approved the funds-flow diagram. Test transactions reconcile through payout or reversal, and seller onboarding exceptions have an owner.

6. Map WooCommerce orders to marketplace transaction states

Do not translate status labels one for one. WooCommerce order status, payment state, fulfillment state, seller acceptance, and payout eligibility may be collapsed into one field today but separated in the destination.

Business event	Questions to resolve	Evidence to preserve
Buyer commits	Is inventory reserved? Is payment authorized or captured?	Timestamp, actor, cart, price, policy version
Seller accepts	Is acceptance required? What is the timeout behavior?	Seller decision and reason
Payment succeeds	Which provider object is authoritative?	Charge, intent, transfer, currency, amount
Fulfillment completes	Who confirms completion and can it be disputed?	Shipment, booking, delivery, or completion proof
Refund or dispute	Which state can be reversed and who carries the balance?	Reason, amount, provider IDs, staff action
Payout becomes eligible	Which event and delay release funds?	Eligibility rule, transfer, payout, balance transaction

If the destination uses a marketplace transaction engine, document its process name, version, states, transitions, and actor permissions. Sharetribe, for example, exposes transaction process, state, transition, pay-in, and payout information in its Marketplace API.⁶ Other platforms will represent the same business facts differently.

Historical orders often should remain read-only records rather than replayed live transactions. Replaying transitions can trigger emails, webhooks, inventory changes, refunds, or payouts. If the business needs interactive history in the new system, create an import path that suppresses side effects and prove that behavior in a rehearsal.

7. Protect search visibility with a complete URL plan

Make a URL inventory from the XML sitemap, analytics and search-console landing pages, internal crawl, backlink data, and CMS export. Include pages, posts, categories, tags, products, variants when indexable, author archives, media attachment pages, pagination, and valuable filtered pages. Server logs can reveal crawled URLs that other sources miss.

Map each old URL to a deliberate destination

Use a permanent server-side redirect for a permanently moved page, normally a 301 or 308. Map each valuable old URL to the closest relevant new URL. Avoid routing unrelated pages to the home page and avoid redirect chains. Google treats permanent redirects as a strong canonical signal, but redirects are only one part of the migration.⁷

For content with no equivalent, choose intentionally among keeping it, consolidating it into a useful page, or returning an appropriate not-found or gone response. Keep a written reason for high-value exclusions.

Align every canonical signal

• Use self-referencing canonicals on the new canonical URLs.
• Update internal links so they point directly to the destination rather than through redirects.
• Regenerate XML sitemaps with final canonical URLs and accurate modification dates.
• Update hreflang, pagination, navigation, feeds, and structured-data URLs where applicable.
• Keep staging blocked from indexing, then confirm the production site is crawlable at launch.
• Preserve useful titles, headings, body content, and metadata unless a planned rewrite has been reviewed.

Google recommends preparing a URL map, testing redirects, updating canonical and internal signals, submitting new sitemaps, and monitoring both old and new sites. It also notes that site-move processing has no fixed crawl schedule.⁸ That is why the plan should use observed indexing and crawl evidence rather than promise a recovery date.

Validate structured data and images

Only publish structured data that matches visible, accurate page content. Check that image URLs are public, stable, indexable, correctly sized, and referenced in the final markup. Validate representative templates, but also crawl the rendered production output because a passing sample does not prove every record is correct. Google requires structured data to describe the page it appears on and requires referenced images to be crawlable and indexable.⁹

Gate: Every important source URL has a tested outcome, canonical signals agree, production crawl controls are correct, and the team has a saved pre-launch benchmark for later comparison.

8. Run a full migration rehearsal

Use a production-shaped environment and a dated copy of source data. Run the same extraction, transformation, import, indexing, integration, and reconciliation steps planned for launch. Measure each step, record manual interventions, and preserve the logs.

Rehearsal acceptance checks

• Record counts and financial totals reconcile within documented rules.
• Users can activate accounts and receive the correct role.
• Sellers can complete or resume onboarding.
• Listings preserve ownership, variants, media, price, inventory, and moderation state.
• Representative transactions complete through refund and payout scenarios.
• Emails, webhooks, support tools, analytics, tax, and fulfillment integrations behave as intended.
• The redirect matrix passes automatically and no redirect loops or chains appear.
• Canonical tags, robots directives, sitemap URLs, structured data, and image responses are correct.
• Operations can find a buyer, seller, listing, order, refund, transfer, and payout from either system.

Turn every failure into one of four things: a code fix, a data rule, a runbook step, or an explicit scope decision. Repeat the rehearsal after material changes. A rehearsal is complete only when its evidence can be reviewed by someone who did not run it.

9. Conduct a timed cutover dry run

A cutover dry run starts at the freeze decision and ends after monitoring, not when the import command finishes. Use the actual runbook, named people, credentials, dashboards, bridge channel, and decision gates.

• Measure export lag and define how changes made after the snapshot are captured.
• Prove maintenance, read-only, or write-routing behavior.
• Time data validation, DNS or routing changes, cache purge, smoke tests, and business approval.
• Practice the abort decision before the irreversible step.
• Confirm every operator can access the systems they own without sharing credentials.
• Record the final go or no-go evidence in one location.

If the measured sequence does not fit the approved business constraints, reduce scope, improve automation, or change the cutover method. Do not solve a rehearsal overrun by assuming production will be faster.

10. Execute production cutover with one authoritative system

At every moment, the runbook must say which system accepts each kind of write. Allowing both systems to accept orders, inventory changes, profile edits, or refunds without a proven synchronization model creates ambiguous records and financial risk.

1. Open the incident bridge, confirm attendance, and record the source snapshot time.
2. Apply the approved write freeze or routing rule.
3. Export source data and capture immutable artifact references.
4. Run transformations and imports with idempotency controls.
5. Reconcile critical records before opening buyer or seller traffic.
6. Enable integrations and webhook destinations in the documented order.
7. Apply routing, redirects, cache, sitemap, canonical, and crawl-control changes.
8. Run buyer, seller, staff, payment, refund, and search smoke tests.
9. Obtain business, finance, support, and engineering approval.
10. Announce launch status and begin enhanced monitoring.

Keep an exception log with the source record, symptom, business impact, owner, disposition, and evidence. Never repair financial records directly in the database without an approved procedure and audit trail.

11. Make rollback executable

A rollback is a tested operating state, not a sentence in the project plan. Reverting DNS alone does not undo users, orders, emails, Stripe objects, transfers, or writes accepted by the new system.

Define triggers before launch

Use observable triggers tied to business harm: checkout cannot complete, order creation and payment diverge, sellers cannot fulfill, financial reconciliation fails, privileged access is wrong, data corruption is detected, or critical crawl controls are incorrect. Name the person authorized to call rollback and the last point at which rollback is safer than forward repair.

Define the restoration sequence

• Stop new writes or route them to the designated system.
• Preserve logs, exports, provider IDs, and the exact failure time.
• Restore application routing and verified configuration.
• Reconcile writes created after the source snapshot.
• Prevent duplicate emails, charges, transfers, refunds, and fulfillment.
• Communicate status to staff, sellers, customers, and partners as applicable.
• Run rollback smoke tests and obtain the same business approvals required for launch.

Test rollback during the rehearsal. If it cannot be demonstrated without improvisation, it is not a rollback plan.

12. Monitor the business after launch

Use a live command center with technical, financial, search, and support views. Compare results with the pre-launch benchmark and segment by device, country, seller, payment method, and acquisition channel when useful.

Area	Watch	Act on
Application	Error rate, latency, job queues, login and checkout completion	New failures, degraded paths, stuck background work
Marketplace	Seller onboarding, listing creation, acceptance, fulfillment	Blocked sellers, incorrect ownership, state-machine dead ends
Money	Charges, refunds, fees, transfers, payouts, disputes	Ledger mismatch, failed payout, duplicate or missing provider object
Search	Crawl errors, indexed pages, submitted URLs, redirect hits, canonical selection	Important not-found URLs, blocked resources, conflicting canonicals, deindexing
Support	Contact reasons and affected cohorts	Repeated activation, order-history, seller, or payment problems

Keep the legacy system and migration artifacts available under the approved retention and security plan. Close the migration only after exceptions are resolved or accepted, financial records reconcile, search issues have owners, and operating teams can support the new workflows without the launch crew.

13. Use this migration runbook

Gate	Action and evidence	Owner	Stop condition
Scope approved	Signed operating model, source inventory, exclusions, platform decision	Executive sponsor and product	Unresolved merchant, seller, refund, tax, or support ownership
Mapping approved	Field map, ID crosswalk, transformation tests, privacy review	Data and engineering	Critical field has no disposition or financial relationship fails reconciliation
Identity ready	Activation test, role matrix, consent migration, support scripts	Security, product, support	Unauthorized role, inaccessible cohort, or unsafe password handling
Payments ready	Funds-flow diagram, Stripe configuration, seller status inventory, ledger tests	Finance and payments engineering	Charge, refund, transfer, payout, or dispute cannot be traced
SEO ready	URL map, redirect tests, crawl, canonical and sitemap validation	SEO and engineering	Critical URLs lack an outcome or production crawl controls are wrong
Rehearsal accepted	Dated artifacts, duration, reconciliation report, defect disposition	Program lead	Unowned critical defect or sequence exceeds launch constraints
Go or no-go	Fresh backup, staffed bridge, access check, rollback checkpoint	Incident commander	Missing approver, stale artifact, failed dependency, or trigger already breached
Launch verified	Smoke tests, business approval, dashboards, exception log	Functional owners	Any pre-agreed rollback trigger
Migration closed	Financial reconciliation, SEO review, support handoff, artifact retention	Executive sponsor	Material exception lacks owner and disposition

For each row, add the responsible person's name, exact evidence link, command or dashboard, expected result, timestamp, and escalation contact. Keep commands copyable and ordered. Mark steps that are safe to retry and document idempotency keys or deduplication rules where money or notifications are involved.

Relevant marketplace operating experience

Horizon Labs worked with Rarewaters, a Sharetribe marketplace, from day one of marketplace operations through acquisition. That experience informs our attention to seller workflows, marketplace transactions, and operating continuity. It is not presented as a WordPress migration case study or as proof of a specific migration result.

Request a migration risk review

If your company has a live WooCommerce business and a marketplace roadmap, Horizon Labs can review the operating model, data map, Stripe Connect design, SEO plan, cutover sequence, and rollback gates before implementation. Request a marketplace migration risk review and bring your current architecture, known constraints, and proposed destination.

Frequently asked questions

How do I know whether to keep WooCommerce or move to a marketplace platform?

Model the required seller, transaction, payment, moderation, and operations workflows first, then score each option against them. Keep WooCommerce when extensions can support the model without creating unacceptable operating risk. Move when a destination represents the required workflows more directly and your team can own its constraints.

Can existing WordPress passwords be migrated?

Only if the destination can securely verify the existing password hashes and the implementation has been reviewed. Otherwise, migrate the account identity and use a controlled password-reset or activation flow. Do not export plaintext passwords or build an unreviewed compatibility layer.

Do sellers need new Stripe Connect accounts?

Not always. The answer depends on the current and destination Connect configurations, account countries, capabilities, platform responsibilities, and Stripe eligibility. Inventory every account and confirm the supported path with Stripe and the destination platform before asking sellers to onboard again.

How should WooCommerce orders map to marketplace transactions?

Map business events and financial evidence, not status names alone. Separate payment, fulfillment, seller acceptance, refund, dispute, and payout eligibility, then decide whether historical orders should be read-only records or side-effect-free imported transactions.

How do I protect SEO during a WordPress marketplace migration?

Inventory valuable URLs, map each one to a relevant destination, test permanent redirects, align canonicals and internal links, regenerate sitemaps, validate structured data and images, and monitor crawl and indexing signals after launch. Do not promise a fixed recovery date.

What should trigger a rollback?

Use agreed, observable conditions such as broken checkout, payment and order divergence, financial reconciliation failure, data corruption, incorrect privileged access, or critical crawl-control errors. Name the decision owner and the last safe rollback point before launch.

Can the old and new platforms run at the same time?

They can serve different purposes, but each type of write needs one authoritative system unless bidirectional synchronization has been proven. Running both systems without clear ownership of orders, inventory, profiles, refunds, and payouts creates conflicts that a DNS change cannot repair.