Blog · Marketplace · 16-min read
WordPress/WooCommerce to Marketplace Migration Checklist
Skip to content
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.
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.
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.
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.
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.1
| 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.
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.
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.
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.
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.2
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.
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.
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.5
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.
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.6 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.
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.
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.7
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.
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.8 That is why the plan should use observed indexing and crawl evidence rather than promise a recovery date.
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.9
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.
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.
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.
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.
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.
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.
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.
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.
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.
Test rollback during the rehearsal. If it cannot be demonstrated without improvisation, it is not a rollback plan.
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.
| 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Discover what Clutch.co is, how its verified B2B reviews and agency rankings work, and how startups can use it to find reliable software development partners.
Design a dispute-resolution control plane with case states, evidence, roles, financial actions, reconciliation, appeals, and operator-ready metrics.
Discover if Sharetribe is the best fit for your marketplace. Compare ST vs Cocorico, explore alternatives, and answer 10 crucial questions before you decide.
Tell us what you're building. After an intro call with our founders, you'll hear back within 72 business hours: a written scope with an hour range and a hard ceiling, or the questions we need answered first.