Provider migration runbook

Migrate from Namecheap to Hostinger without gambling the live site

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.

8 controlled phases3 copies live, destination, offline backupDNS + email treated separatelyRollback decided before cutover

Scope first

Know what is and is not moving

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.

Source account

Keep Namecheap active, billable and accessible through stabilization.

Destination account

Confirm the exact Hostinger product supports the application, storage, traffic and runtime.

Domain and DNS

Record the registrar and authoritative nameservers. They need not move with hosting.

Email

Inventory every mailbox, alias, forwarder, MX record and sending service; test inbound and outbound separately.

Dynamic data

Orders, comments and submissions created during transfer need a freeze or final synchronization plan.

Recovery

Store a provider-independent file, database and DNS copy with restore instructions.

Pair-specific procedure

  1. 01

    Preflight

    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.

  2. 02

    Build the destination

    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.

  3. 03

    First transfer

    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.

  4. 04

    Acceptance test

    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.

  5. 05

    Final synchronization

    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.

  6. 06

    Cutover

    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.

  7. 07

    Stabilization

    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.

  8. 08

    Closeout

    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

Resolve these before DNS changes

Go/no-go gate

Acceptance matrix

Write the tester, timestamp, result and evidence for every row. “Looks fine” is not an acceptance result.

DNS

A/AAAA/CNAME resolve to intended destination; MX, SPF, DKIM and DMARC remain intact

Pass / fail / blocked
Application

Homepage, deep links, login, search, uploads, forms, API calls and scheduled tasks work

Pass / fail / blocked
Commerce

Cart, checkout, payment callback, stock, tax, customer email and refunds work with a real low-value transaction

Pass / fail / blocked
Data

Recent posts, users, orders and media exist; row counts and timestamps match the freeze point

Pass / fail / blocked
Security

HTTPS chain, redirects, administrator access, firewall rules and secrets are correct

Pass / fail / blocked
Performance

No material regression in server response, uncached pages or regional route compared with the agreed baseline

Pass / fail / blocked

Rollback

Decide the abort line in advance

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.

Before cutover

Rollback means abandoning the destination copy; the live site never moved.

After DNS cutover

Restore the previous records or nameservers and monitor resolution from multiple networks.

After new transactions

Do not blindly restore an old database. Reconcile orders, users and submissions first.

Official procedure library

Migration FAQ

Should the domain be transferred too?

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.

Will lowering DNS TTL eliminate downtime?

No. It can shorten caching for records whose resolvers honor it, but it does not repair application, certificate or email mistakes.

Can I cancel the old host after DNS changes?

Wait until DNS, HTTPS, email, forms, scheduled tasks and real user journeys are stable, and retain an independent backup first.

Does a free migration include email?

Do not assume so. Website, DNS and mailbox migration are distinct scopes; obtain written confirmation.

Compare the destination before committing

Model the renewal, backups and operational fit—not only the migration offer.

Open decision tools →