Website hosting migration: when to move, what to assess and how to reduce downtime risk

A hosting migration can be the right response to persistent performance problems, unreliable support, unsuitable security controls or a platform that no longer matches the website’s operational importance.

It can also be an expensive way to avoid diagnosing the real issue.

A slow website may be constrained by application code, oversized media, database queries, third-party scripts or cache configuration. An outage may originate in DNS, a payment service or an integration rather than the server. Moving the same application and configuration to a different environment can move the problem with it.

The first decision is therefore not which host to choose. It is whether changing infrastructure is justified by evidence and requirements.

Choose infrastructure against the website’s actual requirements, then manage the migration as a controlled release with tested recovery options.

That approach does not make a migration risk-free. It makes the risks visible, assigns responsibility and creates a credible way to proceed, pause or roll back.

The short answer

A hosting move is credible when all five conditions are met:

• The current problem or constraint has been evidenced rather than assumed.
• The destination is demonstrably better suited to the workload, risk and support requirements.
• The team understands the website, data, integrations, DNS and third-party dependencies that must move or continue working.
• A verified backup, restore path, test environment, cutover runbook and rollback decision are ready.
• Named people can monitor the old and new environments until the change is proven stable.

If one of these conditions is missing, the next step may be diagnosis or preparation rather than migration.

When moving host is justified

There is rarely one universal signal. A move normally becomes credible when several persistent constraints affect customers, operations or risk.

The current environment cannot meet evidenced demand

Resource saturation, unacceptable response times under realistic load or recurring capacity constraints can justify change. The evidence should come from monitoring, server or application logs, synthetic tests and representative user journeys, not one speed-test score.

Performance is also end-to-end. A faster server cannot remove the effect of a heavy front end, slow external script or inefficient database query. Establish a baseline for server response, key pages, transaction paths, error rates and resource use before deciding what the new environment must improve.

Reliability or recovery capability is unsuitable

Repeated outages, poor incident communication, inaccessible logs, inadequate backup options or untested restoration may indicate an operational mismatch. Business criticality should determine the required availability, backup frequency, recovery time and recovery point. Those requirements need a commercial and technical owner; words such as “enterprise” or “managed” do not define them.

Security, privacy or governance requirements have changed

An organisation may need clearer access control, logging, geographic or contractual treatment of data, stronger isolation or a provider whose shared-responsibility documentation is suitable for its risk. A hosting move alone does not create compliance. The application, user accounts, data handling, configuration and operational procedures remain part of the picture.

The Australian Cyber Security Centre’s cloud shared-responsibility guidance emphasises that the provider and customer share security responsibility, and that the exact division depends on the service. It also recommends clarifying backups, restoration, alerts, logs and incident support rather than assuming the provider covers them.

The technology or support model is a poor fit

The current host may not support a required runtime, deployment workflow, staging pattern, database, commerce platform or traffic profile. Alternatively, its support model may not fit the organisation’s operating hours or escalation needs.

Compatibility must be confirmed against the real application. A sales page stating that a host supports WordPress, for example, does not confirm compatibility with every plugin, custom integration, scheduled task or deployment process.

Contract, ownership or access has become a material risk

Sometimes the infrastructure works, but the operating arrangement does not. The organisation may lack account ownership, billing control, administrator access, current documentation or a clear escalation path. Correcting governance in place may be possible. Where it is not, migration can restore control, provided access to the current environment and data is secured before the relationship ends.

When the better answer is to fix the current environment

Migration should not be the default response to:

• A single unexplained incident
• Poor Core Web Vitals caused mainly by page construction or third-party scripts
• Outdated CMS, plugin or application code
• Unoptimised images or database tables
• Incorrect caching or CDN rules
• A broken form, payment service or API that is independent of the host
• A DNS configuration issue that can be corrected safely
• A vague desire for a “faster” or “more secure” platform without acceptance criteria

Fixing the application, content or configuration may be faster, safer and less expensive. It may also expose the evidence needed to select the right destination later.

Move only when evidence and destination fit justify the disruption.

Define the destination before comparing providers

A useful hosting brief describes the workload and operating requirement, not a preferred logo.

Application and platform

Record the CMS or commerce platform, versions, runtime, database, search service, cache, scheduled tasks, background workers, file storage, deployment approach and any custom server requirements. Identify components that are no longer supported or would need upgrading as part of the move.

Traffic and performance

Use representative patterns, including ordinary periods, campaign peaks, seasonal events, crawler demand and administrative activity. Define key journeys and performance acceptance criteria. Average monthly visits alone can hide a severe launch-hour peak or a resource-intensive product import.

Data and recovery

Identify every data store and how quickly it changes. A publishing website may tolerate a short content freeze. An ecommerce site can accept orders, account changes and inventory movements throughout cutover, making final synchronisation and reconciliation more consequential.

Set recovery objectives against business impact. Confirm what is backed up, how often, where copies are stored, how long they are retained, who can restore them and whether restoration has been tested.

Security, privacy and access

