Free migration is only valuable when it moves the whole working site, preserves the data that changes during the cutover, and leaves you with a faster, verifiable result. When comparing wordpress hosting with free migration, ask who performs the transfer, what they exclude, how they handle DNS, and what happens if checkout orders or form submissions arrive mid-move. A free transfer that copies files but misses mail records, cron jobs, redirects, or recent WooCommerce orders is not free. It creates cleanup work and business risk.
What free WordPress migration should actually include
A competent managed migration is more than exporting a database and zipping `wp-content`. At minimum, the host should copy WordPress core files, themes, plugins, uploads, the full database, and the configuration needed for the new environment. They should also provide a temporary preview method so you can test the migrated site before public DNS changes.
The important distinction is between a basic copy and an operational handoff. A basic copy may be enough for a small brochure site with low traffic. An operational handoff matters for a WooCommerce store, membership platform, lead-generation site, multisite installation, or any site using external services and scheduled jobs.
Ask for a plain answer on scope before you authorize access. The migration should identify whether it includes redirects, SSL provisioning, DNS guidance, cron configuration, transactional email checks, cache setup, and a post-migration review. None of these are exotic extras. They are common places where a site looks fine on the home page but fails under real use.
| Area | What to verify | Why it matters | | --- | --- | --- | | Files and database | All site files, uploads, tables, and serialized data are copied | Missing media or incomplete tables can create delayed failures | | DNS and SSL | The cutover plan, certificate issuance, and rollback path are clear | A good migration can still cause downtime through bad DNS handling | | Dynamic data | Orders, users, bookings, comments, and form entries have a plan | Database changes can occur while the copy is running | | Email and third parties | SMTP, payment gateways, webhooks, analytics, and API keys are tested | These services often depend on the live domain or server IP | | Performance | Caching, PHP version, object cache, and server resources are reviewed | Moving a slow site without correcting the bottleneck changes little |
Prepare your site before the migration team touches it
The host can run the transfer, but you still own the application. Give the team a clean, documented starting point. This reduces failed migrations and makes it much easier to separate a pre-existing issue from a new hosting issue.
Start by recording how the current site behaves. Capture a few key URLs, current page-load timings, admin login behavior, checkout behavior, and any known errors. If the site is already slow, record its Time to First Byte and the plugins active at the time. Otherwise, a post-move speed discussion turns into guesswork.
Create an independent backup before any work begins. The new host should take one too, but an independent restore point protects you from account-access mistakes, corrupted source backups, and accidental changes made during preparation. For stores and membership sites, note the exact time of that backup.
Next, inventory the parts that do not live entirely inside WordPress. Common examples include DNS records, email routing, CDN settings, payment webhooks, domain-based API restrictions, object storage, and external cron services. Changing web hosting does not automatically move these services. Worse, changing nameservers without documenting MX, SPF, DKIM, and DMARC records can break email even when the website works perfectly.
If you have shell access, collect basic facts before the move:
wp core version wp plugin list --status=active wp theme list --status=active wp cron event list wp option get home wp option get siteurlSave the output with your migration notes. It gives you a fast way to spot a missing plugin, an unexpected PHP compatibility issue, or a scheduled task that was not recreated.
Handle WooCommerce and other dynamic sites differently
A content site can often tolerate a short content freeze during final synchronization. A store cannot safely assume that. New orders, account registrations, stock updates, and payment gateway callbacks write to the database continuously.
For WooCommerce, agree on the final sync method and the exact cutover window. A common approach is an initial full copy, followed by a brief maintenance window or order pause while the host runs a final database sync. The right method depends on order volume, checkout architecture, and whether inventory is also managed in an external system.
Do not treat maintenance mode as a complete solution by itself. It can stop public checkout activity, but payment callbacks and background tasks may still arrive. Test a real transaction after the move, then confirm the order status, stock reduction, confirmation email, and gateway dashboard record all match.
How the cutover should work
Good migrations use a staged sequence: copy, preview, validate, synchronize dynamic data, then change DNS. DNS should be the final public switch, not the start of testing.
Lower the DNS TTL ahead of time if you control the zone. A lower TTL can reduce how long some visitors resolve the old address after the record change, though it does not override resolver behavior everywhere. Keep the old hosting account active until the new site has been verified under the live domain and traffic has settled.
The preview environment deserves real testing. Do not approve a migration because the homepage renders. Cached homepages are easy. Test uncached paths and authenticated actions: WordPress admin, search, contact forms, password reset, account login, cart updates, checkout, and any custom application endpoint. If the site has a staging environment, confirm that staging is not accidentally allowed to send customer emails or process live payments.
Also check search engine settings. A temporary migration URL should not become the canonical URL, and a staging environment should not be indexable. After cutover, confirm that `home` and `siteurl` point to the production HTTPS domain and that redirects resolve in one hop where possible.
Validate the new host after DNS changes
The migration is not complete when DNS propagates. It is complete after the production site survives the workflows that make money, collect leads, and keep the application healthy.
Use this production checklist during the first hour:
- Load key pages in a private browser window and while logged in.
- Submit a form and verify delivery, not just the success message.
- Place a low-value test order if the store supports it, then verify payment, email, and fulfillment flow.
- Review PHP and web-server error logs for fresh warnings, fatal errors, and upstream timeouts.
- Confirm scheduled actions and WordPress cron events are running on schedule.
- Purge caches and retest a changed page to ensure you are not seeing stale content.
Pay close attention to errors that appear only under logged-in or uncached traffic. Full-page caching can hide an overloaded PHP pool, slow database queries, or blocked external requests. On WooCommerce, the cart, checkout, account area, and background Action Scheduler jobs are the first places resource limits show up.
Free migration cannot compensate for weak infrastructure
The transfer process protects continuity. It does not cure slow hosting. If the source site suffers from high TTFB because PHP workers are saturated, the database is slow, or the account shares CPU with too many noisy neighbors, moving it to another overloaded platform simply relocates the bottleneck.
Ask what resources are actually available to your site. Useful answers mention PHP worker capacity, memory limits, database behavior, server-level object caching, storage performance, and how support investigates load spikes. Vague promises of unlimited traffic or optimized WordPress do not explain what happens when ten uncached checkouts hit PHP at once.
Hardware matters, but only as part of a complete stack. High-frequency CPUs help WordPress because PHP execution and many database operations are latency-sensitive. Modern dedicated hardware, such as AMD Ryzen 9950X systems, can materially improve response time when paired with sane worker limits, tuned NGINX or LiteSpeed rules, object caching, and an actively monitored database. It will not fix an expensive plugin query or a broken external API call, so the host should be willing to show where time is being spent.
A platform such as WP Tango is most useful when the migration is treated as the start of an operational review: confirm cache behavior, inspect slow requests, establish reliable backups, and test recovery before an incident forces the issue.
Warning signs before you approve a host
Be cautious if a provider cannot describe whether migration is manual or automated, offers no preview environment, or asks you to cancel the old account before validation. Those are process failures, not minor inconveniences.
The same applies to hosts that call a migration complete without checking forms, email, cron, and commerce workflows. A generic transfer tool is useful, but it cannot know which custom plugin routes revenue, which webhook expects the old IP, or whether a stale cache is serving an outdated product catalog.
Free migration should remove the mechanical burden of moving WordPress, not transfer the risk to you. Choose the provider that can explain the cutover plan before it begins, prove the site works after it ends, and stay accountable when production traffic exposes the details that a homepage test missed.
