Editorial verdict
A migration succeeds only when evidence transfers authority
Preserve the old host until files, databases, forms, logins, scheduled work, payments, mailboxes, certificates, redirects, analytics and DNS have passed the acceptance tests that matter for this site.
Migration type selector
Start by naming the change
The default guidance below is readable without JavaScript. Selecting a type adds a focused warning; it does not send or save data.
Risk triage
Match the cutover method to the site’s write paths
Static brochure site
Usually one controlled copy and DNS switch. Still test HTTPS, redirects, forms, analytics, assets and every hostname.
Content site
Account for editorial changes, comments, media uploads, search, scheduled publishing and cache invalidation.
Transactional site
Orders, payments, bookings, memberships and form leads require a write freeze, final sync, replication or another tested reconciliation method.
Custom application
Inventory workers, queues, APIs, sessions, object storage, webhooks, allowlists, secrets, scheduled jobs and external callbacks.
No universal zero-downtime promise. Near-zero interruption may be feasible, but architecture, write rate and cached DNS answers determine the result. Define a measurable service objective instead of buying an absolute claim.
Dependency and write-path inventory
Record what moves, who owns it and how it is proved
| Dependency | Source of truth | Copy or final sync | Acceptance evidence | Rollback consequence |
|---|---|---|---|---|
| Files and media | Web root and external object storage | Initial copy plus changed-file sync | Counts, representative checksums and rendered assets | New uploads may need reconciliation |
| Database | Named primary and exact timestamp | Consistent dump, maintenance window or tested replication | Import succeeds; key record counts and journeys match | Writes after the snapshot can be lost |
| DNS | Authoritative zone export | Change only planned records | A, AAAA, CNAME, MX, TXT, CAA and other required records resolve | Cached answers may split traffic |
| Mailbox and routing inventory | Separate mail copy or coexistence plan | Inbound, outbound, reply, form and authentication tests | Mail may continue arriving at the old service | |
| Runtime and jobs | Version and task inventory | Recreate configuration, cron, queues and workers | Scheduled and background work completes once | Duplicate or missed work must be reconciled |
| Integrations | Application and vendor records | Update callbacks, allowlists and secrets | Forms, analytics, consent, payment and webhook test IDs | Retries must not create duplicates |
Record domain expiry and registrar status, nameservers, all hostnames, rewrite rules, database engines and character sets, runtime versions, licences, user uploads, environment configuration, certificates, CDN/WAF/cache, firewall rules, forms, customer accounts, subscriptions and external APIs. Keep secret values out of the worksheet.
Recovery proof
A backup archive is not a rollback until it restores
- Keep one encrypted provider-independent copy outside both hosting accounts.
- Capture files and database at one recoverable point or record their exact timestamps.
- Open and list the archive; import the database into an isolated destination.
- Compare representative media, file counts and data counts or checksums where practical.
- Log in and run the site’s critical journeys after restoration.
- Record every write after the snapshot and the final-sync method.
WordPress documents that a site normally includes both files and a database. Database consistency depends on the engine and write activity, so this guide does not prescribe one command for every platform. Use the backup and disaster-recovery guide and the WordPress restore drill before cutover.
Migration state board
Advance only when the named evidence exists
Scope, owners, freeze method, acceptance tests and rollback triggers approved.
Initial files, database and configuration copied with timestamps.
New origin tested without changing public traffic or allowing indexing of a duplicate.
Writes controlled; final IDs, timestamps and sync evidence recorded.
Planned DNS change made by the named owner and change record saved.
Traffic, errors, transactions, email and external integrations monitored.
Technical and business journey matrices pass; rollback remains possible.
Observation and rollback windows close; evidence and backups remain accessible.
DNS, email and HTTPS
Prepare the control plane before cutover
DNS time to live (TTL) is a cache lifetime, not a global countdown. Lower the relevant record at least one old TTL window before cutover so previously cached answers can expire. Verify authoritative answers and independent recursive resolvers, including both IPv4 and IPv6 where published. Restore a normal TTL only after acceptance.
DNS record
- Export the complete old zone
- Compare A, AAAA, CNAME, MX, TXT, CAA, SRV and verification records
- Handle DNSSEC deliberately when nameservers change
- Save before-and-after evidence
Email continuity
- Inventory mailboxes, aliases, forwarders and catch-alls
- Copy historical mail or define coexistence
- Test inbound, outbound and replies externally
- Inspect SPF, DKIM and DMARC results
TLS and edge
- Serve every hostname with a valid certificate chain
- Test HTTP-to-HTTPS redirects and mixed content
- Verify CDN/WAF origin access and cache rules
- Confirm automated certificate renewal
Access security
- Use unique least-privileged temporary access
- Transmit credentials through an approved secure channel
- Keep secrets out of tickets and screenshots
- Revoke or rotate access after acceptance
Changing hosting does not normally require a registrar transfer. See nameservers versus DNS records, preserving email, and SPF, DKIM and DMARC.
Acceptance matrix
Test user journeys, not only the homepage
| Journey | Evidence before acceptance | Failure signal |
|---|---|---|
| Public web | Homepage, representative deep URLs, redirects, 404, canonical, robots and sitemap | Wrong status, broken asset, redirect chain, lost metadata or blocked crawl |
| Identity | Login, logout, password reset, session and role checks | Failed login, stale session or privilege mismatch |
| Forms and mail | Submission ID, notification, reply and stored lead | Missing record, mail failure or duplicate |
| Commerce or booking | Controlled test order, payment callback, invoice and inventory change | Failed or duplicate transaction, missing webhook or stock mismatch |
| Background work | Cron, queue, scheduled post, backup and integration logs | Missed or double execution |
| Measurement | Analytics marker, consent behavior and monitoring receive a known test | Missing or duplicate events, unexpected tracking before consent |
| Performance and edge | Origin and edge responses, cache behavior and representative regions | Origin overload, stale content or unexpected block |
Rollback contract
Define the decision before pressure arrives
| Observed failure | Trigger | Immediate action | Data reconciliation |
|---|---|---|---|
| Checkout or booking | One confirmed critical-journey failure after the planned retry | Decision owner pauses cutover or restores old traffic | Compare transaction and webhook IDs across both origins |
| Missing writes | Any unexplained gap between final old and first new record | Stop writes and investigate source of truth | Export, deduplicate and replay only with tested controls |
| TLS or hostname | Invalid certificate or required hostname unavailable | Restore known-good traffic route | Normally no data merge; preserve logs |
| Error or latency | Sustained breach of the site’s predeclared window | Disable optional load, then roll back if unresolved | Reconcile writes made during partial traffic |
The rollback owner must know who changes traffic, how cached DNS affects the reversal, whether the old origin is still writable, and how writes received during the failed cutover will be merged. AWS migration guidance similarly recommends predefined rollback checkpoints, strategy and decision ownership.
Managed migration scope
Compare what the service excludes
Checked 18 August 2026. These are examples of current documented process, not rankings or guarantees. Confirm eligibility and current terms in your account before sharing access or changing DNS.
Hostinger
Its current migration guide says the process includes website files and databases but excludes email, cron jobs, DNS records, custom SSL configuration and FTP accounts. WordPress multisite is not supported through that route.
Evidence: official migration guide, updated recently.DreamHost
Its live-site transfer guide separates website files, database and email, and instructs readers to test the destination before pointing DNS. Professional and self-service WordPress paths have different scope.
Evidence: official transfer and WordPress migration documentation.Cloudways
Its assisted process requests source access, application details and critical journeys to test. Its go-live documentation treats validation, DNS and TLS as separate tasks after the application copy.
Evidence: official end-to-end migration and go-live documentation.Check current migration scope
Ask what is included, who owns the final sync, which tests mark completion, how access is protected, what happens after failure, and whether post-cutover help is included.
Affiliate disclosure: These provider links may earn Web Host Lens a commission without changing our evidence standard or scores. The documentation links in the source library are direct and untracked.
Local migration checklist
Record the minimum evidence before retirement
Next account step
Retire the old host only after every gate closes
Complete all nine migration evidence gates before opening the cancellation runbook. Your checklist stays in this browser tab and is never submitted.
Continue to safe cancellationLocked: 9 migration evidence gates remain.
Frequently asked questions
Website migration questions buyers ask
Can a website migration truly have zero downtime?
Not universally. Static sites can often move with little interruption, but dynamic sites need a tested final-sync or write-freeze strategy and DNS caches can continue using an old answer until it expires.
Does lowering DNS TTL make propagation instant?
No. A lower TTL shortens future cache lifetimes only after previously cached answers expire. Lower it at least one old-TTL window before cutover and verify authoritative and recursive answers.
Does changing web hosts require a domain transfer?
Usually no. Hosting can change by updating web-facing DNS while the registrar remains unchanged. Combining a registrar transfer with a host move creates another variable and should be justified separately.
What should a complete website backup contain?
It should cover website files, databases and required configuration, with timestamps and any external assets documented. A backup is not proven until it can be restored and critical journeys work in an isolated destination.
How do I prevent lost orders or form submissions?
Identify every write path, choose a maintenance window, read-only mode, incremental sync or tested replication method, then record the last accepted item on the old origin and the first on the new origin.
What happens to email when I change hosting?
Email does not automatically move with website files. Inventory mailboxes and MX, SPF, DKIM and DMARC records, migrate historical mail separately, and test inbound, outbound, replies, forms and transactional messages.
What should trigger a migration rollback?
Set measurable triggers before cutover, such as failed checkout, missing writes, invalid TLS, sustained error rates or unavailable login. Name the decision owner and how new data will be reconciled before reverting traffic.
When is it safe to cancel the old hosting account?
Only after DNS and traffic have converged, business-critical journeys and email pass, monitoring stays stable through the agreed observation window, backups are retained and the rollback window has formally closed.
Are free or managed migrations always comprehensive?
No. Confirm included applications, databases, email, DNS, SSL, cron, queues, subdomains, size limits, final sync, validation, retries and post-cutover support using current provider documentation.
Will changing hosts hurt SEO if URLs stay the same?
A same-URL infrastructure move follows a different process from a domain or URL change. Preserve URLs, metadata, status codes, canonicals, robots rules and internal links, test the new origin and monitor both environments during cutover.
How should migration credentials be handled?
Use unique least-privileged temporary access where possible, transmit it through an approved secure channel, keep secrets out of screenshots and evidence packs, then revoke or rotate access after acceptance.
How long does a website migration take?
There is no universal duration. Data size, transfer path, write rate, compatibility work, validation depth and cached DNS answers all affect completion. Treat a provider estimate as a planning input, not an acceptance test.
Primary source library
Claims, dates and uncertainty
Sources checked 18 August 2026. Provider scope can change; standards and platform documentation apply only within their stated context.