To move a WooCommerce store off shared hosting without losing orders, back up everything, build a copy on the new server, test it before DNS changes, run one final database sync while new orders are paused, then switch DNS and keep the old server available for rollback. That sequence matters more than any single tool. A store keeps changing while you work, and a plain file copy does not account for that.<\/p>\n\n\n\n
A brochure site can be copied on a quiet afternoon. A WooCommerce store collects orders, customer accounts, stock changes and scheduled tasks around the clock. Every hour between your first backup and your final switch is an hour of data the copy does not know about.<\/p>\n\n\n\n
We have hosted 700,000+ websites over 20+ years, and the migrations that go wrong share one habit. The owner treated the move as a copy job instead of a handover. This guide covers why stores outgrow shared hosting, what must be preserved, how to prepare, how to move the data, how to test and how to switch DNS with little downtime.<\/p>\n\n\n\n
Most stores move because they outgrow the resources a shared plan can give them. More shoppers, a bigger database and busy sales periods push against CPU, memory and process limits, and the owner has little control over the server to fix it. Slow pages and failed checkouts at the worst moments are the usual trigger.<\/p>\n\n\n\n
Concurrency is the number that hurts. A store with 5,000 visitors a day spread evenly is easy. The same 5,000 arriving in two hours after an email campaign is a different workload, because every shopper adding to a cart or opening checkout runs uncached PHP and database queries.<\/p>\n\n\n\n
On shared hosting that work competes with every other account on the machine, and the host caps how many processes your account may run at once. When the cap is hit, visitors see slow pages or errors even though the server itself is fine. Our cPanel web hosting<\/a> plans are a good home for a young store with modest traffic. They are not meant for a store that regularly spikes.<\/p>\n\n\n\n A simple test: look at your host’s resource usage graphs after your last busy day. If the lines touched the ceiling, you have your answer.<\/p>\n\n\n\n Shared plans set limits on CPU time, memory, disk speed and simultaneous processes. WooCommerce is hungry for all four, since pages like cart, checkout and My Account cannot be fully cached. Plugins for shipping, subscriptions and analytics add more.<\/p>\n\n\n\n The symptoms are specific. The admin area crawls while the front end seems fine. Checkout takes eight seconds. Orders appear late and emails queue up. You may see resource limit messages or 503 errors at peak times.<\/p>\n\n\n\n Before you decide to move, rule out the cheap fixes: a caching plugin tuned for WooCommerce, image compression, removing unused plugins and updating PHP. Those help a lot. They do not remove a hard limit, and when you hit that wall, hardware is the fix.<\/p>\n\n\n\n Every order writes rows into the database, and WooCommerce stores far more than the total on the receipt. Line items, shipping details, tax rows, customer notes and order metadata all land in tables. Modern WooCommerce can keep orders in dedicated tables through High-Performance Order Storage, called HPOS, while older stores keep them as posts and post meta.<\/p>\n\n\n\n Add customer sessions, scheduled action logs, coupon usage and plugin data, and the database grows quietly. A store with tens of thousands of orders often has a database several times larger than its media folder. Slow queries against that data are a common reason pages drag, and a shared database server gives you almost no way to tune it. On an NVMe VPS<\/a> you control the database settings and get fast storage underneath.<\/p>\n\n\n\n A tuned database is not magic. If a plugin runs a badly written query on every page, no server hides that for long.<\/p>\n\n\n\n On shared hosting you cannot change MySQL settings, choose PHP worker counts, install a Redis object cache or schedule server cron jobs freely. You work inside what the host allows. For many sites that is fine, and even a relief.<\/p>\n\n\n\n A growing store tends to want those levers. A real server cron job in place of WordPress’s built in task runner makes scheduled actions far more reliable. An object cache cuts repeated database reads. Control over the PHP version and extensions avoids waiting for a support ticket.<\/p>\n\n\n\n Control comes with duty, though. On a VPS you, or someone you pay, must patch the operating system, manage the firewall and watch disk space. If nobody on your team wants that job, price a managed option before you commit.<\/p>\n\n\n\n Peak periods like Black Friday, a product launch or a seasonal rush are where a weak hosting setup costs real money. A store that loses ten minutes of checkout during a sale has lost revenue it cannot get back. Plan for peak, not for the average Tuesday.<\/p>\n\n\n\n Work out your peak rate: orders per hour on your busiest day, multiplied by a safety margin of two or three. Then ask whether your current plan handled that day comfortably. If it limped, a VPS is the usual next step, and a dedicated server<\/a> suits stores whose traffic needs a whole machine.<\/p>\n\n\n\n Do the move well before the season, not during it. Migrating in November because the store is already struggling is how mistakes happen. Pick a quiet week and give yourself room to roll back.<\/p>\n\n\n\n Everything the store has recorded must come with you: orders and their metadata, customer accounts, products with variations and stock, uploaded media, coupons, tax and shipping settings and the configuration of payment gateways and integrations. Most of it lives in the database and the rest lives in files. Move one without the other and the store breaks.<\/p>\n\n\n\n Orders are the records you can never recreate. Each one includes line items, totals, statuses, addresses, notes, refunds and metadata added by plugins, such as tracking numbers or gateway transaction IDs. Accountants, customers and tax authorities all depend on them.<\/p>\n\n\n\n Where they live depends on your store. If HPOS is on, orders sit in dedicated tables such as wc_orders and wc_orders_meta. Older stores keep them in the posts and postmeta tables. A full database copy brings either layout across, which is why we recommend copying the whole database instead of exporting orders through a plugin.<\/p>\n\n\n\n A CSV order export is useful as an extra safety copy. It is not a migration method, because it loses metadata and relationships.<\/p>\n\n\n\n Customer accounts sit in the WordPress users and usermeta tables, with WooCommerce adding billing and shipping details, saved addresses and in some setups saved payment tokens. Passwords are stored as hashes, so customers can keep logging in after the move without resetting anything, provided the whole database comes across.<\/p>\n\n\n\n Do not export customers to a spreadsheet and import them again. You will lose password hashes, order links and any membership or loyalty data tied to their user ID. Keep the database intact and the relationships come with it.<\/p>\n\n\n\n Privacy matters here. Backups contain personal data, so keep them encrypted or at least out of public folders, and delete stray copies once the move is done.<\/p>\n\n\n\n Products and variations are stored as posts with a lot of metadata and attribute data, plus taxonomy tables for categories and tags. Stock levels live in product metadata, which means they change with every sale.<\/p>\n\n\n\n That last fact is the one people forget. If your first backup is taken on Monday and you cut over on Thursday, Thursday’s stock numbers come from Monday’s copy unless you sync again. Stores can oversell a bestseller after a move because inventory was never refreshed. The final database sync fixes it.<\/p>\n\n\n\n Check variable products with extra care. A product with forty variations has forty sets of price, stock and image data, and any gap shows up quickly on the product page.<\/p>\n\n\n\n The wp-content\/uploads folder holds product images, downloadable files and plugin generated files. It often grows to many gigabytes and is the slowest part of the transfer. Digital product stores must check that protected download folders and their permissions come across correctly.<\/p>\n\n\n\n Themes and plugins live in wp-content too. Copy the exact versions you run today, not newer ones from a fresh download, so the test copy behaves like the live store. Update after the move, one change at a time.<\/p>\n\n\n\n If you offload media to a CDN or an external storage service, note the settings and credentials now. Those links need to survive the move too.<\/p>\n\n\n\n Coupons are stored like posts, and usage counts are stored with them. Tax rates and shipping zones live in WooCommerce’s own tables and in the options table. Most settings sit in options, so they travel with the database.<\/p>\n\n\n\n Screenshots help. Before you start, capture the main WooCommerce settings screens, your shipping zones and your tax rates. If anything looks different after the move, you will have proof of what it should be. It takes ten minutes and has saved us arguments.<\/p>\n\n\n\n Add a note of any custom code snippets in the theme or a snippets plugin. Tax and shipping tweaks often hide there.<\/p>\n\n\n\n Gateway settings are saved in the database, including API keys, but the gateway account itself sits outside your store. Some gateways tie keys, webhooks or allowed IP addresses to your current server. Shipping carriers, accounting tools and email services may do the same.<\/p>\n\n\n\n List every external service that talks to your store. Write down what each one needs: a webhook URL, an IP allowlist, a callback address. Check each after the move. It is the step that gets forgotten, and a broken webhook can hide for days while orders quietly sit in the wrong status.<\/p>\n\n\n\n Preparation means six jobs: take full backups you have actually tested, record how the current server is set up, confirm the new server meets WooCommerce’s needs, lower your DNS TTL, build the new environment and write a rollback plan. Skipping any one of them is where most migration trouble starts.<\/p>\n\n\n\n Take a full backup of the files and the database, and store a copy away from your hosting account. For the database, use a tool that creates a consistent snapshot. On a server with command line access, mysqldump with the single transaction option does this for InnoDB tables without locking the store. Hosting control panels and plugins can also produce exports.<\/p>\n\n\n\n Then prove the backup works. Restore it somewhere harmless and check that it opens. A backup nobody has restored is a hope. Our reseller features<\/a> page lists the backup and security options on our plans, and whichever host you use, ask what they keep and for how long.<\/p>\n\n\n\n Keep this first backup untouched. It is your oldest safety net.<\/p>\n\n\n\n Write down the PHP version and extensions, the database type and version, the WordPress and WooCommerce versions, the active plugin list with versions, the web server software and any custom settings in php.ini or .htaccess. The WooCommerce System Status page collects much of this on one screen.<\/p>\n\n\n\n Also note scheduled jobs, special redirects and anything customized outside the WordPress admin: custom code in the theme, server rules, firewall exceptions. The documented item is the one you will remember to recreate. The forgotten one breaks checkout at midnight.<\/p>\n\n\n\n Save the whole list in a shared document, not on your laptop, so a colleague can follow it if you are unavailable on migration day.<\/p>\n\n\n\n Check what WooCommerce currently requires for PHP and for MySQL or MariaDB, and compare the new server to that list. Then check every plugin. An old payment plugin that works on an older PHP release may fail on a newer one.<\/p>\n\n\n\n If the new server runs a newer PHP version than the old one, treat that as a second project. Change one big thing at a time. Move first on matching versions if you can, test, and upgrade PHP afterward. Two changes at once make a failure impossible to trace.<\/p>\n\n\n\n Check that the PHP extensions WooCommerce and your plugins rely on, such as those for images and compression, are installed on the new server.<\/p>\n\n\n\n TTL, or time to live, tells resolvers how long to cache your DNS records. If it is set to 24 hours, some visitors will keep reaching the old server for up to a day after you switch. Lower it to about five minutes, ideally one to two days before the cutover.<\/p>\n\n\n\n The timing matters. The old, longer TTL must expire before the short one takes effect everywhere. Lowering it an hour before you switch does almost nothing. Put a reminder in the calendar, and raise the TTL again a few days after the move.<\/p>\n\n\n\n If you put a proxy in front of the store, such as CloudFlare CDN<\/a>, you may be able to change the origin address without waiting on DNS caches, which makes the cutover quicker. Check how your own setup behaves before relying on that.<\/p>\n\n\n\n Set up the server before you copy anything. Install the web server, PHP with the right extensions and the database server, and settle your SSL plan. Create an empty database and a database user with a strong password and rights only to that database. Set the PHP memory limit, upload limits and execution time at sensible levels for a store.<\/p>\n\n\n\n Our servers use Intel Dual Xeon hardware with NVMe drives and LiteSpeed, which suits the constant small reads and writes a store makes. If you want a deeper look at drive types, see our page on NVMe drives versus SSDs<\/a>. And if your new environment has a panel with an installer such as Softaculous<\/a>, you can drop in a clean WordPress to confirm the server works before the real data arrives.<\/p>\n\n\n\n Set up a real cron job too. WordPress’s built in scheduler only runs when someone visits the site, which is a weak foundation for a store. A server cron job that calls wp-cron.php every few minutes, with the built in trigger switched off in wp-config.php, keeps scheduled actions running on time.<\/p>\n\n\n\n Decide now what failure looks like and what you will do about it. Examples: checkout errors above a set rate, orders not appearing in the admin, payments not confirming. Write the trigger and the action next to each.<\/p>\n\n\n\n The rollback itself is usually simple if you prepared it. Point DNS back at the old server, which is still running and still holds the last good data. The catch is orders placed on the new server after the switch. If you roll back, you must bring those orders back to the old site or accept losing them. Know that before you start.<\/p>\n\n\n\n Set a point of no return, perhaps a few days after the move, after which the old server is retired.<\/p>\n\n\n\n Copy the WordPress files and media, import the database into a new empty one, update wp-config.php with the new database details, confirm settings and permalinks, set up SSL and server rules, and finish with a final sync of orders and customers just before DNS changes. Do the first full copy early, and treat the last sync as a separate, short event.<\/p>\n\n\n\n Transfer the full WordPress directory, including wp-content with themes, plugins and uploads. Use rsync over SSH or SFTP when you can, since rsync resumes interrupted transfers and only sends changes. Downloading to your laptop and uploading again works, but doubles the time.<\/p>\n\n\n\n Because uploads are large and mostly static, copy them early and then run rsync again at the end. The second pass sends only new files, so it takes minutes. Check file ownership and permissions afterward. Directories at 755 and files at 644 are the usual defaults, with wp-config.php locked down tighter. Wrong ownership causes failed uploads and plugin update errors that look unrelated.<\/p>\n\n\n\n Export the database from the old server and import it into the empty database on the new one. For a small store, phpMyAdmin may be fine. For a large one it will time out, so use the command line instead, with mysqldump for the export and the mysql client for the import. WP-CLI offers wp db export and wp db import if it is installed.<\/p>\n\n\n\n As a made up example, a database of 600 MB might import in a couple of minutes on a fast server, while one ten times that size takes far longer. That duration decides how long your final sync window will be. Time your first import. It gives you the real number.<\/p>\n\n\n\n Open wp-config.php on the new server and update DB_NAME, DB_USER, DB_PASSWORD and DB_HOST to match the new database. DB_HOST is often localhost on a single server but not always. Check the table prefix, set by the table_prefix line, and make sure it matches the imported tables exactly. A mismatch shows up as a fresh WordPress install screen, which alarms people but is easy to fix.<\/p>\n\n\n\n Do not edit the live site’s file by accident. It is an easy slip to make, so label your terminal windows and keep clear which server you are connected to.<\/p>\n\n\n\n If you test on a temporary address and the domain differs, replace the URLs in the database with a tool that understands serialized data, such as the WP-CLI search and replace command. A plain text replace can corrupt serialized settings. With the same domain and a hosts file test, you can skip this step entirely, which is simpler and safer.<\/p>\n\n\n\n Most settings arrive with the database. Still, confirm them. Log in to the admin area on the test copy and check WooCommerce settings, shipping zones, tax rates, email templates and payment methods. Then go to Settings, Permalinks and click Save to flush rewrite rules. That one click fixes a surprising number of 404 errors on product pages.<\/p>\n\n\n\n Check the WooCommerce Status page for warnings and review the active plugins. Clear every cache, including page cache, object cache and plugin caches. Cart, checkout and account pages must be excluded from page caching, or customers can end up seeing each other’s cart data. A caching mistake here is worse than slowness.<\/p>\n\n\n\n Your store must serve HTTPS from the first minute after DNS changes, or browsers will warn shoppers away from checkout. Free certificates that validate over HTTP usually need the domain pointing at the new server. Your options are to use DNS based validation, install your existing certificate and key on the new server, or issue the new certificate the moment DNS changes and accept a brief gap.<\/p>\n\n\n\n Decide this in advance. Also move server level rules: redirects between www and non www, HTTP to HTTPS redirects, security headers, upload size limits and any rules that protect downloadable products. Since we run LiteSpeed, we find that rewrite rules from an old .htaccess file generally carry over, but test them instead of assuming.<\/p>\n\n\n\n This is the step that separates a safe migration from a risky one. Your first copy is already out of date by the time you finish testing, because customers kept ordering. So you freeze the old store briefly, take a fresh database export, import it on the new server and sync any new files.<\/p>\n\n\n\n Do not try to merge new orders by hand into the copy. Order IDs, stock counts, customer records and HPOS tables are tangled together, and a partial merge creates duplicates or gaps. Replacing the new server’s database with a fresh full export is far safer, as long as no testing data on the new server needs to survive. It should not.<\/p>\n\n\n\n Freezing orders for 15 to 30 minutes at a quiet hour is a small cost. Live replication from the old database to the new one can avoid even that, but it is complex and easy to get wrong, so we would only suggest it for stores that truly cannot pause.<\/p>\n\n\n\n Test with DNS still pointing at the old server, using a hosts file entry on your own computer so you see the new server under the real domain name. Check old orders and accounts, products, the full checkout in test mode, gateways and webhooks, shipping, tax, coupons, emails and scheduled actions. If anything fails, you have lost nothing.<\/p>\n\n\n\n Open the orders list and compare counts with the old store. The totals should match exactly, along with the newest order number. Open a handful of old orders from different years and compare line items, notes and refunds side by side with the old site.<\/p>\n\n\n\n Then check customers. Log in as a test customer whose password you know and confirm that order history and addresses show. Check the reports in the WooCommerce admin, which should match the old figures. A count mismatch at this stage is a gift. It tells you something went wrong while there is still time to fix it.<\/p>\n\n\n\n Browse like a shopper. Open category pages, search results, product pages with variations and products with images, galleries and downloads. Check that prices, sale dates and stock statuses are correct.<\/p>\n\n\n\n Compare stock for a few products against the old store, and watch for broken images, which usually point to missing uploads or wrong permissions. Look at page load times too. Server location affects them, and our 25 worldwide locations and multi-location hosting<\/a> let you place a store near its shoppers. If the new server is not clearly faster on the same pages, find out why before you cut over.<\/p>\n\n\n\n Run the whole path: add items, change quantities, apply a coupon, enter an address, choose shipping, pay and reach the thank you page. Do it as a guest and as a logged in customer. Try a variable product and a digital product if you sell them.<\/p>\n\n\n\n Be careful on a test copy. It can send real emails to real customers and, if gateways are in live mode, take real payments. Put gateways in test mode, and stop or redirect outgoing mail on the test copy. A customer receiving a test order confirmation is embarrassing, and a duplicate renewal charge from a subscription plugin is worse.<\/p>\n\n\n\n Use each gateway’s test or sandbox mode to complete payments, including a failed card and a refund. Then confirm that the order status updates as it should. Status updates after payment usually depend on a webhook or callback reaching your store.<\/p>\n\n\n\n Webhooks target your domain, so during testing with a hosts file entry, outside services will still reach the old server, not the new one. That means you cannot fully test webhook delivery until DNS changes. Plan for that. After cutover, watch your gateway’s dashboard for failed webhook deliveries and resend them. Most gateways show failures and let you replay events.<\/p>\n\n\n\n Test each shipping zone and method with realistic addresses. Test tax calculations for a few regions and for a tax exempt customer if you have one. Test coupons with their rules: minimum spend, expiry and usage limits.<\/p>\n\n\n\nResource limits affecting store performance<\/h3>\n\n\n\n
Database workload from orders and customer activity<\/h3>\n\n\n\n
Limited server-level control<\/h3>\n\n\n\n
Performance requirements during peak sales periods<\/h3>\n\n\n\n
What WooCommerce Data Must Be Preserved During a Hosting Migration?<\/h2>\n\n\n\n
Historical orders and order metadata<\/h3>\n\n\n\n
Customer accounts and customer data<\/h3>\n\n\n\n
Products, variations, and inventory<\/h3>\n\n\n\n
WordPress media and uploaded files<\/h3>\n\n\n\n
Coupons, taxes, shipping, and store settings<\/h3>\n\n\n\n
Payment gateway and integration configuration<\/h3>\n\n\n\n
How Do You Prepare a WooCommerce Store Before Moving It?<\/h2>\n\n\n\n
Creating a complete backup of files and database<\/h3>\n\n\n\n
Recording the current hosting and software configuration<\/h3>\n\n\n\n
Checking PHP, database, and plugin compatibility<\/h3>\n\n\n\n
Lowering DNS TTL before the migration<\/h3>\n\n\n\n
Preparing the new hosting environment<\/h3>\n\n\n\n
Planning a rollback before making the final switch<\/h3>\n\n\n\n
How Do You Migrate WooCommerce From Shared Hosting to the New Server?<\/h2>\n\n\n\n
Transferring WordPress files and media<\/h3>\n\n\n\n
Importing the WooCommerce database<\/h3>\n\n\n\n
Configuring the new database connection<\/h3>\n\n\n\n
Restoring WordPress and WooCommerce settings<\/h3>\n\n\n\n
Reconfiguring SSL and server-level settings<\/h3>\n\n\n\n
Synchronizing final order and customer data before DNS cutover<\/h3>\n\n\n\n
How Do You Test a Migrated WooCommerce Store Without Losing Orders?<\/h2>\n\n\n\n
Checking historical orders and customer accounts<\/h3>\n\n\n\n
Testing product pages and inventory<\/h3>\n\n\n\n
Testing cart and checkout functionality<\/h3>\n\n\n\n
Verifying payment gateways and webhooks<\/h3>\n\n\n\n
Testing shipping, tax, coupons, and transactional emails<\/h3>\n\n\n\n