How to Move a Website to a New Host Without Downtime

Moving a business website to a new host should be a controlled change, not a moment when the old server is switched off and everyone waits to see what breaks. The safest approach is to build and test the new copy first, preserve DNS and email settings, then move live traffic while both environments remain available.

This guide explains how to move a website to a new hosting provider while minimising downtime. It covers ordinary same-domain hosting migrations, WordPress sites, DNS, HTTPS, forms, email continuity, search visibility, rollback and the questions to ask a new provider before purchasing.

Important: no responsible provider can promise zero risk for every website. Custom applications, active shops, membership sites and old systems may need a tailored migration plan. The goal is verified continuity and a recoverable change.

Hosting migration versus domain transfer

These are separate operations:

• Hosting migration: copies the website or application to a new server.
• DNS change: directs visitors to the new hosting.
• Domain transfer: moves domain management between registrars.
• Email migration: moves mailboxes and mail flow to a new service.

You do not normally need to transfer the domain simply to change website hosting. Keeping these operations separate reduces the number of moving parts. If you also plan to transfer a .ie domain, follow our domain transfer checklist as a distinct project.

The safest migration sequence

1. Inventory the current website, DNS, email and integrations.
2. Take and verify independent backups.
3. Prepare the new hosting environment.
4. Copy the site and database.
5. Test privately without changing public DNS.
6. Prepare HTTPS, monitoring and rollback.
7. Reduce relevant DNS TTL values in advance.
8. Synchronise final changes and switch DNS.
9. Monitor both servers, forms, payments and email.
10. Retire the old host only after traffic has moved and recovery checks pass.

Google's official hosting-change guidance follows the same broad model: prepare and test the new infrastructure, update DNS, monitor traffic on old and new hosting, and shut down the old environment only when users and Googlebot are reaching the new one.

Phase 1: inventory everything the current site depends on

A website is rarely just a folder of pages. Before requesting a migration, record:

• domain and current nameservers;
• DNS records, including A, AAAA, CNAME, MX, TXT, CAA and verification records;
• website files and document root;
• databases, versions, users and prefixes;
• CMS, plugins, themes and custom code;
• runtime versions such as PHP, Node.js or database engines;
• scheduled tasks and background workers;
• forms, SMTP delivery and notification recipients;
• payment, booking, CRM, analytics and consent integrations;
• redirects, security headers and firewall rules;
• file storage, media processing and backups;
• email mailboxes, aliases, forwarding and authentication records;
• Search Console and analytics verification methods.

Ask the current developer and provider for documentation. If nobody knows how an integration works, investigate before the migration window rather than discovering it from a customer complaint.

Phase 2: take backups you can actually restore

Create a complete backup of files, databases and configuration. Keep a copy outside both hosting accounts. A provider snapshot is useful, but it is not your only recovery plan if the account itself becomes unavailable.

For WordPress, the official migration guidance specifically calls for backing up the WordPress directory, images, plugins, themes and database before moving servers. A database export without uploaded media is incomplete; files without the database omit posts, settings, users and many plugin records.

Record the backup time and test that archives open and database exports can be read. For a high-value shop or application, perform a restore rehearsal in a private environment.

Phase 3: confirm the new hosting fits the application

Before paying or copying data, verify:

• supported runtime and database versions;
• storage, memory, CPU and process limits;
• scheduled-task and background-worker support;
• HTTPS certificate provisioning;
• backup frequency, retention and restoration process;
• staging or private-preview options;
• logging and monitoring access;
• email sending restrictions;
• support hours and migration responsibility;
• renewal price and exit/export process.

Use our Irish small-business hosting checklist to compare the service beyond an introductory price. You can also review Hoster website hosting before deciding whether it fits the workload.

Phase 4: copy the website before changing DNS

Build the new environment while the old website continues serving customers. Copy files and databases, recreate environment variables and scheduled tasks, and configure the correct runtime.

Do not place production secrets in a source-code repository or send them through an ordinary support ticket. Transfer credentials through an approved secure method, rotate them when appropriate, and provide each supplier only the access required.

