Moving from Square Online to WooCommerce is a sequenced cutover, not a plugin install. Merchants who make the switch are rarely worried about setup mechanics; what keeps them up at night is the fear of losing order history and customer records in the process. That fear is valid if the migration is approached without a plan. The operations that protect your data follow a fixed order: freeze the store before you export, map payments carefully, reconcile stock before opening the doors, and run both stores in parallel for a short window to prevent overselling. Just as important is naming the items that genuinely cannot be migrated, such as stored card credentials, rather than discovering those gaps mid-migration. This guide walks through the full cutover sequence. You will learn the prerequisites and a realistic timeline, what cannot be moved from Square Online, how to execute each of the six migration phases, Australian considerations for GST and payouts, and the post-cutover checks to run at the 48-hour, week-one and month-one marks.

Before You Start: Prerequisites and a Realistic Cutover Timeline

Set the clock before you set the date. Plan on two to four weeks of preparation, with a checkout freeze of 24 to 72 hours depending on order volume. Treat both as working estimates rather than guarantees: confirm Square Online's current export scope and store-closure options inside your own Square account instead of trusting a guide written for a different plan tier, then write the freeze date into the plan.

Work through four preparations before anything moves.

1. Build an access checklist. You need owner-level admin on Square, WordPress admin on the Woo store, host panel access for DNS, and staging capacity to run a full test import. If that import times out on your host's PHP limits, you want to know now, not on launch night.
2. Count your records before touching anything. Record total orders, customers, products and variations, then list which attachments matter: receipts, order notes, dispute evidence and GST records. The ATO's record-keeping rules for business set out what you must retain, so settle retention before you archive anything. Those counts become your verification targets after each import.
3. Assign three roles in writing. Name who pauses checkout, who answers customer email during the freeze, and who has authority to abort and roll back. A migration with no rollback owner tends to get finished in a hurry.
4. Create a rollback point. Take a full database and files backup of the Woo store, plus a dated Square export downloaded and stored off-platform. The first import is a rehearsal, not the live one. For the duplicate-order risk when an older connector is still running, cutover without duplicate orders is optional background reading.

With scope, access, counts and a rollback point confirmed, you can name what will not travel before you schedule the freeze.

What Cannot Be Migrated From Square Online

With the rollback point stored off-platform, list what will not be in it. That list belongs in the plan before launch, not in a support inbox afterwards.

• Stored card credentials do not move. Tokenised card details sit with your payment processor, not in your Square export. Customers re-enter a card at their first WooCommerce checkout, and no plugin changes that. Confirm your processor's documented behaviour before you promise anyone a smooth switch.
• Subscriptions are the hard case. Ask in writing whether your processor supports account-to-account token migration. Treat the answer as no until a written yes arrives. If there is no migration path, subscribers need a reauthorisation email and a short grace period before recurring billing resumes.
• Square-only records stay behind. Square Invoices history, Square Loyalty balances and reward history, Square Marketing lists and segments, and physical POS transactions may not appear in your online order export. Check each one's export availability in your dashboard before telling customers their history is safe. If Square Loyalty remains part of your setup, review loyalty rewards sync across systems before promising balances will carry over.
• Some data has no direct mapping. Reviews, wishlists, custom checkout fields and account-level notes may need archiving or a manual re-entry list. Accept that some records remain retrievable by you but invisible to customers.

Say it early. One pre-launch email explaining that saved cards must be re-entered and that loyalty points have a defined end date prevents the support spike that can overshadow an otherwise clean cutover. With that list agreed, you can set the freeze date and take a clean export.

Phase 1: Freeze the Store Before You Export

Knowing what will not move, you can now write the first date on the calendar: the freeze.

1. Set the freeze window. Freeze means no new orders on Square Online for the export window, so the file you take is the file you import. Choose your quietest 24 to 72 hours and avoid sale events, end-of-financial-year promotions, Black Friday and Cyber Monday, and any local campaign that would send a traffic spike at a paused checkout. Confirm in your Square account how checkout pausing behaves before you rely on it.
2. Do a pre-freeze sweep. Fulfil and mark as shipped every open order you can, and cancel or refund anything you will not fulfil. Every order you close before the freeze is one less status you have to map or explain later. Note any refunds made under consumer guarantees so the record survives the migration.
3. Announce it properly. Post on the site, by email, and on social channels with the exact re-open time and where customers should shop in the meantime. That may be the new store on a temporary URL or the Square store kept live for browsing. If customers shop the temporary URL while Square still holds the catalogue, you may want to unlink products from Square to avoid duplicate inventory signals across two storefronts.
4. Take two exports. Take one at the moment of freeze, and one immediately before you repoint the domain. The second catches the orders, signups and stock changes that landed in the gap. Store both files off-platform with access limited. They contain customer records, which are personal information under the Australian Privacy Principles.
5. Log the freeze. Record the timestamp, the name of the person who paused checkout, and the count of open orders and on-hand units at that moment. That log is the starting number for every reconciliation that follows, including the product import in Phase 2.

