WEBSITE & EMAIL TRANSFER GUIDE • OCTOBER 12, 2026
Hosting.com Migration: plan the move before changing DNS
Move your website with a clear backup, email plan and acceptance checklist.
Compare Hosting.com plans for your moveSee the migration checklistAffiliate disclosure: We may earn a commission from qualifying purchases through affiliate links, at no additional cost to you. Recommendations depend on fit. This is a documentation-based guide, not a hands-on migration benchmark.
Quick answer: can you move without losing email?
Plan the website and email separately. Identify where mail is hosted, preserve the correct DNS records, and agree how existing messages will be copied if mailboxes are moving. Preview the website and test fresh email delivery before cancelling the old account. No guide can guarantee zero disruption for every setup.
Inventory websites, mailboxes and DNS; keep an independent backup.
Confirm the destination, migration scope and any fee in writing.
Approve the preview and agree how recent data will be synchronized.
Verify the live site and real inbound and outbound email.
Hosting.com migration: what the service actually covers
Hosting.com’s current migration page describes a managed move with a preview before the switch. It advertises website and mailbox transfers and says external Google Workspace or Microsoft 365 mail can stay where it is. Its global billing policy still allows charges for complex non-cPanel work. Because those descriptions differ, get your exact scope and any fee confirmed in writing before ordering.
That confirmation should identify the source platform, destination product, websites, mailboxes and timing. A general promise cannot establish compatibility with every custom application. This article provides a planning and checking workflow. It is not a report of a migration we performed on your account, and it does not guarantee uninterrupted service.
Start with the decision that matters: are you moving only the website, the website and email, or an entire hosting account? Those jobs can require different access and testing. Make a short inventory before asking for help. It gives the migration team a clearer picture and reduces the chance of discovering an important dependency after the transfer.
Sources: official migration overview and global billing policy. Confirm the applicable product and region.
Website migration, DNS change and domain transfer are different
Your website consists of files, a database where applicable, and application settings. A migration copies that working setup to a new environment. DNS tells visitors and mail systems where to connect. Domain registration is the ownership and renewal service for the name itself. You can move a website while leaving the domain registered with its current registrar.
Decide who will manage DNS after the move. If you keep an existing DNS provider, ask which website records must change. If you move nameservers, copy the complete zone into the destination first. A nameserver change affects the whole DNS zone, so overlooked mail or verification records can cause problems beyond the website.
For a simple example, imagine a business whose domain is at one registrar, website at another provider, and mailboxes at Microsoft 365. Moving the website does not require moving those mailboxes. Preserve their mail records and validate delivery separately. This is a planning example, not a description of your own account.
Reference: site migration versus domain transfer.
Step 1: choose the destination before requesting the move
Match the destination to the applications you actually run. Record website count, storage, database size, traffic pattern and mailbox requirements. Check whether your account also runs a custom script, development project or scheduled process. A WordPress-focused product should not be selected on the assumption that it supports everything a general hosting account does.
Compare the complete opening payment and renewal bill. Migration assistance can be valuable, but it does not make an unsuitable plan a good purchase. Use our Hosting.com shared versus managed WordPress guide to understand that product choice, and our renewal price guide to check the longer-term budget.
Before paying, ask whether your source platform is supported and whether email needs a separate service. Request a realistic timetable for your workload. A small static website and an active store need different cutover planning. Choose the plan because it meets your requirements after migration, not merely because the transfer is advertised as included.
Step 2: inventory the services that must keep working
Write down every live domain, subdomain and important application. For each website, identify its database, uploads, redirects and scheduled jobs. Include contact forms, newsletter connections, payment integrations and analytics. This list becomes your acceptance checklist when the new copy is ready.
Make a separate mail inventory. Record mailbox addresses, aliases, forwarders and the location of existing messages. A working inbox on a phone does not tell you where mail is hosted. Check the current provider and whether the app uses IMAP or stores some messages locally. Preserve a local archive if it contains mail that never reached the server.
Assign an owner for each item. Someone should approve the website, someone should check email, and someone should authorize the DNS switch. For a solo business, the same person can handle all three. For an agency, clear responsibility prevents the migration team from receiving conflicting instructions from several collaborators.
Choose the right destination first
Confirm your website and mailbox requirements with the migration team, then compare the complete opening and renewal costs.
Review Hosting.com optionsMigration eligibility and scope require confirmation. We do not promise a special discount.
Step 3: keep an independent backup before the transfer
Export website files and the relevant databases, and store the backup separately from the old hosting account. Confirm that it includes the media library and current application settings. A database dump alone is not a full copy of a WordPress site. A WordPress content export is also different from a complete installation backup.
Check that the archive opens and that its size looks plausible. If the site is important, test a restoration in a separate environment. Keep the backup date with the file. A copy taken before a busy sales period may omit later orders or uploads even if the archive itself is intact.
Back up mail separately when it is moving. Ask how messages and folders will be copied and whether a final synchronization is included. Keep old service access while the work is underway. A migration becomes harder to recover when the source account is cancelled before the destination has been verified.
Reference: cPanel migration inclusions and exclusions.
Step 4: request migration through the official account
Use Hosting.com’s official customer area or its migration team’s supported channel. Describe the source control panel, destination product, site count, mail setup and preferred window. Ask how to provide the necessary access securely. Do not send passwords through a public comment or place a backup containing private data on an unrestricted download link.
Use an individual or temporary migration account when the source platform supports the required permissions. Keep access available until the provider confirms completion, then remove temporary access or rotate shared credentials as appropriate. The migration team should tell you what it needs; do not guess that a WordPress administrator login can export every server or mailbox setting.
Request written answers to four questions: what will move, what will remain, what may cost extra, and what you must test. Include a question about host-specific settings. A clear ticket is easier to review than an informal chat promise, particularly if another team member needs to finish the project.
Step 5: understand cPanel and custom-platform limitations
Hosting.com’s cPanel documentation lists website content, databases, mail settings, cron jobs and DNS among the items handled within a cPanel account migration. It also excludes configurations made outside cPanel, such as root-level server packages, and says two-factor authentication requires setup again. Treat that list as product-specific documentation, not a universal promise for every destination.
If your source does not use cPanel, give the team a precise description. A custom application may depend on a runtime version, server package or background worker that is not part of a standard website backup. Files can copy successfully while the application still fails to run. Ask who will recreate those dependencies.
Do not remove a service simply because it is absent from the migrated control panel. It may be managed elsewhere. Compare your original inventory with the destination and mark each item as moved, intentionally retained, or needing work. That reconciliation gives you a practical definition of completion.
Step 6: preserve business email and old messages
Choose whether to keep the current email provider or migrate mailboxes. Keeping an independent mail service often means the website move only needs careful preservation of its DNS records. When mail is moving, ask whether old messages, folders, aliases and forwarders are included, and how new messages arriving during the move will be synchronized.
Record the destination mailbox settings before updating devices. Test webmail as well as the phone or desktop application. An app can appear healthy while reading cached messages from the old server. Send a fresh message from an unrelated mailbox, reply to it, and verify that both messages arrive at the intended destination.
Website-generated email is a separate test. Submit the contact form, request a password reset and trigger a test order notification where relevant. Confirm the configured sender and outgoing mail service. A working business inbox does not prove that WordPress notifications use the right delivery path.
Step 7: check DNS without breaking mail
Save the existing DNS records and note which provider is authoritative. Ask the migration team for the exact website destination, rather than copying a server address from an unrelated example. If you use a proxy or CDN, tell the team so that it can account for certificates, caching and origin access.
Preserve the mail records appropriate to your email provider. MX records route incoming mail; SPF, DKIM and DMARC support authentication and policy. Do not paste generic values into your zone. Use the values supplied for the services you actually operate, and check that old and new settings do not create contradictory records.
When moving nameservers, recreate verification records and subdomains as well as the main website. Save a rollback copy of the old configuration. Avoid combining the hosting cutover with unrelated DNS cleanup. Fewer simultaneous changes make it easier to identify why a website or mailbox behaves differently.
Step 8: inspect the preview before approving the switch
Use the temporary preview or testing method supplied by the migration team. Check your homepage, several articles, category pages and important landing pages. Compare images, menus, downloads and redirects. Open an administrative page and verify that recent content is present.
Test functions rather than appearance alone. Send a form submission and confirm its destination. Check search, login and any membership flow. For a store, use the supported test payment method instead of making an accidental real purchase. Ask the team which features require testing again after the public domain points to the new server.
Verify HTTPS and mixed-content behavior. A preview address may behave differently from the final domain, so record any remaining certificate or integration tasks. Approve the cutover only when the checklist is clear enough to distinguish an acceptable pending step from a broken essential function.
Step 9: coordinate an active store or membership site
A site receiving orders, registrations or comments continues to change after the first copy is made. Agree on how those new records will reach the destination. A short editing or transaction pause may be appropriate for some projects. Ask the migration team to explain the final synchronization process before scheduling the switch.
Do not overwrite the live database casually with an older copy. That can remove records created since the backup. Identify which environment is authoritative during the cutover and who is allowed to accept new transactions. Make the plan understandable to the person answering customer messages.
After the switch, check recent orders, customer accounts, stock and notification messages. Confirm scheduled jobs and integrations. Keep a written log of the final sync and acceptance checks. If there is a discrepancy, the log helps the team determine which data needs attention without guessing.
Step 10: verify the live result before cancelling old hosting
Once DNS has been changed, confirm that the intended environment serves the public site. Test from more than one network where practical, and have the migration team verify the destination. Cached content can make an old page appear current. Compare a harmless recent update or another agreed indicator instead of relying only on the homepage design.
Repeat the critical website and email tests. Check the certificate, forms, login and important redirects. Verify inbound and outbound mail, including website notifications. Review analytics and search-console access so you can monitor errors after the move. Hosting changes do not require new article URLs unless you deliberately redesign the address structure.
Keep the old account until testing and any required synchronization are complete. Then follow its documented cancellation process and retain confirmation. Separate hosting cancellation from domain and email services you are retaining. Do not assume that removing a payment method is the same as closing the correct subscription.
Protect search visibility during a hosting move
If the domain and URLs remain the same, preserve the existing site structure wherever possible. Keep internal links, canonical URLs, redirects and sitemap settings consistent. Check that production pages are not marked noindex because a test environment was copied with restrictive settings.
Inspect the robots file and representative page metadata after cutover. Make sure old HTTP addresses lead to the intended HTTPS version. If URLs are changing as part of a separate redesign, prepare redirect mappings before launch. Moving hosting and changing every address at once creates more variables to troubleshoot.
Monitor crawl errors and important pages after the switch. A hosting move does not guarantee better rankings, and a clean migration does not remove competition or content problems. Its immediate goal is to preserve availability, access and functionality while you move to a setup that better fits your needs.
What to do if something is missing
Contact the migration team with a specific example: the affected URL, mailbox or function, the expected result and what happened instead. Mention when you first noticed the issue. Share private account details only through the approved support channel. A precise report is more useful than saying the entire migration failed.
A missing image suggests a different investigation from a failed checkout or undelivered email. Compare the destination with your inventory and backup. Do not repeat a complete import immediately if the new site has already received orders or messages. Ask which repair will preserve new data.
If rollback is necessary, coordinate it with the team. Returning traffic to the old environment can also create split data if both sites accept changes. Agree on the authoritative copy and the synchronization required. Keep the decision log until the project is accepted and the recovery copies can be retired.
Your Hosting.com migration acceptance checklist
| Area | Check | Acceptance evidence |
|---|---|---|
| Website | Content, media, menus and login | Representative pages and functions work |
| Live data | Orders, members and recent edits | Final sync agreed and verified |
| Messages, aliases and delivery | Fresh inbound and outbound tests pass | |
| DNS | Website and retained service records | Intended destinations confirmed |
| HTTPS | Certificate and redirects | Public pages open securely |
| Recovery | Independent backup and rollback | Copy retained and responsibilities clear |
Frequently asked questions
Is Hosting.com migration free?
The public migration page advertises included moves, while the global billing policy allows charges for some non-cPanel work. Ask the team to confirm the scope and fee for your setup before buying.
Do I need to transfer my domain registration?
A website migration and domain transfer are separate tasks. You can keep your registrar and change the necessary DNS records for the website.
Can I keep Google Workspace or Microsoft 365?
Yes, plan to retain that provider and preserve its mail and authentication records. Confirm the DNS scope with the migration team and test fresh delivery.
Will an old hosting cancellation remove my mail?
It can affect mail hosted within that account. Verify mailbox migration or an independent mail arrangement before cancelling.
How long should I keep the old hosting?
Keep it until the destination, final synchronization and critical website and email tests are accepted. Agree the timeline with the team rather than using a fixed guess.
Will migration improve rankings automatically?
No. Preserve URLs, redirects, canonical settings and crawl access, then monitor the live site. Hosting alone does not guarantee rankings.
Ready to plan your move?
Check the product that fits your site, ask for a written migration scope, and keep email continuity in the plan.
Explore Hosting.com for your websiteRead our Hosting.com reviewRelated decision guides
Research method: Public migration, cPanel and billing documentation reviewed October 12, 2026. We did not access a customer migration ticket or run a provider benchmark. Product terms and regional policies can differ. Written confirmation for your account controls the work.