Dynamic websites need a content plan

A brochure site may be copied once. A shop, booking system, forum or membership site can change every minute. Decide how final orders, users, stock, uploads and submissions will be synchronised before DNS switches.

Options include a short maintenance window, a final database synchronisation, temporary read-only mode or application-specific replication. Never overwrite new customer transactions with an older database copy.

Phase 5: test the new site privately

Use a staging hostname, host-file override, private preview or provider testing mechanism so authorised reviewers can reach the new server without moving public visitors.

If a temporary hostname is publicly reachable, prevent it from being indexed. Google recommends a noindex rule for temporary test sites. Remove that rule before launch; accidentally carrying noindex into production can remove pages from search results.

Migration test checklist

• Homepage and every important landing page load.
• Navigation, search and internal links work.
• Images, documents, fonts and scripts return successfully.
• Contact, quote and newsletter forms reach monitored recipients.
• Login, password reset and account permissions work.
• Checkout, test payments and fulfilment work where applicable.
• Cookie consent and analytics behave correctly.
• Canonical tags, metadata, robots rules and sitemap are correct.
• Permanent redirects remain in place.
• Mobile, keyboard and major-browser checks pass.
• Logs contain no repeated application or permission errors.

Phase 6: protect business email

Changing website hosting should not silently replace email DNS. Export the complete DNS zone before editing anything. Preserve MX records and the TXT/CNAME records used for SPF, DKIM, DMARC and provider verification unless the mail service is intentionally changing.

If nameservers are moving, recreate and verify the entire working zone at the new DNS provider before changing delegation. Missing MX or authentication records can stop incoming mail or damage outbound deliverability even when the website works.

If email is also being migrated, treat it as a separate workstream with mailbox inventory, data copying, DNS cutover, inbound/outbound testing and access instructions. See our business email hosting guide.

Phase 7: prepare DNS for the switch

DNS resolvers cache answers for the record's Time to Live. Google recommends lowering the relevant TTL to a conservative low value in advance—its guidance suggests doing so at least a week before a hosting move—so older cached answers expire sooner during the switch.

Lowering TTL at the moment of migration does not erase records already cached under the old value. Plan ahead, and restore an appropriate TTL after the migration is stable.

Identify exactly which records change. If the nameservers and email provider remain the same, a website move may require only the web A, AAAA or CNAME records. Do not replace a complete zone merely because one web destination changed.

Phase 8: prepare HTTPS on the new host

The new server must present a valid certificate for every public hostname it will serve, such as both example.ie and www.example.ie. Test HTTP-to-HTTPS redirects and the chosen canonical hostname.

Do not disable HTTPS to make a migration easier. Mixed content, invalid chains or a missing hostname can create browser warnings and break forms, payments or embedded resources.

Phase 9: switch traffic during a controlled window

Choose a period of lower business activity when the responsible technical and business contacts are available. Take a final backup and synchronise recent dynamic data immediately before the switch.

Update only the reviewed DNS records. Record the previous values and exact change time. This makes rollback possible without guessing.

After the change, test from more than one network and device. Your own computer may still use a cached answer while another network already reaches the new server.

Phase 10: monitor the migration

Customer experience

• Check key pages, forms, login and checkout repeatedly.
• Watch customer-support channels for reports.
• Confirm transactional emails are delivered.
• Measure response times and error rates.

Old and new server traffic

Google advises monitoring logs on both environments. Traffic should decline on the old host and rise on the new host as caches update. Keep the old service available until its traffic has ended and the new environment is stable.

Search visibility

Keep Search Console verification working, inspect important URLs, monitor crawl errors and submit the existing sitemap if required. Google notes that a temporary change in crawl rate can occur after a hosting move. If the URLs and content remain the same and the new server works correctly, avoid unnecessary URL changes during the same migration.

What if the domain name or URLs also change?

That is a site move with URL changes, not just a hosting change. Create a one-to-one mapping from old URLs to their closest new equivalents, use server-side permanent redirects, update canonical URLs and internal links, publish the new sitemap and keep redirects operating long enough for users and search engines.