Phase 2: Export and Import Products, Customers, and Order History

With the freeze logged and the first export secured, move through three data sets in a fixed order: products, customers, then orders.

1. Products first. Export SKUs, prices, tax classes, categories, images and variations, then import through WooCommerce's CSV importer or a dedicated migration tool. Check every variable product by hand. Variation-level SKUs are where mismatches most often go unnoticed.
2. Customers second. Import name, email, billing and shipping addresses, phone and marketing consent. Consent is the field most often dropped. If addresses move but opt-in status does not, your win-back campaign becomes an Australian Spam Act problem, not a data-tidiness one. A purchase alone does not establish marketing consent, and ACMA's consent record expectations cover how and when consent was obtained.
3. Orders third. Import the order records using the Square order import process, then confirm field by field that line items, totals, tax, shipping, discounts, status and dates landed as expected. Treat imported historical orders as reporting and dispute history rather than transactions you can refund from the new dashboard until you have checked what payment detail arrived with them.
4. Settle GST before importing. Confirm with your accountant whether Woo prices include or exclude GST and how tax classes map onto imported line items. If that answer changes mid-transition, your BAS reporting splits into two halves that will not reconcile.
5. Verify by counting. Compare exported row counts against imported row counts, then spot-check 10 to 20 real orders line by line, including one with a discount and one with a partial refund. Archive the source export files in case a difference appears weeks later.

Phase 3: Map Payments and Rebuild Checkout

The import gives you history; this phase gives you a working checkout. If you have not connected the WooCommerce payment gateway yet, do it before you import orders, because order status logic, refund flows and customer emails all depend on it. Confirm every method you currently offer, including cards and any wallets or buy-now options, is supported for Australian merchants before launch week. The connect your Square payments guide covers the configuration sequence.

Map each Square Online payment method to a WooCommerce equivalent. Where none exists, decide now: drop it, redirect those customers, or record it as an offline or manual method. Do not leave the gap for a live checkout.

Treat the WooCommerce merchant account as new even if the provider is the same. Payouts, settlement timing, dispute handling and refund routing change. Get the payout schedule and refund process confirmed in writing, then plan working capital for the settlement gap across the switch.

Run a full test-mode pass before real money moves: one successful order, one declined card, one full refund and one partial refund. For each, verify the order status, the customer email and the stock movement. A refund that fails to return stock, or an order that sits on hold, is cheaper to find now.

Decide who owns the money on a hybrid order. If Square POS stays for in-person and click-and-collect, agree before dual running which system records the payment and which records the stock movement. Write the rule down; the next phase reconciles stock and needs that rule to hold.

Phase 4: Reconcile Stock Before You Open the Doors

With payment routing settled, the stock ledger is your next dependency: if the opening balance in WooCommerce is wrong, every downstream check inherits the error.

Do a physical count at the freeze and make that count the opening balance in WooCommerce. Never import last-known Square quantities and assume they are accurate. Square Online holds a running figure, not a verified count, and any drift in it becomes an oversell on day one.

Reconcile three numbers per SKU

For every SKU, compare three figures: units counted, units Square says are on hand, and units already committed to open orders. Set a threshold, such as any variance greater than two units or any SKU with fewer than three units remaining, and investigate every SKU that crosses it instead of averaging the differences away. If your Square and WooCommerce dashboards still disagree once both stores run, a safety stock buffer rule closes the gap that a simple count cannot.

Handle committed stock explicitly

Orders taken before the freeze but not yet fulfilled must have their units deducted in whichever system will now own stock. Otherwise those same units stay available and get sold twice. Assign a named owner to that deduction pass and log every adjustment against the freeze count.

Resolve edge cases in writing

Work through bundles and kits that consume component stock, backorders, pre-orders, deposit-based orders, and any SKU sold both online and in store from one shared pool. Each one needs a named owner and a written rule before you go live. An unwritten rule is an oversell waiting for a busy Friday.

Set WooCommerce stock behaviour deliberately

Choose whether backorders are allowed or blocked, set low-stock notification thresholds, and decide out-of-stock visibility. Test one deliberate oversell scenario on staging and confirm the store blocks it before you open the doors.

With stock reconciled and WooCommerce behaviour verified, Phase 5 covers keeping both stores from selling the same unit during the parallel window.

Phase 5: Run Both Stores in Parallel Without Overselling

With opening balances now reconciled, keep the parallel window tightly controlled. For every SKU, decide which system owns the quantity. You can split ownership by SKU or by channel, but never let Square Online and WooCommerce decrement the same stock independently across the whole window. The typical failure is identical each time: two checkouts sell the last unit within a minute of each other.

Set a fixed end date of a few days up to one week and write it into the plan. Do not run promotions that send traffic to both stores at once; that raises collision risk on your fastest-moving lines.

If both stores genuinely need to accept orders, use a synchronisation layer instead of manual spreadsheet edits. SquareSync for Woo, the plugin this site covers, claims real-time sync of products, inventory, orders and customers plus a Find Square Matches duplicate check, but treat those as vendor claims and test them against your catalogue on a staging copy before either store relies on it. If Square also serves a physical shop, review how multi-store inventory setups work before the window opens.

