Define what is actually moving
A hosting migration changes where a website is served, but it does not automatically transfer ownership of the domain, mailboxes, subscriptions or external integrations. Write down the intended outcome before selecting a method: replace an unreliable server, change technology, consolidate suppliers, or move to a managed service. Record whether visitors will keep exactly the same URLs and whether the application will remain the same. These answers determine how to handle search visibility, databases, redirects and testing. Treat migration as a controlled business change with a named decision-maker, not merely a file upload.
Make an inventory that someone else can use
List the live domain and subdomains, hosting account, content management system, runtime versions, database engine, themes, plugins, scheduled jobs and storage locations. Include downloadable brochures, images, user uploads, redirects, custom error pages and any protected directories. Identify who controls each account and whether access can be recovered if the usual technician is unavailable. A small company may discover that its contact form uses a third-party service while its website uses another provider. An inventory prevents that dependency from disappearing during a seemingly straightforward server move.
Separate domain control from hosting control
Confirm the registrar account, domain expiry date, authoritative nameservers and current DNS administrator. Hosting renewal and domain registration are separate obligations even when a single invoice covers both. A server migration normally needs changes to selected web-facing A, AAAA or CNAME records; it does not necessarily require changing the registrar or authoritative nameservers. Export or record the entire DNS zone before planning edits, including entries that look unrelated to the website. Do not use a hosting migration as an excuse to transfer domain ownership or change unrelated services without a separate approved plan.
Protect email before changing DNS
Identify the current MX destinations, SPF policy, DKIM selectors, DMARC record and any autodiscovery or verification records. A website may move while the company's email stays with its existing provider. Replacing nameservers without reproducing these records can interrupt incoming mail or weaken authentication even if the new website loads correctly. If the old hosting account also receives mail, investigate mailbox storage and local routing before closing it. cPanel's email-routing choice is a server-side setting, not proof of the public DNS configuration. Test real sending and receiving only within an authorized migration acceptance plan.
Capture a useful baseline
Before moving anything, record the working state of the existing website. Save a representative list of important URLs, response codes, page titles, language alternatives, form behavior, downloadable files and mobile screenshots. Note which features require a signed-in account, which depend on a payment gateway, and which must not be tested with real customer transactions. Capture available performance observations and the time of the observation, but do not promise the new host will automatically improve them. The baseline gives reviewers a concrete comparison and helps distinguish pre-existing faults from migration regressions.
Back up more than the visible pages
Create a recoverable copy of the required website files, database, media uploads and application configuration, using the platform's supported method. WordPress guidance explicitly includes the database, plugins, images and other files when moving servers. For cPanel accounts, understand the difference between a full account backup and individual partial backups; a full archive cannot simply be restored automatically through the ordinary cPanel interface. Confirm where the archive is stored, who can access it and whether it can be read. A backup label or successful download message alone does not prove recoverability.
Test restoration without overwriting production
A safe migration plan asks whether the backup can restore a usable site in an isolated destination. Verify the file tree, database tables, sample records and a selection of uploaded documents after restoration. Avoid restoring over the live account simply to test the archive. If the supplier must perform full account restoration through an administrative interface, confirm that responsibility and any prerequisites in writing. Record the result, missing components and elapsed restoration time. These observations are more useful than a vague claim that backups run daily, especially when a rollback window is limited.
Check destination compatibility before paying
Compare the target service against the actual application, not just advertised disk space. Check supported runtime and database versions, file permissions, scheduled tasks, extensions, upload limits, outbound connections and certificate arrangements. An older plugin may fail on a newer PHP version; a static site may not need PHP at all. Ask who manages security updates, logs, backups and emergency access under the proposed contract. If the migration needs specialized support or downtime, establish that scope separately. Do not infer that a supplier's general marketing page guarantees a particular feature on the chosen plan.
Plan database consistency and last-minute changes
A dynamic site can keep accepting orders, comments or enquiries while its files are copied. If the old database changes after the copy, the new site may launch with missing records. Choose an appropriate approach: a short approved maintenance window, a final database synchronization, or an application-specific replication process handled by a qualified operator. Record the exact cutoff and how new submissions will be reconciled. Never silently discard transactions or assume a copy made yesterday is current. A static brochure site has fewer moving parts, but its external form submissions still require an independent continuity check.
Handle WordPress URLs and stored settings carefully
For a WordPress move that preserves the domain and page paths, copying files and database may be sufficient, subject to configuration differences. If the database credentials change, the site's configuration must reflect the new connection. Changing the domain or paths is a different project: database values can contain embedded URLs, including serialized data that ordinary text replacement can damage. Follow WordPress's migration guidance and use a serialization-aware process where necessary. Check menus, media, canonical URLs and login behavior after migration. Do not combine a hosting move with a redesign unless the additional risks are deliberately scoped.
Prepare a staging copy that cannot confuse customers
Use a restricted staging environment to test the migrated site before redirecting public visitors. Prefer access controls and a temporary hostname that does not look like the official customer-facing address. If a test hostname is publicly reachable, Google recommends preventing accidental indexing while testing; remove any temporary noindex or crawler block from the real production copy before launch. Disable real payment capture, external notifications and production automation in staging unless a bounded test has been explicitly authorized. Label sample data clearly and avoid copying sensitive customer information unnecessarily. A staging screenshot is not evidence that the live site works.
Check pages, assets and language parity
Test a deliberate sample of the homepage, service pages, article pages, contact route, privacy information, downloads and error pages. Open the site on narrow and wide screens and confirm fonts, images, navigation, contrast and keyboard access. For an English and Bahasa Melayu website, inspect both language versions and their links rather than assuming one passing page proves the other. Confirm that images do not point back to the old server and that downloads use expected content types. Keep a defect log with the URL, observed result, expected result and person responsible for correction.
Preserve URLs and search signals
If public URLs stay unchanged, Google's hosting-change guidance treats the move differently from a site migration that changes URLs. Preserve existing page paths, titles, canonical tags, hreflang links, robots directives and sitemap references. Compare representative response codes before and after the move, including redirects and genuine 404 responses. If paths must change, prepare a reviewed old-to-new redirect map and follow the separate guidance for URL-changing moves. Keep Search Console ownership verification working; a forgotten verification file or tag can complicate monitoring. Neither an unchanged domain nor a successful DNS change guarantees rankings.
Verify HTTPS at the actual destination
Before cutover, confirm that the destination can serve the intended hostnames using valid HTTPS certificates and the correct application configuration. Test both the root domain and www if both are in use, plus any subdomain that will move. If a CDN or reverse proxy sits in front, check the encrypted connection to the origin as well as the visitor-facing certificate; one successful browser padlock does not prove the complete path is configured correctly. Inspect redirect loops and mixed-content warnings. Certificate issuance and renewal may depend on DNS reachability, so schedule them before the public switch where possible.
Validate forms and integrations without exposing data
A contact page can render perfectly while its submission endpoint fails. Inventory form processors, anti-spam verification, webhook destinations, email notifications, maps, booking tools and payment providers. For each integration, identify a safe test method, expected response and owner of the receiving system. Avoid using genuine customer details or triggering live transactions during rehearsal. Confirm the privacy notice still describes actual processing, and that required secrets remain outside public source files. Where a backend endpoint is out of scope or protected by a separate release gate, record it as unverified rather than declaring the entire site accepted.
Review caches and external dependencies
A migration may involve browser caches, CDN caches, application caches and DNS caches, each with different behavior. Inventory any proxy rules, cache exclusions, redirects and content security settings before changing infrastructure. After copying the site, test both a fresh request and a previously visited page so an old cached copy does not conceal an error. Check whether static assets have stable URLs or versioned filenames. Do not purge every cache or alter a production CDN blindly: an aggressive change can increase origin load or expose pages that were deliberately uncached. Coordinate cache changes with the authorized cutover.
Keep credentials and permissions controlled
Confirm that the new environment has named administrators, least-privilege access, supported authentication and a process for removing temporary migration accounts. Move secrets using an approved secure channel rather than pasting passwords into tickets, shared documents or public repositories. Review file ownership and write permissions after copying content; a page that loads may still be unable to save uploads or updates. Check that private backups, logs and configuration files are not publicly downloadable. If a supplier needs elevated access, define the duration and revoke it after verification. Access changes require their own authorization and audit trail.
Choose a cutover window based on business activity
Pick a change window by looking at real enquiries, orders, staff availability and supplier support hours, not by assuming midnight is always safest. Assign a person to approve the switch, one to perform it and another to verify results where resources allow. Prepare a concise internal notice describing the expected effect, emergency contact and conditions that would cancel the move. For a hypothetical Malaysian appointment-based business, moving during a quiet period may reduce disruption, but a critical booking system still needs a transaction plan. Do not promise zero downtime when that has not been demonstrated.
Understand TTL and the DNS switch
Google recommends considering lower DNS time-to-live values ahead of a hosting change so caches can refresh sooner. TTL is not a universal instant-switch button: different resolvers and cached answers can cause old and new destinations to receive traffic during transition. Record which exact web-facing records are authorized to change and the prior values needed for rollback. Check the authoritative DNS provider rather than assuming the old host's zone editor controls public answers. Avoid changing MX, nameservers or DNSSEC as collateral work. Keep both environments capable of serving consistent content while cached answers expire where feasible.
Monitor evidence after the switch
After an authorized cutover, check the important URLs from more than one network and verify their HTTPS response, content and language variants. Review logs on old and new servers if access is available; Google specifically advises watching traffic shift before shutting down the previous host. Watch application errors, missing media, failed form submissions and unusual redirects. Use Search Console to observe crawl and indexing signals without treating a temporary fluctuation as proof of a penalty. Record timestamps, test conditions and unresolved defects. A green status page or a single successful homepage load is insufficient acceptance evidence.
Define rollback triggers before trouble starts
A rollback plan should name the previous DNS values, the old serving environment, the most recent consistent data snapshot and the person authorized to reverse the change. Specify objective triggers such as critical transactions failing, widespread certificate errors or missing customer records, together with a decision deadline. Reverting DNS alone may not recover database writes that occurred on the new site; dynamic applications need a reconciliation strategy. Test whether the old environment can still serve users during the planned transition. Keep rollback instructions separate from an untested promise that everything can be restored in minutes.
Close the migration only after handover
A completed technical switch is not the same as a completed business handover. Record the new provider, renewal owner, billing contact, administrator, backup schedule, certificate renewal responsibility and location of the current configuration inventory. Obtain evidence that critical pages and authorized integrations passed their acceptance checks. Confirm that staff know how to report a problem and which supplier owns each layer. Retire the old service only after traffic, data retention, mail dependencies and contractual notice requirements are reviewed. For an OnHypp enquiry, request a scoped assessment of the existing site and migration constraints; do not assume migration, monitoring or ongoing care is included in an unrelated hosting plan.
Move the application without disturbing business email
The migration plan must inventory A/AAAA and CNAME records separately from MX and mail authentication TXT records. Schedule a website-only cutover, retain the prior application backup and validate forms, checkout, logins and database writes before closing the change. A successful homepage response is not sufficient evidence that transaction workflows work.
Confirm whether the existing domain should remain at its present registrar and avoid paying twice for the same registration. In any plan, record the customer-approved site document root, SSH deployment scope, backup restoration method and rollback conditions before DNS changes.
Sources & further reading
Ready to explore a related service?
See the related OnHypp service and decide whether it fits your business needs.
Email & hostingDomainsWebsite design