Source account
Keep Namecheap active, billable and accessible through stabilization.
Provider migration runbook
Create a complete WordPress copy, launch Hostinger's migration request or supported migration workflow, validate on the destination, then change DNS. This is an operational checklist, not a promise that either provider will migrate every site, mailbox or DNS record.
Scope first
A website transfer usually covers files and a database. It may not cover domain registration, DNS hosting, mailbox contents, licences, CDN rules, server jobs or third-party credentials.
Keep Namecheap active, billable and accessible through stabilization.
Confirm the exact Hostinger product supports the application, storage, traffic and runtime.
Record the registrar and authoritative nameservers. They need not move with hosting.
Inventory every mailbox, alias, forwarder, MX record and sending service; test inbound and outbound separately.
Orders, comments and submissions created during transfer need a freeze or final synchronization plan.
Store a provider-independent file, database and DNS copy with restore instructions.
Pair-specific procedure
Identify the registrar, authoritative DNS, web root, database, PHP version, cron jobs, mailboxes, forms, analytics, payment webhooks and third-party licences. Export the DNS zone and take an independent full backup before touching either account.
Add the site without pointing the live domain. Match the runtime, create a fresh database, enable a temporary URL or hosts-file preview and keep search-engine indexing disabled on the copy.
Use the documented provider workflow where eligible; otherwise copy files and database, update credentials and repair serialized WordPress URLs with a serialization-aware tool. Record every exclusion.
Test anonymous and signed-in paths, forms, transactional email, media, redirects, scheduled tasks, caching, security headers, checkout and mobile layouts. Compare database row counts and critical files.
Choose a quiet window. Freeze publishing and orders if the transfer method cannot synchronize changes. Copy the delta, repeat acceptance tests and lower DNS time-to-live only where the current DNS operator permits it.
Change only the necessary A, AAAA or CNAME records when possible. If nameservers must change, recreate MX, SPF, DKIM, DMARC, verification and subdomain records first. Confirm HTTPS after the destination can answer the domain.
Monitor both origins, external DNS, certificate status, logs, forms, mail delivery and real transactions. Keep the source online and unchanged until the longest relevant DNS cache and the agreed observation window have passed.
Create a new off-account backup, document ownership and renewal, remove temporary administrator access, update monitoring and only then cancel the old hosting. Domain and mailbox cancellation are separate decisions.
Provider-pair risks
Go/no-go gate
Write the tester, timestamp, result and evidence for every row. “Looks fine” is not an acceptance result.
A/AAAA/CNAME resolve to intended destination; MX, SPF, DKIM and DMARC remain intact
Pass / fail / blockedHomepage, deep links, login, search, uploads, forms, API calls and scheduled tasks work
Pass / fail / blockedCart, checkout, payment callback, stock, tax, customer email and refunds work with a real low-value transaction
Pass / fail / blockedRecent posts, users, orders and media exist; row counts and timestamps match the freeze point
Pass / fail / blockedHTTPS chain, redirects, administrator access, firewall rules and secrets are correct
Pass / fail / blockedNo material regression in server response, uncached pages or regional route compared with the agreed baseline
Pass / fail / blockedRollback
Rollback is appropriate when critical writes are missing, payment or login fails, email records were lost, HTTPS cannot be issued, or the destination is unstable. Stop new writes, restore the prior DNS answer, preserve both datasets, wait for caches, then reconcile anything created after the freeze. Do not delete the failed copy until evidence is retained.
Rollback means abandoning the destination copy; the live site never moved.
Restore the previous records or nameservers and monitor resolution from multiple networks.
Do not blindly restore an old database. Reconcile orders, users and submissions first.
Official procedure library
Confirm eligibility, current interface labels, exclusions and support boundaries directly with the provider.
Open official source ↗Primary documentationsupport.hostinger.comConfirm eligibility, current interface labels, exclusions and support boundaries directly with the provider.
Open official source ↗Migration FAQ
Usually not during the hosting cutover. Separating the changes reduces failure points; transfer the registration later if there is a clear ownership or renewal benefit.
No. It can shorten caching for records whose resolvers honor it, but it does not repair application, certificate or email mistakes.
Wait until DNS, HTTPS, email, forms, scheduled tasks and real user journeys are stable, and retain an independent backup first.
Do not assume so. Website, DNS and mailbox migration are distinct scopes; obtain written confirmation.
Model the renewal, backups and operational fit—not only the migration offer.
Open decision tools →