Google warns that ranking fluctuations can occur while changed URLs are recrawled and reindexed. Combining a host change, domain change, redesign, CMS replacement and content rewrite in one uncontrolled launch makes diagnosis much harder. Separate changes where practical.

A rollback plan that can actually work

Before switching DNS, decide:

• which failures require rollback;
• who has authority to make the decision;
• the old DNS values and server state;
• how new transactions will be preserved;
• how users will be informed;
• how the failed migration will be investigated before retrying.

Rolling DNS back without handling orders or records created on the new system can lose data. Dynamic applications need a data-reconciliation plan, not merely the old IP address.

When can the old hosting be cancelled?

Not immediately after the first successful page load. Keep it until:

• DNS caches have moved to the new destination;
• old-server traffic has reached an acceptable endpoint;
• forms, email, payments and scheduled jobs are verified;
• backups and restore procedures exist on the new platform;
• the rollback window has closed;
• required files, logs and data have been retained lawfully.

Google's hosting-migration guidance recommends shutting down the old infrastructure only after you are confident that users and Googlebot receive content from the new host and nobody is using the old environment.

WordPress migration notes

A same-domain WordPress move commonly requires the files, uploads and database, plus correct database credentials and runtime configuration. Review PHP and database compatibility, caching, cron, mail delivery, file permissions and plugin licences.

Search-and-replace operations can damage serialised data if performed incorrectly. If the public URL is unchanged, avoid unnecessary URL replacement. Use a tested WordPress-aware process and keep the original backup untouched.

Security improvements to make during the move

A migration is a useful time to remove abandoned accounts and unsupported software, but avoid an uncontrolled redesign. At minimum:

• rotate exposed or shared credentials;
• enable multi-factor authentication for hosting, DNS and domain accounts;
• give suppliers individual least-privilege access;
• update supported software after compatibility testing;
• protect backups separately;
• configure logging, monitoring and security updates;
• document ownership and recovery contacts.

Ireland's National Cyber Security Centre recommends MFA because it adds protection against password-related attacks such as credential stuffing.

Questions to ask a new hosting provider

1. Is migration included, assisted or entirely my responsibility?
2. Which files, databases and mailboxes will be moved?
3. How will the new copy be tested before DNS changes?
4. Who changes DNS, and which records will change?
5. How are dynamic orders or submissions synchronised?
6. Will HTTPS be ready before cutover?
7. What monitoring happens during and after the switch?
8. What is the rollback procedure?
9. What backups and restores are included after migration?
10. What are the limits and renewal price?
11. How can I export the site later?

Frequently asked questions

Will changing host damage SEO?

A properly prepared same-URL hosting move should preserve the public site structure. Problems arise when the new server is slow, unavailable, blocked from crawling, missing content or returning different statuses. Monitor Search Console and server logs during the change.

Do I need to transfer my domain?

No. Website hosting can change by updating DNS while the domain remains with its current registrar.

How long does DNS propagation take?

There is no single universal duration. Resolvers cache records according to TTL and their own behaviour. Lower relevant TTL values in advance, keep both hosts working during the transition and monitor multiple networks.

Will my email stop when I change hosting?

It should not if the existing email DNS and service remain intact. Email can fail when nameservers are changed without recreating MX and authentication records, so export and verify the complete zone first.

Can a provider guarantee zero downtime?

Careful parallel operation can make downtime unnoticeable for many sites, but custom and dynamic systems carry real risk. Ask for the test, synchronisation, monitoring and rollback plan rather than relying on an absolute promise.

Plan the move before buying

Start by documenting the site and asking the prospective provider how it will be copied, tested and switched. Review Hoster hosting options and use the contact form to describe your CMS, traffic, email arrangement and required migration window. A useful pre-sales answer should identify dependencies and responsibility before any DNS change.

Official sources

• Google Search Central: changing web hosting
• Google Search Central: site moves with URL changes
• WordPress: moving to a new server
• Ireland NCSC: multi-factor authentication for SMEs