Hosting Migration & Backup Fee Checklist: What Hosts Charge

Cost line item	Shared / managed WordPress	VPS / dedicated / cloud	What it is really worth
Site migration (one site)	Usually free on the standard plan; limits on plugin count, database size, or file count may apply	Rarely included; offered as paid add-on, billed hourly, or self-serve only	Free migration is genuine on shared and managed WordPress; on VPS and cloud, expect to do it yourself or pay a fee.
Migration for additional sites	Often a paid add-on after the first free migration; sometimes $10 to $50 per site	Billed hourly or by request; $50 to $200+ per site on managed services	If the host allows only one free migration, the second site is a real cost, not a freebie.
Plugin and database size limits	Migration may be limited to a maximum number of plugins or a maximum database size; oversized sites fall outside free migration	Limits are usually based on server resources rather than a fixed plugin count	A 5 GB WooCommerce database may not fit inside a free shared migration limit.
Email migration	Often free as part of a hosting plan; may be a paid add-on or excluded entirely	Often excluded; mailboxes and forwarders must be set up manually or via a paid service	Mailbox counts above a free threshold (e.g., 10 or 25) are usually a paid add-on.
DNS changeover window	0 to 48 hours typical; 5 minutes to 72 hours in the worst case	0 to 48 hours typical; depends on registrar TTL	Lower the TTL to 300 seconds at least 24 hours before the cutover to reduce the worst-case window.
SSL certificate migration	Usually free via Let's Encrypt on the new host; some hosts charge for dedicated or wildcard certificates	Free Let's Encrypt available; dedicated and wildcard certificates are usually paid	A free Let's Encrypt certificate covers most sites; wildcard and EV certificates are an extra cost.
Automated backup retention	7 to 30 days on the standard plan; longer retention is often a paid add-on	Backups often a separate line item; 7-day retention is common on entry VPS plans	Retention windows shorter than your update cycle are a real risk; longer windows are usually paid.
Off-site backup storage	Rarely included; offered as a paid add-on or as a third-party integration (e.g., S3, Backblaze)	Usually a paid line item, billed as a percentage of server cost or per GB	Off-site backups protect against host-level failures; on-site backups do not.
On-demand backup restore	Self-service restore within retention is usually free; request-based restore may be paid	Self-service restore is normal on VPS and cloud; managed services may bill hourly	Test the restore path during onboarding, not during an outage.
Point-in-time restore	Rarely included; offered as an add-on on managed WordPress plans	Available on managed databases and some cloud plans; usually paid	Point-in-time restore is the only way to recover from a database corruption event that is not the latest change.
Malware scan and cleanup	Often included as a basic scan; full cleanup is usually a paid add-on or a one-time fee	Customer's responsibility unless a managed security add-on is purchased	A basic scan tells you there is a problem; cleanup is the part that costs.
Migration help desk hours	Often 24/7 on managed plans; business hours on entry-level shared plans	24/7 on managed cloud; business hours on unmanaged VPS	If the migration needs a senior engineer, business hours are a real cost in delayed cutover.

The cheapest way to read this table is to assume migration is free on shared and managed WordPress hosting, self-serve on VPS and cloud, and that backup retention and on-demand restore are the line items that turn into fees the moment you actually need a restore.

Site migration in detail

Site migration is the most common reason a buyer interacts with the host's migration team. On shared and managed WordPress hosting, free migration is usually a single-site offer with limits. The standard offer typically covers one website, a maximum plugin count (often 25 to 50), a maximum database size (often 500 MB to 2 GB), and standard file types. WooCommerce sites with large product catalogs, multisite networks, and sites with custom database tables usually fall outside the free migration limit and require either a paid migration or a manual migration.

On VPS, dedicated, and cloud hosting, migration is rarely included in the base plan. The host may offer a paid migration add-on (often $50 to $200 per site), bill the migration hourly, or expect the customer to migrate manually using SSH, SFTP, and phpMyAdmin or a similar database tool. The cheapest path on VPS is usually to migrate yourself; the cheapest path on a fully managed cloud plan is to pay for the migration service and treat the cost as part of the onboarding.

The migration workflow below is the one that produces the cleanest cutover with the shortest downtime window.

