How to Use a Free Migration Service from Your Host

A smooth migration saves hours and protects your traffic.

Free migration services from reputable hosting providers move your website, database, files, and often email from an old provider to a new one with minimal downtime. The service is designed to reduce risk and shorten the cutover window so customers do not notice the switch. This guide shows you exactly how to prepare, request, and validate a migration, along with the decisions that keep the process safe and predictable.

What a Free Host Migration Actually Includes

A “free migration” usually covers a copy of your site from the source environment into the new host’s environment. The scope varies by provider, but most services include:

Web files and media copied from your old server or platform
Databases exported and imported so your application can boot normally
Basic configuration such as web server and PHP settings that match the target platform
DNS change guidance or a cutover checklist so you can flip traffic cleanly

Some providers also help with:

Email routing if the domain’s mailboxes run on the host’s platform
SSL certificate issuance on the new host once DNS points at it
Prelaunch staging so you can review the migrated site privately before cutover

A free service rarely includes heavy refactoring, theme rewrites, custom server modules, or performance tuning. Treat it as a safe transport, not a redesign.

Should You Use the Free Service or Migrate Yourself

Choose the path that fits your risk tolerance and timeline.

Use the free service if you want less hands-on work, predictable steps, and support that has done this hundreds of times. This is the right default for most owners, agencies on a deadline, and non-technical teams.
Migrate yourself if you require full control, are comfortable with database dumps, file synchronization, and search and replace tasks, or if your stack includes custom services the host does not support.
Hire a specialist when the site carries significant revenue, has a complex checkout or membership flow, or has custom code with many environment assumptions. The free service can still handle the basic copy while a specialist reviews edge cases.

If you are undecided, request the free migration and ask the provider to confirm scope before they begin. A clear scope avoids surprises.

Pre-Migration Checklist

Good preparation removes most migration stress. Use this checklist before you submit the request.

Confirm the destination plan and versions

Match your application’s requirements on the new host. Verify supported PHP version, database engine and version, storage limits, and any platform restrictions. If your site uses a specific PHP extension or a rewrite rule, confirm availability.

Collect credentials and artifacts

You will need:

Source host control panel access
SFTP or SSH credentials
Database credentials and the database name
Admin login to your CMS
A list of active domains and subdomains
Third party services that expect your origin IP, such as firewalls or allowlists

Store this in a secure note. You will share only the pieces the host requests.

Lower DNS TTLs ahead of time

Lower the time to live to 300 or 600 seconds 24 to 72 hours before cutover. That leads resolvers to refresh quickly when you switch records. Remember to raise TTLs later for stability.

Audit your email setup

List the MX records and any TXT records for SPF, DKIM, and DMARC. If a third party handles mail, you will keep those as is. If your current host provides mailboxes and your new host will too, plan where each mailbox will live after cutover and export any local mail that is not in IMAP.

Freeze content during the final copy

Dynamic sites can drift between the first copy and final cutover. Plan a short content freeze so you do not lose late edits, orders, or comments. For stores, schedule a brief maintenance window.

Back up the source

Even with a free migration, take your own backups. Export the database and a copy of your media library or storage bucket. Independent backups reduce recovery time if anything goes wrong.

Step-by-Step: Using Your Host’s Free Migration

This is a practical sequence you can reuse, regardless of your stack.

1. Submit the migration request

Open a migration ticket in the new host’s portal. Provide the domain, the source provider, the CMS or framework, and any special notes such as custom directories or cron jobs. Ask for a target date range and confirm whether the host will schedule the final DNS flip or provide instructions for you to do it.

2. Provide secure access

Hosts typically accept either temporary credentials or a restricted user. Prefer a temporary user with SFTP and database access limited to the site being moved. If you must share a control panel login, change the password right after the host confirms the copy is complete.

3. Identify the canonical hostname

Decide whether the canonical site will live at the root domain or at a subdomain such as www. Set one as the canonical and redirect the other to it. The migration team needs this decision to configure redirects and certificates correctly.

4. Let the host copy files and data

Behind the scenes, teams use standard tools:

File copy via SFTP or rsync for efficiency
Database export with mysqldump or platform tools, then import on the new host
Search and replace of absolute URLs in CMSs that store full paths in the database
Platform web server configuration aligned with your current rewrite rules

Do not change the source during this phase. Changes increase the chance of a mismatch.

5. Review the migrated site on a private URL

