Moving a WooCommerce store from local to live

The fastest way to move a WooCommerce store from a local environment to Flashcloud is a migration plugin that exports your files and database together and imports them on the live server, including when you're moving from another site already on your account. Either way, do a full test checkout on the live copy before you point your domain at it, and use a maintenance window if the store has real customers waiting.

Local builds (Local by Flywheel, XAMPP, DevKinsta, Docker) don't have a public URL, so you can't use a simple database export alone. WordPress stores your site URL inside the database itself, in post content, widget settings, and serialized option fields. Copy the database as-is and every internal link still points at localhost or mysite.local.

The plugin path (most local-to-live moves)

A migration plugin like All-in-One WP Migration or Duplicator handles the export, transfer, and URL rewrite in one pass. The general flow:

1. On your local install, run the plugin's export. It packages your files, database, plugins, and themes into a single archive.
2. Install WordPress on your Flashcloud hosting first, using the WordPress install option in the portal or WordPress Management (WP Toolkit) in cPanel.
3. Install the same migration plugin on the fresh live install and run its import, pointing it at the archive from step 1.
4. Let the plugin handle the search-and-replace of your local URL for your live domain. This is the step that makes the site work; don't skip it or try to do it by hand in phpMyAdmin unless you're comfortable with serialized data (a plain find-and-replace on serialized fields corrupts them).

Large media libraries or big product catalogs can hit upload size limits on the free tier of some migration plugins. If your export is oversized, split it into a files package and a database package, or upload via FTP Accounts and import the database separately through phpMyAdmin.

If you're moving between two sites already on Flashcloud

If your "local" copy is actually a staging site on your Flashcloud account rather than a machine on your desk, the same plugin export-and-import steps above still apply, run in the direction of staging to live rather than live to staging. See Using WordPress staging for more on how staging sites work on your account.

Before you cut over: test the whole store, not just the homepage

A homepage that loads is not a working store. WooCommerce stores have moving parts that break silently after a migration: payment gateway API keys, shipping zone rules, and permalink structures all reference the site URL or environment in ways a plugin migration doesn't always catch.

Before pointing your domain at the new install, work through:

• Permalinks. Go to Settings → Permalinks in wp-admin and click Save, even if you change nothing. This flushes the rewrite rules for the new environment.
• Payment gateways. Most gateways (Stripe, PayPal, Square) need to be switched from test/sandbox mode to live mode, and some validate the domain they're registered against. Run a real test transaction, refund it if needed, and confirm the order shows up correctly in WooCommerce.
• Shipping zones and rates. Confirm your zones still match to a live address at checkout. If you're not sure how zones and rates fit together, see WooCommerce shipping: zones, classes, and live rates.
• Emails. Order confirmation and shipping notification emails often silently fail after a migration if SMTP settings pointed at a local mail catcher. Send yourself a test order and check that the email actually lands.
• SSL. Checkout requires HTTPS. Flashcloud issues a free Let's Encrypt certificate automatically once your domain's DNS points here, usually within a few minutes, and renews it without you doing anything. If checkout throws a mixed-content warning, it's almost always a plugin or theme hardcoding http:// URLs from the local environment.

Cut over without losing orders

If the local build is brand new with no customers yet, there's nothing to protect and you can point DNS as soon as testing passes. If you're replacing an existing live store, treat this like any risky WooCommerce change: keep the current live site untouched and working while you build out the new one, and only switch DNS once the new install has been through the full checklist above. Orders placed on the old site during your testing window can be lost if you're not tracking the cutover point carefully. Pick a low-traffic time, note the exact moment you switch, and check the old site's order list against the new one afterward.

Once the store is live, it's already running on the caching stack described in Running a WooCommerce store: LiteSpeed Cache for pages plus a Redis object cache. Check that cart and checkout pages are excluded from the page cache in the plugin's settings; if checkout pages ever appear to serve stale content, look for another caching layer first.

When to open a ticket

Large database imports that time out, migration plugins that fail partway through, or a checkout that still won't complete after working through the list above are worth escalating. Open a ticket from Support in the portal. A real person can check server-side logs and PHP limits that aren't visible from wp-admin, which is often faster than guessing at a broken import from the outside.