1. Audit the source site. Inventory the plugins, themes, custom code, scheduled tasks, cron jobs, and external integrations. Anything not in the inventory is at risk of being lost during migration.
2. Confirm the source site's database size and file count. Compare against the host's free migration limit. If the site exceeds the limit, plan for a paid migration or a self-serve path.
3. Lower the TTL on the domain at the registrar. At least 24 hours before cutover, lower the TTL to 300 seconds (5 minutes). This reduces the worst-case DNS propagation window.
4. Create the destination site on the new host. Install the stack, create the database, set the file structure, and apply the SSL certificate.
5. Transfer files and database. Use a migration plugin (All-in-One WP Migration, Duplicator, Migrate Guru), manual SFTP + phpMyAdmin, or a paid migration service. Verify checksums and database integrity after the transfer.
6. Update DNS records at the registrar. Point the domain to the new host's IP addresses and update the MX records if email is moving too.
7. Test the new site on a hosts file override before changing DNS. Map the domain to the new host's IP in your local hosts file, browse the site, test forms, logins, and checkout flows. Catch errors before the public cutover.
8. Cut over DNS during a low-traffic window. Lower traffic means fewer visitors see the propagation lag.
9. Monitor DNS propagation and 5xx errors for 24 to 48 hours. Have a rollback plan: the old site stays live on the old host's IP for at least 48 hours, ready to switch back if the new site fails.
10. Cancel the old hosting only after the new site is stable. Screenshot the cancellation confirmation, save the last backup, and verify no further charges on the next billing cycle.

Skipping the hosts file test is the most common cause of "the site is broken after cutover" tickets. Skipping the rollback plan is the most common cause of "we have to rebuild from scratch" stories.

DNS changeover time in detail

DNS changeover is the part of the migration where downtime risk lives. The TTL (time to live) on the domain's DNS records determines how long resolvers cache the old IP before checking for a new one. A TTL of 86400 seconds (24 hours) means resolvers may keep returning the old IP for up to 24 hours after the records change; a TTL of 300 seconds (5 minutes) means resolvers check again within 5 minutes.

Most registrars default to a TTL of 3600 to 86400 seconds. Lowering the TTL to 300 seconds at least 24 hours before cutover gives resolvers time to pick up the shorter cache window, so when the records actually change, the worst-case window shrinks from 24 hours to 5 minutes. This is one of the few free actions that materially reduces downtime.

DNS propagation is rarely zero. Some resolvers honor the TTL strictly; others ignore it and use their own caching window. CDN providers, corporate networks, and mobile carrier resolvers sometimes cache aggressively. The realistic worst-case window is 0 to 48 hours, and the realistic best case is 5 to 30 minutes. Plan for the worst case and the cutover will feel smooth.

Backup retention in detail

Backup retention is the single most common hosting line item that buyers miss. Most shared and managed WordPress hosts include automated daily backups in the base plan, with retention windows of 7 to 30 days. Longer retention (60, 90, or 365 days), off-site storage, and point-in-time restore are commonly paid add-ons. VPS, dedicated, and cloud hosting often charge for backups as a separate line item, either as a percentage of server cost (commonly 10% to 20% of the plan) or as a per-GB storage fee.

The retention window should match the site's update cycle. A blog that updates weekly needs at least 7 days of retention to recover from a bad update. An ecommerce site that updates multiple times a day needs at least 30 days of retention, ideally with point-in-time restore, to recover from a payment processor bug or a database corruption event that is not caught immediately. A site that is updated infrequently can run on 7-day retention, but should still consider off-site backups because on-site backups do not protect against host-level failures.

The cheapest way to set up backups is to combine the host's automated backups with a third-party off-site backup plugin (UpdraftPlus, BackupBuddy, BlogVault) that writes to S3, Backblaze, or Google Drive. The third-party backup is independent of the host's infrastructure and survives a host-level failure. The cost is the storage fee at the third-party provider, which is usually a few dollars per month.

On-demand restore in detail

On-demand restore is the line item that turns into a fee the moment you need it. The restore process differs across hosts in three ways:

• Self-service restore: the customer clicks a button in the host's control panel and restores a backup to the live site. This is the cheapest and fastest option, and it is standard on most managed WordPress hosts and on most VPS and cloud plans.
• Request-based restore: the customer submits a support ticket, and the host's team performs the restore. Some hosts include this in the base plan; others bill hourly for restoration work.
• Out-of-retention restore: the customer needs a backup from a date outside the host's retention window. Most hosts cannot perform this restore because the backup no longer exists.

The cheapest way to handle restore is to test it during onboarding, not during an outage. A 15-minute restore test on a staging or test site confirms that the restore path actually works, the backups are intact, and the team knows the steps. A restore test that fails during an outage is the most expensive way to learn that the retention window was shorter than expected.

What does not move when you switch hosts

A useful way to plan a hosting migration is to list everything that does not survive the move. The inventory below is the list of items that have to be rebuilt or reconfigured on the new host.

• Server-level configuration: PHP version, memory limits, max execution time, Apache or Nginx rules, .htaccess rewrites. Rebuilt manually on the new host.
• Email accounts and forwarders: rebuilt manually unless the host offers a free mailbox migration. Mailbox passwords reset.
• DNS records: A records, AAAA records, MX records, TXT records (SPF, DKIM, DMARC), CNAMEs. Updated at the registrar, not at the host.
• SSL certificate: reissued or re-installed on the new host. Let's Encrypt certificates are usually reissued automatically; dedicated and wildcard certificates are manual.
• Scheduled tasks and cron jobs: rebuilt on the new host's cron scheduler. Cron expressions and execution environments differ across hosts.
• Backups taken on the old host: do not transfer to the new host. Download the most recent backup before canceling the old plan.
• Control panel preferences: access logs, error log retention, hotlink protection, and rate-limiting rules. Rebuilt on the new host.
• Staging environments: rebuilt on the new host. Some hosts include staging in the base plan; others charge separately.
• Email authentication (SPF, DKIM, DMARC): updated at the registrar's DNS records when the email host changes. Failure to update causes email to land in spam.