Your host should give you a temporary domain, a staging URL, or instructions to edit your local hosts file so you can reach the new environment without public DNS changes. Test the critical paths:

Homepage, navigation, search, and sitemap
Login, checkout, forms, and any gating or membership flows
Media downloads and streaming
Admin tasks like posting content and updating menus

Record issues with exact URLs and steps to reproduce. Clear, concise notes speed fixes.

6. Prepare for cutover

When staging looks correct, confirm the cutover window. Keep TTLs low. If your site accepts orders, payments, or submissions, schedule a short maintenance window during cutover and post a friendly notice.

7. Flip DNS and issue certificates

Point the domain to the new host. If the new platform issues TLS certificates automatically, watch for the certificate to become active and then enforce HTTPS. If you manage certificates yourself, request and install them ahead of public traffic if your host supports prevalidation.

8. Run post-cutover checks

Test the same critical paths on production. Verify that analytics and pixels fire once, that caches warm quickly, and that redirects behave as expected. Watch error logs for the first few hours. If you see a severe issue, roll back DNS to the old origin while you investigate.

9. Raise TTLs and close the change

Increase TTLs to a steady value such as 3600 or 14400 seconds to reduce churn. Document the final state and store copies of your pre-cutover and post-cutover DNS zones.

Special Cases and How to Handle Them

WordPress

Ask whether the host uses a built in search and replace on URLs and serialized data. Confirm scheduled tasks are running on the target with either core cron or the host’s task runner. If you rely on object caching, check that the same mechanism exists on the new platform.

WooCommerce and other stores

Plan a quiet hour for the final sync and cutover. If you cannot freeze orders, use a short maintenance mode and queue orders temporarily. After cutover, verify payment gateway webhooks, tax calculations, and shipping integrations.

Headless or Jamstack sites

If the site builds statically, the migration may be a repository mirror or a build pipeline change rather than a direct file copy. Point your DNS at the new edge platform and confirm build hooks and environment variables. Test previews for draft content.

Multisite networks

Confirm network mapping, wildcard certificates, and domain mapping settings. Inventory every mapped domain and test each on staging before cutover. Multisite adds complexity, so give yourself extra runway.

Email

If your mail lives with an external provider such as Google Workspace or Microsoft 365, do not change MX records. If you move mail hosting, communicate the exact time of cutover to users so they can close mail clients during the switch. Update SPF, DKIM, and DMARC to match the new sender.

DNS Strategy for a No-Downtime Cutover

A careful DNS plan keeps your site reachable throughout the switch.

Lower TTLs a couple of days prior so caches refresh fast.
Use CNAMEs for hostnames that point to managed targets. CNAMEs can simplify future changes. At the root domain where a CNAME is not allowed, use an ALIAS record if your DNS provider supports it.
Change one record at a time and verify. Start with a less critical subdomain if possible.
Monitor from multiple networks. A record that looks updated in your office may still be cached elsewhere.
Keep the old origin online for a few hours. Stragglers with stale DNS will still reach it. If the content is dynamic, consider a read only banner or a maintenance page to prevent new writes during the tail of propagation.

Security and Compliance Considerations

Your new provider will ask for access. Share it safely.

Principle of least privilege. Provide only the exact access needed for the copy. Create temporary users and remove them after the migration.
Mask sensitive data on staging databases if stakeholders outside your company will view prelaunch content.
Remove old access. Disable lingering SFTP and database credentials on the source after you complete the migration.
Review certificates and CAA policy. If you restrict certificate authorities with CAA, add the new host’s CA before requesting a certificate.
Confirm backups on the new platform and run a test restore. A backup you have not restored is just a theory.

If your business has compliance requirements, ask the host for data processing agreements, region pinning options, and retention policies.

Performance Tuning After the Move

A migration is a chance to remove old bloat and align with your host’s caching model.

Trim plugins and modules you no longer need. Duplicated functions waste memory and increase maintenance.
Resize images to match container widths and compress media before upload.
Defer non-critical scripts and avoid redundant analytics tags.
Warm edge caches by prefetching popular pages, then watch times to first byte and largest contentful paint.
Enable HTTP/2 or HTTP/3 if your platform supports it. These protocols improve multiplexing and perceived speed.

Record a short baseline after launch so you can catch regressions early.

Communication Templates You Can Copy

Clear communication keeps stakeholders aligned and calm.

Migration announcement to your team

