A hosting migration is complete only when the destination serves the right content and the important journeys still work. Copying files is one part of the change. The safest plan keeps the old service available, validates a private destination and defines what to do with new data if a return is necessary. This checklist concerns a conventional self-hosted WordPress site. A shop, membership service or unusual application needs a plan for its additional writes and integrations.
Inventory more than the web directory
Record the domain registrar, authoritative DNS service, web host, database, mail provider and the people who can recover each account. List media, scheduled tasks, redirects, certificates and outbound integrations. Mark the URL paths that must stay unchanged. A hosting move with the same domain normally should not require changing every article address. Avoid combining it with a redesign or permalink change unless there is a separate, tested reason.
WordPress’s backup documentation distinguishes files from the database: a conventional complete recovery needs both. Downloading the web directory alone does not necessarily include the database. Store a matched backup set privately, protect credentials and test restoration away from production. Do not leave a downloadable archive containing configuration secrets on a public website.
Understand what the migration service excludes
Hostinger’s migration documentation, checked on 26 September 2026, includes website files and databases but excludes email, cron jobs, DNS records, custom SSL configuration and FTP accounts. Its free external migration conditions concern eligible open-source CMS sites on Web, Cloud or Agency plans, not VPS. It does not support WordPress Multisite through that migration route; internal Hostinger moves have separate conditions. Confirm eligibility rather than assuming that every transfer is free.
This example explains why an assisted transfer is not a complete business continuity plan. Even if a supplier copies the site, the operator must account for excluded services and test the result. Share temporary, narrowly scoped access through the supplier’s official secure process where supported, and revoke it afterwards. Do not email reusable administrator passwords or disable account protections casually.
Build a private rehearsal
Restore the copy on the destination before changing public DNS. Restrict access: a noindex tag is not an access control. Prevent the copy from sending real messages, charging cards or executing duplicate scheduled work. Confirm that the application can use the destination’s database, storage and supported runtime. A temporary address can help inspect a site, but some domain-sensitive functions need a test configuration designed by the operator.
Walk through the homepage, an old article, search, language selection, images, login and the contact journey. For commerce, add a permitted sandbox transaction rather than a fake real order. Check redirects, canonical URLs and sitemap paths. Record expected results and unresolved failures. A screenshot of the homepage is insufficient evidence that the migration is ready.
Prepare DNS without disturbing email
Decide whether the change concerns the web address records or the whole authoritative DNS service. Preserve the existing mail routing and authentication records unless email migration is deliberately in scope. If a lower DNS time-to-live is useful, plan it before the cutover and allow existing cached values to age; it cannot recall records already cached elsewhere. Keep a dated copy of the original zone and the intended changes.
Hostinger’s guidance says to complete the website migration before pointing the domain. The same sequencing is useful as a general planning principle: prepare, validate, then switch. Do not cancel the old host just because a transfer job reports success. Clients can reach different destinations while caches expire, and rollback still depends on the old copy being usable.
Control the last copy and new writes
Choose a quiet period and define how content changes, form submissions and orders are handled. A small editorial site may pause publishing briefly for a final synchronisation. A busy shop needs a more specific approach to new transactions. Decide which system is authoritative at each stage so that two installations do not independently accept changes that will later be overwritten.
After switching, verify DNS answers, TLS certificates, page status codes and the key journeys from outside the hosting control panel. Watch application errors and message delivery. Record the actual results rather than inferring success from a green dashboard. A missing contact email or background task can be commercially important even when every page returns HTTP 200.
Define rollback before using it
Specify which failures justify returning to the old host, who decides and how to recover data created on the new one. Repointing DNS alone does not move recent orders or enquiries back. If there are new writes, reconcile them under a documented procedure before abandoning the destination. Do not run a destructive restore against the only production copy.
Retire the old environment only after the agreed observation and recovery conditions are met, backups are usable and temporary access is revoked. Keep the migration record with the site operator. This process reduces avoidable mistakes; it is not a promise of zero interruption or unchanged search rankings.
Documentation checked: 26 September 2026. References: WordPress “Backups” and “Migrating WordPress”; Hostinger “How to migrate a website to Hostinger”. Documentary checklist, not a migration performed for a customer. No purchase or affiliate link is included.