Scope decides the timeline, not the catalog size. A small store (under 500 products, no subscriptions, no custom logic) lands in 2 to 3 weeks. A mid-sized store with custom fields, complex variants, and third-party connections runs 4 to 8 weeks. Large catalogs with subscription histories, ERP connections, or multi-currency setups take 8 to 16 weeks. The audit in week one tells us which bucket you're in. Anyone quoting a migration timeline before auditing your current store is guessing at your expense.

Yes, with caveats worth knowing before you sign anything. Active subscription states, renewal dates, customer payment tokens, and billing cycles can be migrated when the source platform exposes them and the payment gateway supports token transfer. Stripe and PayPal both support this on the WooCommerce side. Some platforms make token export difficult or impossible, in which case existing subscribers need to re-authorize payment after migration. We surface this in the audit before the project starts, not after. Memberships, recurring orders, and access permissions all carry over to WooCommerce equivalents like WooCommerce Subscriptions or Paid Memberships Pro.

SEO survival is the part most migrations get wrong. We extract every indexed URL from your current site (products, categories, blog posts, content pages), map old paths to new WooCommerce equivalents, and generate 301 redirects for every one. Structured data is preserved on product pages. Meta titles, descriptions, and canonicals are migrated. The new sitemap is submitted to Google Search Console at cutover. Done this way, you see a brief crawl-rediscovery dip in week one and recovery to baseline within 2 to 4 weeks. Skipping the redirect map is what causes the horror-story traffic crashes.

Yes. Blog posts, content pages, author profiles, categories, tags, featured images, and internal links all transfer. Comments migrate where the source platform stores them in a usable format. Custom fields and metadata are mapped to WordPress custom fields or equivalent structures. Content stays content. URLs get redirected per the SEO plan, so external backlinks to your old blog posts still resolve.

No. The new WooCommerce store gets built and tested on a staging environment while your current store keeps taking orders. Cutover is a DNS change scheduled during your lowest-traffic window. Final data sync (orders placed during the build window) happens just before the switch. Customers see one storefront before the change and the new one after, with no maintenance page and no order gap. The only outage risk is misconfigured DNS, which is why we monitor for the first few hours after the switch.

Payment gateways: Stripe, PayPal, Authorize.net, Square, and most regional processors all have WooCommerce equivalents that connect to the same merchant accounts. Shipping: live-rate carriers (FedEx, UPS, USPS, DHL) and platforms like ShipStation and EasyPost connect through WooCommerce extensions. CRMs and marketing tools (HubSpot, Klaviyo, Mailchimp, ActiveCampaign, Salesforce) connect via official plugins or API work. ERPs and fulfillment systems are handled on a case-by-case basis, depending on whether they expose an API. The audit phase identifies every outside system your current store talks to and confirms which path each one takes.

QA happens before cutover, not after. We place test orders end-to-end, run refunds, validate subscription renewals where applicable, test every redirect from a sampled URL list, confirm customer logins work against migrated accounts, and verify checkout across devices and payment methods. You sign off on a QA report before DNS flips. Post-launch, 30 days of support cover any production issue, transaction error, or edge case that didn't surface in staging. That window typically catches everything that's going to surface. Anything past 30 days is handled on a retainer if you want ongoing coverage.

Yes. That's the Migration + Storefront Rebuild scope. Migrating data and rebuilding the storefront in one engagement is often more practical than doing them separately, because you only test and cut over once. A redesign during migration covers the theme, the homepage layout, the product page template, the checkout flow, mobile responsiveness, and performance tuning. The tradeoff is timeline. Adding a redesign extends the project by 3 to 6 weeks depending on scope and stakeholder count.

Five things. First, admin access to your current store and hosting. Second, an export of your product catalog or database access. Third, a list of third-party systems currently connected (payment gateway, shipping, CRM, email, ERP, anything else that touches the store). Fourth, your design assets (logo, brand colors, fonts, current theme files if available) and any redesign direction if you're going that route. Fifth, a hard deadline if one exists (contract expiration on your current platform, a planned campaign, a fiscal year cutover). The build moves faster when the constraints are on the table from day one.