Subject: Migration window for example.com
We will move example.com to our new host on Thursday between 6:00 and 7:00 a.m. Central. A short content freeze starts at 5:30 a.m. Please avoid publishing and site edits during this window. We expect no downtime. If you see issues after 7:00 a.m., post details in the #site channel with a URL and screenshot.

Client approval note after staging review

Thanks for reviewing the staging copy at the preview link. We fixed the two CSS issues on the pricing table and verified checkout. If you approve, reply with “Approved to deploy” and we will schedule the cutover for tomorrow at 7:00 a.m. Central. We will monitor for 60 minutes after launch.

Post-launch confirmation

Cutover complete at 7:13 a.m. Central. SSL issued, redirects validated, forms tested, and analytics confirmed. DNS TTLs raised to 3600. We will continue to watch logs until noon.

Common Pitfalls and How to Avoid Them

Forgetting email
Teams often focus on web only. Audit MX and TXT records up front so you do not interrupt mail flow.

Mixing CNAME with other records at the same name
DNS does not allow it. Choose one. At the apex, avoid CNAME and use ALIAS if available.

Not lowering TTLs ahead of time
If TTLs are long, you cannot speed up propagation at the last minute. Lower them early.

Missing absolute URLs in the database
Some CMSs store full domain paths. A migration team should search and replace those safely so links do not point back to the old host.

Edge and origin TLS mismatch
If a CDN or reverse proxy sits in front, ensure TLS is valid at both the edge and the origin. Mixed settings cause redirect loops or security warnings.

Assuming the host will rewrite custom code
A free migration is not a development contract. If your app needs refactoring, plan that separately.

What Success Looks Like

A good migration feels uneventful. Your visitors keep browsing. Your team receives a short confirmation that everything works. Pages load at least as quickly as before, and in many cases faster because the new host layers stronger caching and updated runtimes. You gain a cleaner stack, fresh backups, and confidence that you can change platforms without chaos next time.

Decision Matrix: When to Switch Hosts

Use this quick framework to decide if a move is worth it and whether the free service is enough.

Performance. If you are frequently CPU or I/O bound and cannot tune further, a new platform may help.
Reliability. Repeated outages or slow support responses justify a move.
Security posture. If your current host lags on patches or lacks two factor authentication and activity logs, consider leaving.
Workflow fit. If you need staging, backups, and clean deploys and your current host struggles here, a managed platform will save time.
Cost versus time. If your team spends hours fighting the platform, the premium for a reliable host often pays for itself quickly.

If at least two of these push you toward change, request a free migration assessment from the new host and see how much they can automate for you.

Final Takeaway

A free migration service is a practical way to change hosts without burning a week of engineering time. Prepare with a checklist, give the provider precise access, review on staging, schedule a short cutover, and validate the critical paths before you raise TTLs. Treat the migration as a controlled project rather than an emergency. Do that, and you will switch platforms with confidence and keep your audience unaware that anything changed behind the scenes.

Frequently Asked Questions

How long does a free migration usually take

Simple sites copy in hours. The full process can take one to three days when you include staging review, scheduling, and DNS cutover. Complex stores or networks need more time.

Will there be downtime during DNS changes

With lowered TTLs and a good plan, visitors rarely see downtime. Keep the old origin online for a few hours after the switch to serve users with cached DNS and you will be fine.

Can the host migrate my email too

Often yes, but policies vary. If your mail is with a third party like Google Workspace, you keep MX as is. If you move mail hosting, coordinate mailbox creation and IMAP sync to avoid message loss.

What if I need to roll back

Keep the old site online and your old DNS values handy. If a serious issue appears, point the records back to the old origin, investigate, and reschedule. This is why low TTLs and backups matter.

Do I need to change my SSL certificate

If the new host issues certificates automatically, you will receive a new one after DNS points at the platform. If you manage certificates yourself, request a certificate for the target hostnames and install it before enforcing HTTPS.

How do I test the migrated site before going live

Your host will give you a preview link or instructions to edit your local hosts file so your computer resolves the domain to the new server while the public still sees the old one. Use that to run through your checklist.

References

WordPress.org Documentation: Moving WordPress
cPanel & WHM Docs: Transfer Tool and Account Moves
MySQL Reference Manual: mysqldump program for logical backups
Cloudflare Support: Time to Live (TTL) explained
rsync Documentation: Efficient file transfer and synchronization
Let’s Encrypt and Certbot Docs: Certificate management and deployment