Reconcile daily at close of business: compare stock movements and order counts across both systems, and log every manual adjustment with a reason. Unexplained adjustments later read as shrinkage or errors, and both erode trust.

Finally, prepare a kill switch. Know the two or three clicks that take one store's checkout offline, and name who is authorised to use them. A fast-moving SKU disagreement then becomes a five-minute interruption, not a week of apology refunds.

Phase 6: Repoint the Domain and Retire the Old Store

Once dual running closes and one system owns each SKU, the last move is the domain itself. Repoint it only after every earlier step is signed off.

Prepare DNS and redirects before you flip

Lower your DNS TTL well ahead of the switch so the change propagates quickly. Then repoint the domain at the Woo host by A record, nameservers or domain mapping, whichever your host documents. Take the repoint early in the day, mid-week, with support staff awake on both sides.

Build the redirect map first. Every indexed Square URL, including product, category and content paths, needs a 301 to its closest WooCommerce equivalent. WooCommerce permalinks do not mirror Square's structure, so assume nothing matches by default. Google's site-move guidance is blunt: combining a move with a change to URL structure probably costs traffic, because individual pages have to be relearned.

Update everything outside the store

Do it in one pass: Google Search Console and Bing, with the new sitemap and change of address submitted; Google Business Profile; your payment descriptor; email footers; invoice templates; social bios; and every directory or marketplace listing pointing at the old store.

Verify email survived

If business email runs on the same domain, confirm MX records are untouched, then send a test message from an external account. Do not call the domain move finished until it lands.

Pause, don't delete

Keep the Square Online store paused rather than closed for long enough to serve as your recovery window. It stays a retrievable archive of product images, descriptions and order notes, and a live target for redirects. Blocking or returning 404s on old URLs severs the redirect chain, so Google cannot pass signals forward. Before you formally retire it, settle how loyalty balances expire and how tier thresholds behave across both systems; this guide to aligning loyalty expiry shows how to define them once and mirror them. Then retire it formally.

Australian Considerations: GST, Payouts, and Market Data

With the domain repointed and the old Square store paused, work through the remaining Australian checks in order: GST and BAS records, market data, compliance surfaces, then shipping and returns.

Do not recalculate pre-switch GST using your new WooCommerce tax settings; the GST reported on an order should stay as it was recorded at the time. Export a Square report covering the period before cutover and file it with your BAS records. Confirm reporting treatment with your accountant, particularly for orders that straddle the switch date.

Budget for a settlement gap between the two gateways before you schedule a payroll run or a stock purchase.

Treat Australian market data with care. The ABS Retail Trade, Australia series has ceased, its final monthly estimate being the 771st. Current figures must come from another publication. Third-party headlines such as Power Retail's $26.08 billion e-commerce figure are useful scene-setting only when cited by name with no period attributed, because the underlying basis is unconfirmed.

Compliance surfaces move with the customers, not the platform. Privacy collection notices, cookie consent, and Spam Act consent records all need to survive the import intact. Check your WooCommerce privacy settings and your email platform's consent handling before you re-engage anyone on the migrated list.

Last, confirm shipping zones and rates for Australian postcodes, returns policy pages, and any age or licensing restrictions that Square Online enforced for you. None of those carry over automatically into WooCommerce settings. Verify each manually before you consider the cutover complete.

Post-Cutover Checks: 48 Hours, Week One, Month One

With shipping zones, consent records and GST treatment confirmed, the cutover is not finished at the domain switch. Run post-cutover checks on a fixed schedule and log the results.

First 48 hours. Place a low-value order with a real card and refund it in full. Confirm the confirmation, shipping and refund emails all arrive, and that stock decremented once and only once for that order. If the count moves twice, stop and trace the sync or import rule before accepting more orders.

Week one. Compare order counts in WooCommerce against your payment gateway dashboard. Investigate any gap the same day. Contact customers whose checkouts started before the redirect and did not complete. In Search Console, review 404s from old Square URLs and add any missed paths to the redirect map.

Month one. Run a second stock count. Shrinkage and mis-picks tend to surface only once a new system has been running for a while. Compare customer account creation rates with your old store, and look up one historical order to prove the imported history is usable by staff and customers.

Archive and document. Store the freeze exports, redirect map and reconciliation logs where you will still find them at tax time. Record what you deliberately left behind in Square so the next person does not rediscover it.

Conclusion: The Cutover Order That Protects Your History

Once the first month's checks are complete, write the pattern down rather than trusting memory. Start by naming the unmovable items and telling customers what they will need to re-enter.

Freeze deliberately and verify imports by counting rather than by trusting last-known quantities. Then map payments and reconcile stock before either store takes a live order. Then run both for a defined week with one system owning each SKU.

Repoint the domain last. Keep 301 redirects live, and keep the old Square store paused rather than deleted for a while longer. That pause is your recovery window for anything the import missed. That order is the difference between a migration and a reconstruction.