The dollar cost of these items is usually zero or small, but the hour cost is real, and it is the part that migrations most often underestimate. A simple WordPress site with one mailbox and a Let's Encrypt certificate is looking at one to three hours. A WooCommerce site with 10 mailboxes, custom cron jobs, and a dedicated IP is looking at half a day or more.

Affiliate-aware note: CJ-partner providers and hosting migration

PriceGap currently does not claim current advertiser approval with any hosting provider, and this article contains no advertiser checkout links. For context, providers tracked as potential CJ advertiser candidates — such as Hostinger, Interserver, and eUKhost — are part of a separate advertiser-application workflow. If a future affiliate link is added to this page, it would be a tracked link to a specific provider's migration, backup, or pricing page, and it would be labeled accordingly in the disclosure. The decision to migrate a site should be based on your own workload, retention needs, restore process, and migration help quality, not on which provider pays a commission.

Common migration mistakes to avoid

The pattern of mistakes below shows up repeatedly in user reports and support tickets. Each is cheap to avoid once you see it.

• Migrating without testing the new site on a hosts file override. The hosts file test catches errors before the public cutover. Skipping it is the most common cause of "the site is broken after cutover" tickets.
• Forgetting to lower the TTL at least 24 hours before cutover. A high TTL means up to 24 hours of resolver caching on the old IP, even after the records change. Lowering the TTL in advance is the cheapest downtime reduction available.
• Canceling the old host before the new site is stable. The old host should stay live for at least 48 hours after cutover, ready to roll back if the new site fails.
• Assuming "free migration" covers all sites and database sizes. Free migration is usually one site with limits on plugin count, database size, and file count. Verify the limits before scheduling the migration.
• Forgetting to update email DNS records (SPF, DKIM, DMARC). When the email host changes, the SPF, DKIM, and DMARC records at the registrar must be updated or new email will land in spam.
• Skipping the backup retention check. The host's retention window may be shorter than expected. Verify the retention policy before you need a restore.
• Not testing the restore path during onboarding. A restore test on a staging site confirms the path works. Discovering it does not work during an outage is the most expensive way to learn the lesson.
• Forgetting that backups do not transfer between hosts. Download the most recent backup from the old host before canceling. The new host starts with a fresh backup schedule.
• Assuming Let's Encrypt is automatic. Most hosts issue Let's Encrypt automatically, but some require a manual click in the control panel to enable it.
• Ignoring cron jobs and scheduled tasks. Cron expressions and execution environments differ across hosts. Scheduled tasks that worked on the old host may not run on the new host without reconfiguration.

Buyer checklist: hosting migration and backup

1. Audit the source site: plugins, themes, custom code, scheduled tasks, cron jobs, mailbox count, and external integrations. Anything not in the inventory is at risk of being lost during migration.
2. Confirm the source site's database size and file count against the host's free migration limit. If the site exceeds the limit, plan for a paid migration or a self-serve path.
3. Lower the TTL on the domain at the registrar to 300 seconds at least 24 hours before cutover. This reduces the worst-case DNS propagation window.
4. Confirm the destination host's backup retention window, restore process, and self-service restore availability before the cutover. Plan for a third-party off-site backup if the host's retention is short.
5. Run a self-service restore test on a staging or test site before the cutover. Confirm the path works, the backup is intact, and the team knows the steps.
6. Transfer files and database using a migration plugin, manual SFTP + phpMyAdmin, or the host's paid migration service. Verify checksums and database integrity after the transfer.
7. Test the new site on a hosts file override (map the domain to the new IP locally) before changing public DNS. Catch errors before the cutover.
8. Update DNS records at the registrar: A records, AAAA records, MX records, SPF, DKIM, and DMARC. Verify email deliverability with a test send after cutover.
9. Cut over DNS during a low-traffic window and monitor 5xx errors and resolver behavior for 24 to 48 hours. Keep the old host live as a rollback target for at least 48 hours.
10. Only cancel the old host after the new site is stable, the last backup is downloaded, and the next billing cycle confirms no further charges. Screenshot the cancellation confirmation.

Use this hosting migration and backup checklist

Affiliate disclosure: PriceGap is an independent buyer-education site. This article contains no advertiser checkout links, does not claim a current sponsor relationship with any hosting provider, and does not quote fixed live prices, migration fees, retention windows, or restore charges. Migration policies, backup retention, restore processes, and DNS-related rules change frequently; verify current terms directly with the provider before scheduling a migration or relying on a restore.