Define account ownership, administrative roles, multi-factor authentication, logging, patch responsibility, secret management, data location requirements, incident notification and access for support teams. Review the provider’s shared-responsibility model and contract; never infer the boundary from the product name.

Availability, support and observability

Clarify service hours, escalation routes, monitoring, alert delivery, log access and the difference between provider response and restoration. Ensure that both infrastructure and application health can be observed. A server can be online while checkout or enquiry capture is failing.

Commercial and organisational fit

Compare the complete operating cost: hosting contract, licences, migration effort, specialist support, monitoring, backups, CDN, security services and internal time. Also confirm who owns the account, domain and data, how the arrangement can be exited, and how information will be retrieved at the end.

Inventory dependencies before touching DNS

A website is rarely one server. Build a dependency register covering:

• Application files, media and databases
• Domain registrar, DNS zone and nameservers
• TLS certificates and renewal method
• CDN, web application firewall and caching
• Transactional email and DNS records for email authentication
• Forms, payments, search, identity and consent tools
• CRM, ERP, PIM, WMS and other integrations
• Scheduled jobs, webhooks and queues
• Analytics, tag management and Search Console verification
• Vendor allowlists, fixed IPs, licences and callbacks
• Staging environments and deployment credentials
• Monitoring, logs, alerts and status communication

The inventory should state the owner, access holder, configuration source, test method and cutover action for each dependency. This is where hidden assumptions surface. A payment provider may allow traffic only from the old IP address. An API may call back to a fixed hostname. A firewall may block verified crawlers. An email service may depend on DNS records that someone planned to replace wholesale.

Build a migration runbook with a verified rollback path

A runbook converts a broad intention into sequenced, owned actions. It should be specific enough that the delivery team can execute and record the release without inventing decisions during the cutover.

A hosting migration is a release programme, not a file-copy task.

1. Capture the baseline and success criteria

Record current performance, availability, errors, resource use, search visibility, conversion tracking and key operational journeys. Define what the move must improve and which measures must not regress. Without a baseline, the organisation can complete the migration and still be unable to tell whether it solved the original problem.

2. Provision and secure the destination

Create the target environment with agreed access, network rules, runtime, database, backups, logs, alerts and deployment controls. Confirm account and billing ownership. Restrict non-production access appropriately and prevent a public test copy from being indexed.

Google’s current guidance for changing hosting recommends copying and thoroughly testing the site on the new infrastructure before changing DNS. It also suggests using a temporary hostname for testing and applying `noindex` to prevent the test site entering search results. Remove that block from the production destination at the correct release step.

3. Create and test recoverable backups

Take backups of files, databases, configuration and other necessary state. Verify integrity and perform a restoration test into a safe environment. A successful backup job is not the same as a proven recovery path.

For a dynamic website, define the pre-cutover backup, content or transaction freeze, final database synchronisation and reconciliation steps. The recovery point should be explicit: rolling back infrastructure after new orders have been accepted can create data loss or duplication unless the runbook addresses them.

4. Copy the application and test it in context

Test more than page rendering. Exercise:

• Priority pages and navigation
• Login, password reset and permissions
• Search, filters and downloads
• Forms, notifications and CRM routing
• Product, cart, checkout, payment and refund paths
• Integrations, scheduled jobs and webhooks
• CMS editing and media upload
• Redirects, canonical tags, robots directives and sitemaps
• Analytics, consent and conversion events
• Accessibility-critical interactions
• Performance under representative load
• Logging, alerting, backup and restore

Record failures, owners and retest evidence. A generic visual review cannot prove that an operational website is ready.

5. Prepare DNS, certificates and the cutover window

Identify the exact records to change and preserve unrelated records, particularly email and verification entries. Export the current DNS zone and capture the pre-change values. Confirm the destination can serve the correct domain and certificate before directing public traffic.

DNS Time to Live controls how long a record may remain cached. Cloudflare’s DNS documentation explains that longer TTLs can improve lookup caching but cause updates to take longer to reach users. Google’s hosting-move guide recommends considering a conservative lower TTL in advance, allowing existing caches time to refresh. The correct value and timing depend on the DNS arrangement; lowering TTL at the moment of cutover does not retroactively shorten records already cached.

Choose a window based on user demand, staff availability, vendor coverage and the data-freeze requirement. Low traffic can reduce customer exposure, but a midnight move is not safer if the people needed to diagnose an integration are unavailable.

6. Set objective go, pause and rollback criteria

The release owner should know which failures prevent cutover, which can be accepted temporarily and which trigger rollback. Criteria may include critical-journey results, error rate, database consistency, certificate status, monitoring, integration health and stakeholder acceptance.

Rollback must be technically and operationally credible. Define who makes the decision, which DNS or infrastructure state is restored, how new data is handled and how customers and internal teams are informed. A rollback plan that cannot reconcile transactions is only a diagram.

7. Execute, verify and communicate

Follow the runbook, timestamp actions and retain evidence. After directing traffic, verify DNS resolution from several locations, certificate delivery, server logs, application health and complete priority journeys. Check that temporary crawl blocks have been removed and Search Console verification remains available.

