TL;DR: Free migration is a genuine and valuable offer, and it is scoped more narrowly than most people assume. What is almost always included is copying files and a database for one site. What is frequently excluded is everything else: email accounts and their contents, DNS records, server-level rules, cron jobs, redirect maps, SSL reissuance, and integration reconfiguration.
The result is a migration that technically succeeded and left the business broken in ways nobody noticed for days. Email stops silently. Payment gateway callbacks fail without erroring. Scheduled tasks quietly stop running. None of these appear on the migrated website, which looks perfect, which is precisely why they go undetected.
What free migration typically covers
Establishing the baseline, since it is genuinely useful and worth using.
Almost always included:
Copying website files from the old server to the new one. Exporting and importing the database. Updating configuration so the site connects to the new database. Basic verification that the site loads.
Frequently included at better providers:
Search-and-replace for URL changes if the domain is changing, done with a serialisation-aware tool rather than raw SQL, which matters enormously as the migration guide explains.
Setting up the site on a temporary URL so you can test before DNS changes.
Basic advice on DNS sequencing.
Why it is offered: migration friction is the main reason people stay with a provider they dislike. Removing that friction is how a host wins customers from competitors, which makes free migration a customer acquisition cost rather than charity. That is a perfectly reasonable arrangement and it explains the scoping — the provider will do enough to get your site running and no more.
What "free" means in practice: a defined task, performed by a team doing many of them, following a standard procedure. It is not a consultancy engagement examining your particular setup for things that might break.
The gap that creates: your business is not just a website. It is a website plus email plus integrations plus scheduled processes plus accumulated server configuration. The migration covers the first item and you own the rest, whether or not anyone told you.
The eight things routinely excluded
The list worth checking against any offer before you commit.
1. Email accounts and their contents. Mailboxes hosted on the old plan do not move with a website copy. Accounts must be recreated and existing mail transferred separately, which is a distinct technical operation.
2. DNS records. A migration copies your site; it does not replicate your DNS zone. If you change nameservers, every record must be recreated at the new provider, and missing MX records is the most common serious error.
3. Server-level configuration. Custom .htaccess or nginx rules, security headers, redirect rules, PHP settings you tuned, and rate limiting configuration. These accumulate over years and are rarely documented.
4. Cron jobs. Server-level scheduled tasks, as distinct from WordPress's own scheduling. Backups, syncs, report generation, cleanup scripts. They stop silently and are noticed weeks later.
5. SSL certificates. Certificates do not transfer; the new host issues fresh ones, which usually works and occasionally does not, particularly for wildcard or multi-domain certificates.
6. Redirect maps. If you have accumulated redirects for old URLs, and they live in server configuration rather than a plugin, they do not travel.
7. Integrations and IP whitelists. Your server IP changes. Payment gateways, SMTP providers, APIs and third-party firewalls that whitelist your address need updating, and these fail silently.
8. Testing. A provider confirms the site loads. Confirming that checkout works, forms submit, email sends, and the specific things your business depends on still function is your responsibility, and it is where problems are actually found.
Also commonly excluded: subdomains beyond the main site, staging environments, databases not attached to the main site, files outside the web root, and anything on a different server.
Why email is the biggest gap
The single most common post-migration crisis, and the one that damages the business fastest.
Why it happens: people think of their website and their email as one thing because both are "the website provider." Technically they are separate services that happen to be sold together, and a website migration addresses only one.
What goes wrong, in order of frequency:
MX records not replicated. If nameservers change and the destination zone lacks MX records, incoming mail stops immediately. No bounce to you, no error on your site, just silence. Customers assume you are ignoring them.
Mailbox contents not transferred. Accounts recreated at the new host are empty. Years of correspondence sits on the old server until that account is cancelled, at which point it is gone.
Authentication records missing. SPF, DKIM and DMARC TXT records not replicated means outgoing mail starts failing authentication. This is worse than an outage because it is invisible: you keep sending, delivery quietly degrades, and you learn about it when a customer says they never received an invoice, as the email deliverability guide covers.
Sending IP reputation reset. A new server means a new sending address with no established reputation, so deliverability can degrade even with everything configured correctly.
Website-generated email breaking. Contact forms, order confirmations and password resets configured against old SMTP settings.
The practical guidance: treat email as a separate migration project with its own plan and its own testing. And consider whether your mail should be on your hosting at all — separating it means a future hosting change does not touch it, which removes this entire category of problem permanently.
The silent failures
The category that makes post-migration problems dangerous: things that break without producing any visible error.
Payment gateway callbacks. Gateways send server-to-server notifications confirming payment. If your new IP is not whitelisted, or a security rule blocks them, payment succeeds at the gateway and the order never records on your site. You have the money and no order, and you discover it from customer complaints.
Cron jobs stopped. Backups not running is the worst version, because you find out when you need a backup. Also sync jobs, report generation, and cleanup tasks.
Outbound API integrations. Shipping providers, accounting sync, SMS and CRM connections that authenticate by IP.
Webhooks from third parties, which do not follow redirects and fail quietly.
Email authentication, as above.
Redirects lost, producing 404s on URLs that used to work, which shows in Search Console rather than to you.
Monitoring pointed at the old server, so you believe you have monitoring and do not.
Backups configured on the old host and not the new one, which means you have no backups and no indication of it.
The common characteristic: the website looks fine. Every one of these can be true while your homepage loads perfectly, which is why "the migration went well" is a judgement that should wait a week and a checklist rather than being made on switchover day.
Scope: what to ask before agreeing
Questions to ask in writing before committing, when you have leverage.
How many sites does the free migration cover? One is common. Agencies with a dozen sites should establish this early.
Does it include email accounts and mailbox contents? Ask explicitly. The answer is frequently no, and it is better known now.
Will you replicate my DNS zone, or is that mine? Get the answer before nameservers change.
Do you handle server-level configuration — custom rules, redirects, PHP settings, cron jobs?
Will you set up the site on a temporary URL for testing before DNS changes? This is the difference between a safe migration and a hopeful one.
Who manages the DNS switchover and TTL lowering? Lowering TTL two days ahead is what keeps the window to minutes, as the DNS propagation guide explains, and it cannot be done retroactively.
What is the timeline, and is there a maintenance window for the final data sync? Without a final sync, orders and submissions from between the copy and the switch are lost.
Is there a size or complexity limit? Large databases and sites with many files often exceed standard tooling.
What happens if something breaks after switchover? Is remediation included or billable?
Will you keep the old site running during propagation? That is on your old host, and it matters, so plan not to cancel immediately.
Get answers in writing. A support reply you can point back to resolves most disputes about scope later.
| Item | Usually in free migration | Who actually owns it | Failure is visible? |
|---|---|---|---|
| Website files | Yes | Provider | Yes |
| Database | Yes | Provider | Yes |
| URL search-replace | Often | Provider | Sometimes, settings vanish |
| Temporary URL for testing | Often | Provider | N/A |
| Email accounts | Rarely | You | Yes, eventually |
| Mailbox contents | Rarely | You | Yes, eventually |
| MX records | Rarely | You | No, mail just stops |
| SPF, DKIM, DMARC | Rarely | You | No, silent spam foldering |
| Server-level rules and redirects | Rarely | You | Partly, 404s in Search Console |
| Cron jobs | Rarely | You | No, until you need a backup |
| SSL reissuance | Usually automatic | Provider | Yes |
| IP whitelists and integrations | Never | You | No, silent failures |
| Final data sync | Sometimes | Negotiate | Yes, missing orders |
| Post-migration testing | No | You | Depends what you test |
Site count and complexity limits
Where free migration stops being adequate.
Multiple sites. One free migration is common. If you run five sites, ask whether each is covered or whether you are migrating four yourself.
Large databases. Standard migration tooling hits execution timeouts on very large databases, and the resolution requires command-line work that a standard migration process may not include.
Sites with enormous file counts. Media libraries with hundreds of thousands of files transfer slowly and sometimes incompletely, and verification is harder than it sounds.
Custom applications. Anything not standard WordPress may need specific handling that standard tooling does not cover.
Multisite installations. Considerably more complex than a single site, with network configuration, domain mapping and per-site tables. Ask specifically.
Sites with custom server requirements. Specific PHP extensions, unusual configuration, or software the new host must install.
High-traffic stores. The technical migration is the same; the scheduling is not. A store needs a maintenance window and a final sync, and doing it during trading hours risks losing orders.
The signal to negotiate or pay: if any of these apply, establish scope explicitly and consider whether paying for a managed migration is worth removing the risk. A paid migration on a revenue-generating store is cheap against a day of lost orders.
Doing your part properly
Assuming you use free migration, here is what you own.
Before:
Export your complete DNS zone and screenshot it. Every record type. This is your reference and your rollback.
Document your server-level configuration: custom rules, redirects, PHP settings, cron jobs.
List every integration that might whitelist your IP: payment gateway, SMTP, shipping, accounting, CRM, monitoring.
List your email accounts and decide how mailbox contents will move.
Take your own full backup, stored somewhere that is neither host.
Lower DNS TTL to 300 seconds two days ahead.
During:
Test on a temporary URL or via your hosts file before DNS changes. Homepage, interior pages, admin login, a form submission, and checkout with a test order.
Agree a maintenance window for the final data sync if your site accepts orders or submissions.
After, within the first hour:
Confirm the site loads on both www and the bare domain, and that SSL is valid.
Send a test email to the domain and from the domain, checking headers for authentication passes.
Place a test order and confirm the gateway callback recorded it.
After, within the first day:
Update every IP whitelist. This is the most commonly missed step and its failures are silent.
Verify cron jobs are running on the new server.
Confirm backups are configured on the new host.
Point monitoring at the new server.
Raise TTL back to normal.
After, within the first week:
Check Search Console for crawl errors and lost redirects. Verify mail deliverability. Then, and only then, cancel the old hosting.
When to pay for a migration instead
Cases where paying is the better decision.
Revenue-generating store with real order volume. The cost of a paid migration is trivial against a day of lost orders or a week of failed gateway callbacks. Pay for scope, testing and someone accountable.
Complex email requirements. Many mailboxes with substantial history, where transfer is a real project.
Multisite or custom applications, where standard tooling does not apply.
No internal technical capacity. If nobody on your side can perform the customer-side checklist above, the gaps in a free migration become gaps in your business.
Tight timing. If the migration must happen in a specific window with no room for iteration, paying for dedicated attention is reasonable.
Compliance-sensitive data. Where you need documented handling and evidence of what was moved and how.
What paying should get you: written scope covering everything in the excluded list, a tested rollback plan, a defined maintenance window, post-migration verification of the items that fail silently, and someone accountable if it goes wrong.
What it should not cost: a great deal. This is routine work for people who do it regularly, and the price should reflect scope rather than urgency.
The middle path most businesses take: use the free migration for the website, handle DNS and email yourself with the checklist above, and budget a few hours of your own time for verification. That works well provided you know the checklist exists, which is the entire point of this article.
FAQs
What does free website migration actually include?
Typically copying website files and a database for one site, updating configuration so the site connects, and basic verification that it loads. Better providers also handle URL search-and-replace and set up a temporary URL for testing. Email, DNS records, server-level configuration, cron jobs and integrations are usually your responsibility.
Does free migration include my email accounts?
Rarely. Mailboxes hosted on your old plan do not move with a website copy, so accounts must be recreated at the new host and existing mail transferred as a separate operation. Ask explicitly before committing, since discovering this after switchover is a bad week.
Why did my email stop working after migrating hosts?
Almost always missing MX records at the new DNS provider, since mail routing lives in the same DNS zone as your website records and a website migration does not replicate it. Missing SPF, DKIM and DMARC records cause a subtler failure where mail still sends but lands in spam without any error reaching you.
What breaks after a migration without showing an error?
Payment gateway callbacks failing because your new IP is not whitelisted, so payments succeed and orders never record. Cron jobs stopping, including backups. Outbound API integrations authenticating by IP. Email authentication. Redirects lost from server configuration. Monitoring still pointed at the old server. All of these can be true while your homepage loads perfectly.
Do I need to update anything after changing hosts?
Yes, and this is the most commonly missed step. Your server IP changed, so update whitelists at your payment gateway, SMTP provider, shipping and accounting integrations and any third-party firewall. Also reconfigure backups on the new host, verify cron is running, and point monitoring at the new server.
Should I cancel my old hosting immediately after migrating?
No. Keep it running for at least a week, because during DNS propagation some visitors still resolve to the old server, and if it is live they see a working site rather than an error. Cancelling on switchover day is a common mistake that turns a smooth migration into an outage for anyone with stale DNS.
What should I ask before agreeing to a free migration?
How many sites are covered, whether email accounts and mailbox contents are included, who replicates the DNS zone, whether server rules and cron jobs are handled, whether a temporary testing URL is provided, who manages TTL and switchover, whether there is a final data sync window, and what happens if something breaks afterwards. Get answers in writing.
How do I avoid losing orders during a migration?
Agree a maintenance window for a final data sync. Anything written to the old site between the initial copy and the DNS switch exists only there, so a store that continues taking orders during that gap loses them. Put the old site into maintenance mode briefly, re-sync, then switch.
Is a paid migration worth it?
For a revenue-generating store, complex email requirements, multisite installations or where you have no internal technical capacity, generally yes. The cost is trivial against a day of lost orders or weeks of silently failing gateway callbacks. What you should get is written scope, tested rollback, a defined window and post-migration verification.
Can free migration handle a very large site?
Often not without additional work. Standard tooling hits execution timeouts on large databases, and media libraries with hundreds of thousands of files transfer slowly and sometimes incompletely. Establish size limits before committing, since discovering them mid-migration is worse than planning around them.
Will my SSL certificate transfer to the new host?
Usually not directly. Most hosts issue a fresh certificate once DNS points at the new server, and a brief warning during that window is normal. Wildcard and multi-domain certificates occasionally need specific handling. Confirm HTTPS works properly within the first hour rather than assuming.
What is the single most important thing to do before migrating?
Export and screenshot your complete DNS zone, every record type, and lower your TTL to 300 seconds two days beforehand. The zone export is your reference and rollback for the records nobody else will replicate, and the TTL change cannot be done retroactively — it only works with lead time.
Conclusion
Free migration is a real offer worth taking, and it is scoped to the website rather than to your business.
The gap between those two things is where the problems live. Your website is files and a database. Your business is that plus email, DNS, scheduled jobs, server rules accumulated over years, and a set of integrations that authenticate by an IP address which is about to change.
What makes this dangerous rather than merely annoying is that most of the failures are silent. Email stops without bouncing. Gateway callbacks fail without erroring. Backups stop running and tell nobody. Every one of those is compatible with a homepage that loads perfectly, which is why "the migration went fine" should be a conclusion you reach after a week and a checklist rather than on the day.
Two actions carry most of the value. Export your complete DNS zone before anything changes, because MX records are the single most common serious omission and nobody else is going to replicate them for you. And after switchover, update every IP whitelist, because that is the step that fails quietly and costs money.
Then keep the old host running for a week. It is cheap, and it means anyone still resolving to the old address sees a working site instead of an error.
Ask the scope questions in writing before you commit, while you still have leverage. A provider that answers them clearly is telling you something useful about how the rest will go.
HostCloud includes free migration handled by our team, with DNS sequencing managed so both servers stay live through propagation, and we will tell you plainly what sits outside the scope before you commit rather than afterwards. Plans from ₹99 a month at https://www.hostcloud.in.