Crypto-only payments. Pay with USDT or USDC.
Moving a Website Without Breaking Business Email
The Hightide Hosting Editorial Team · 2026-10-03
A website move should not quietly become a mailbox move. Treat the two as separate projects, even when the old control panel presents them together.
Start with a record of what is live
Before changing a host, list the website destinations, mail-routing records, sending services and domain-control accounts. A small company's quotations may depend on mailboxes hosted somewhere different from its website. Identify who owns each service and save the current DNS values with a timestamp. Keep a reachable administrative contact outside the domain being changed so a mistake does not also remove the recovery route.
Include subdomains, external forms, scheduled jobs and integrations in the inventory. Ask which website forms send through an application mail service and which staff mailboxes receive their messages. These are different paths. Do not assume that recreating a homepage recreates the enquiry workflow. Mark the expected owner and test for each path before choosing a migration window.
Copy and validate the application before changing DNS
Back up the relevant files, database and configuration, then prove that the copy can be restored on an isolated destination. Keep private data protected and avoid indexing a staging copy of a production catalogue. Check the runtime, dependencies, storage permissions and environment settings actually required by the application. A successful upload alone is not proof that a database-backed page or background job works.
Exercise the important pages using a controlled preview method rather than redirecting customers into an unfinished deployment. Compare product URLs, redirects and downloadable files with the existing site. For a dynamic store or portal, decide how new writes will be handled during the final copy; an old backup can miss orders or enquiries received after it was taken. Document the final synchronisation plan instead of assuming all data is static.
Keep mail records separate from website records
Preserve the active mailbox provider's MX records unless you are deliberately migrating mail as well. Retain the provider's real SPF, DKIM and DMARC configuration, including any sending services the business uses. Do not paste an invented authentication record or replace a verified selector simply because a new host presents a generic example. Record the authoritative source of each value so the next maintainer knows why it exists.
Plan web A, AAAA or CNAME changes against the actual destination supplied by the new provider. Review any incompatible or obsolete address records rather than leaving a second path to the old host by accident. If nameservers must change, transfer the complete zone deliberately and compare the new authoritative answers. Changing delegation is broader than changing the address of one website and needs its own acceptance checks.
Make the cutover observable and reversible
Review record TTLs ahead of the window and account for values that existing caches may already hold. A last-minute TTL change cannot erase responses that were cached earlier. Keep the old service available for the agreed rollback period, and write down which record or application setting returns customers to it. Avoid an automatic deletion of the old host before you have evidence that the new one handles the important traffic.
After the switch, inspect authoritative DNS and the customer-visible website from more than one connection. Check the secure connection, redirects, forms and any background tasks against the acceptance list. There is no honest universal zero-downtime promise: application state, existing caches and provider completion all matter. Treat a problem as a reason to use the documented rollback rather than improvising several simultaneous changes.
Test business mail in both directions
Send a non-sensitive test message to a staff mailbox from an independent account, then send a reply outward. Check the correct recipient, delivery timing and authentication results in the headers. Repeat the application's enquiry path separately because it may use another sender. A successful incoming message does not prove that a form can send, and a successful form does not prove that a staff mailbox still receives supplier replies.
Keep the final record of DNS values, completed provider orders, test results and the rollback deadline with the business. Hightide website hosting and business email are separate catalog choices, and paid orders require review before activation. Confirm the new service is actually ready before scheduling the move. Once the acceptance list is complete, retire the old service deliberately and retain the recovery records according to the business's data policy.
Must I move mailboxes when moving a website?
No. Website hosting and mailbox hosting can be separate. Preserve the active mail provider's records unless mail migration is also planned.
Can I guarantee zero interruption from a DNS change?
No. Existing caches, application state and provider readiness affect the cutover. Use testing, monitoring and a documented rollback.
What should be confirmed before changing the live website address?
Confirm service activation, a tested application and data copy, the actual destination records, business-mail continuity and a usable recovery path.