Do not describe the objective as guaranteed zero downtime. DNS caching, third-party dependencies, user sessions and data synchronisation create variables outside one team’s control. The credible objective is to reduce avoidable interruption and detect problems quickly.

8. Monitor both environments before retiring the old one

Google recommends monitoring traffic on the old and new infrastructure and shutting down the old environment only when the team is confident that users and Googlebot receive content from the new destination. Its guidance also notes that a temporary change in crawl rate after a hosting move can be normal.

Monitor application errors, response times, transactions, forms, integrations, resource use, certificates, analytics and search crawling. Compare the outcome against the baseline and success criteria. Keep the old environment protected and available for the agreed observation period, but prevent it from creating conflicting data.

Assign responsibility before the cutover

Hosting migrations fail organisationally when everyone assumes another supplier owns the same task.

Name one accountable owner for every migration action and decision.

The exact division varies, but a credible project normally clarifies:

• Client owner: business acceptance, account and contract decisions, access authority, risk acceptance, data ownership and final go or rollback decision.
• Emote: requirements advice, application assessment, migration planning, website or application work, test coordination, release coordination and communication within the agreed scope.
• Hosting provider: provision and operation of contracted infrastructure, platform-specific migration actions, provider controls, infrastructure support and provider-side incident response.
• Other vendors: registrar, DNS, email, payment, integration and software actions within their systems.

Emote can recommend and coordinate with an appropriate host or work with the client’s suitable existing provider. The hosting contract and infrastructure service remain between the client and provider unless a different current agreement is explicitly approved. This separation protects clarity: coordination does not mean that Emote operates the underlying infrastructure or guarantees the provider’s service.

Common migration mistakes

Selecting on headline specifications

CPU, memory and storage figures do not describe application fit, support, observability, recovery or operational responsibility. Compare against acceptance criteria.

Combining too many changes

Changing host, platform, URLs, design, integrations and tracking in one release multiplies variables. Sometimes changes must coincide, but the programme should then be treated as a broader replatforming project with corresponding Discovery, migration and search planning.

Treating a backup as a rollback plan

A backup is an input. Rollback also needs a decision, a restoration method, data reconciliation and verification.

Replacing the entire DNS zone

This can disrupt mail, verification and other services unrelated to the website. Change only the records in the approved runbook unless the broader DNS design is deliberately being replaced.

Turning off the old environment too early

Cached DNS responses and crawler behaviour mean traffic may continue reaching it. Monitor logs and preserve a controlled fallback until the exit criteria are met.

Finishing when the homepage loads

The real acceptance test includes revenue, forms, accounts, integrations, tracking, administration, monitoring and recovery.

Questions to ask before approving a hosting migration

• What evidenced problem or requirement justifies the move?
• Which part of the current stack is causing the constraint?
• What success measures will be compared before and after?
• Does the destination support the actual application and every material dependency?
• Who owns the host account, domain, DNS, certificates and data?
• What is included in infrastructure support, and what remains the customer’s responsibility?
• What is backed up, how often and how has restoration been tested?
• How will changing data be frozen, synchronised and reconciled?
• Which journeys and integrations must pass before cutover?
• What are the go, pause and rollback criteria?
• Who has authority to make the rollback decision?
• How long will old and new environments be monitored?
• When and how can the previous service be safely terminated?

Frequently asked questions

Can a hosting migration happen with no downtime?

Careful preparation can reduce disruption, and some architectures support gradual traffic movement. No generic provider or agency should promise zero downtime without understanding DNS, data writes, sessions, integrations and the release design. Define an acceptable interruption objective and a recovery plan instead.

Will changing host hurt SEO?

If user-visible URLs and content remain stable, the change is different from a URL migration. Google provides a specific hosting-change process and notes that temporary crawl-rate fluctuation can occur. Search performance still depends on access, response, stability and correct technical configuration, so monitoring is required and no ranking outcome is guaranteed.

How long does a migration take?

The implementation window may be short, but preparation can be substantial. Application complexity, data change rate, integrations, access, provider procedures, testing and governance determine the programme. A date should follow inventory and requirements.

Should the new host perform the migration?

Provider migration services can be useful, but their scope may cover only files and databases. Confirm who owns application testing, integrations, DNS, tracking, data reconciliation, acceptance and post-cutover support.

Does Emote provide hosting?

No. Emote does not sell, resell or directly provide hosting infrastructure. Emote can assess requirements, recommend and coordinate with an appropriate hosting partner, or work with the client’s suitable existing host.

Treat the move as a controlled release

A successful migration is not defined by copying a website and changing one record. It begins with evidence, requirements and ownership. It protects data, tests the actual journeys, controls DNS and certificates, sets rollback criteria and monitors the application until the new environment is proven.

That discipline helps the organisation solve the right problem and understand which party owns each continuing responsibility.

Explore Emote’s website maintenance and support capabilities.

If your current environment is constraining performance, reliability or support, book an initial meeting with Emote. Emote can help assess the website’s requirements and coordinate a controlled migration with an appropriate hosting partner or your suitable existing host.