Hostinger Website Migration: Move WordPress Without Losing Email

Quick answer: copy first, connect later

A Hostinger website migration should be planned as a transfer plus a verification process. Getting the homepage to load is only one checkpoint. Your visitors also need working links, images, forms and account journeys, while your team still needs email and access to business records.

Our recommended sequence is simple: identify everything the website depends on, preserve a recovery copy, prepare the destination, transfer the site, test it, and then make the domain change. Keep the previous service available until you have verified the result.

This guide focuses on an existing WordPress website keeping its domain. It is based on official documentation and editorial planning advice. We have not timed your migration or benchmarked your site, so we do not promise a fixed completion time, zero disruption or higher search rankings.

Is free migration available for your website?

Hostinger documents free assisted migration for eligible external websites on Web, Cloud and Agency hosting. Self-hosted WordPress and other supported open-source CMS sites can qualify; VPS and internal Hostinger moves follow different arrangements. Proprietary builder sites are not a direct WordPress transfer.

Confirm the current eligibility with support before buying. A WordPress site hosted at GoDaddy is different from a site built with GoDaddy Website Builder. Similarly, owning a domain at a company does not tell you what software serves the website.

Write down the source platform, approximate storage requirement, destination plan and any unusual dependencies. This short description helps support answer the right question. An inexpensive plan is not good value if it cannot accommodate the project you intend to move.

Our Hostinger plan comparison can help organize feature priorities. Treat your account and current checkout as the final authority on allowances and availability.

Website, domain and email are three separate decisions

You do not need to make every change in the same maintenance window. Our recommendation is to keep the project as narrow as possible. For example, a website move can be planned while you retain your existing registrar and mail provider.

Assign an owner to each task. A developer handling the site should not assume that someone else has preserved the mail settings. A single written plan makes those responsibilities visible before a customer notices a problem.

Build a migration inventory before making changes

Choose a few representative pages: the homepage, a long article, a page with a form, your highest-value landing page and any customer login. Save screenshots and note the expected result of each interaction. Include mobile navigation and your main calls to action.

Record where media files live and which external services the site uses. Payment gateways, appointment calendars, SMTP delivery, analytics and affiliate redirects all deserve an explicit test. A migration can look complete while a small integration remains unverified.

Keep a private list of plugin licenses and configuration locations. Store credentials in an appropriate password manager, rather than in a public checklist or support screenshot. Share access only through the official provider workflow and revoke temporary access after the job.

Finally, decide who can approve the domain change. That person should receive the test results, the unresolved issues and the recovery plan. An informed approval is more useful than simply being told that the upload finished.

Preserve a usable backup and a realistic rollback plan

Keep a recovery copy that includes the website files and database. Record its creation time and which installation it belongs to. A folder full of archives is less useful if nobody knows which archive contains the current production data.

Our Hostinger backup guide explains recovery planning after the move. For the source site, use the tools supported by your current provider and confirm that you can actually retrieve the backup.

Define what would trigger rollback: a critical checkout failure, missing recent records or a persistent access problem, for example. Also define who will carry it out. Do not wait for an outage to decide which system has the authoritative information.

A rollback is especially delicate after the new site begins accepting orders, registrations or comments. Preserve newer records before reverting. Simply restoring an older database can undo valid customer activity, even if it restores the design you expected.

Submit the right migration request

In Hostinger’s dashboard, look under Websites for Import Website or Migrations. The assisted flow supports WordPress or cPanel login access for online sites, and a backup-upload route. A WordPress backup needs both application files and its database.

Review the domain and destination carefully before submitting. Keep the original service accessible during the process and follow the provider’s instructions about when to connect the domain. See the official migration guide for current controls and requirements.

Our editorial advice is to avoid simultaneous redesigns or plugin replacement during the move. If the destination looks different, you want a short list of possible causes. Combining several projects makes diagnosis and recovery harder.

For an agency project, record exactly which installation is in scope. A staging subdomain and the main website can contain different data. Never treat similar names as proof that either one is the correct source.

If login access fails, diagnose before retrying

Hostinger’s request troubleshooting guide identifies inaccessible login URLs, unsuitable access roles and authentication challenges as possible obstacles. It also offers the backup-upload alternative when protection prevents the assisted login flow.

First confirm that the source login page works through the normal authorized route. Give support the error message and the relevant URL, without exposing passwords. Repeatedly submitting the same request does not establish which prerequisite failed.

Prefer a supported backup route if it meets the project’s needs. If support proposes a temporary authentication change, understand its scope and restoration steps before approving it. Keep a record of any adjustment and verify the intended protection afterward.

Do not interpret a migration warning as permission to remove unrelated security settings. Solve the specific access problem, preserve the website and return to the verification plan.

Track progress without assuming a promised deadline

The migration-status documentation explains Pending, Updated, In progress, Completed and Rejected states. For a rejection, inspect the reason and next steps. A “Taking longer than expected” message alone does not mean the migration failed.

Use the current request status as the operational signal. Our advice is to schedule the domain change around a completed and tested transfer rather than around an estimate somebody remembers from another website.

If you need help, send support the request identifier, the visible state and the time you last checked. A concise description is easier to investigate than a long series of screenshots without context.

Meanwhile, preserve the source service and avoid unplanned edits that create competing versions of the site. Tell anyone who normally publishes content which environment they should use and when they can resume normal work.

Test the destination as a visitor and as an administrator

Open the transferred site through the supported preview method before changing public routing. Hostinger describes using a preview with the destination IP. Treat that as a functional check, then repeat important tests on the real domain after the change.

Our test list starts with the pages you recorded earlier. Compare the header, typography, content and image placement. Click your main CTA and confirm its destination. Submit a clearly marked test form and verify receipt in the intended inbox.

Then check an administrator’s routine work: logging in, opening an existing post, finding its media and reviewing the expected settings. Save changes only when necessary for the test. A successful login is useful, but it is not evidence that every business workflow works.

For a store, use the payment provider’s approved test process. Verify the resulting order and notification without creating an unintended charge. Mark every test with its expected outcome so a reviewer can distinguish a pass from an untested feature.

Connect the domain and protect existing email routing

Hostinger’s domain-connection guide describes changing nameservers or retaining external DNS and updating website records. Use the values provided for your destination account. A server address from another project is not a safe template.

If you keep Cloudflare DNS, update the website destinations in that zone. If you change nameservers, inventory and recreate required records in the destination zone. Preserve the current mail provider’s MX and authentication records when email is staying there.

Our recommendation is to save a before-and-after record of the exact changes. Include the apex domain, www and any subdomains actually in use. Check for conflicting old destinations rather than deleting every record with an unfamiliar name.

Confirm secure HTTPS access after routing changes and investigate certificate errors through the provider’s supported process. Do not count a browser security warning as a successful launch. Complete this stage before advertising the new environment as ready.

Move email only if your plan includes an email move

If you are changing mail providers, make it a separate workstream. Hostinger’s email migration guide covers recreating mailboxes and settings, configuring the required DNS, importing messages and updating email clients. Website migration does not automatically carry out that workflow.

Our acceptance checks include sending from an outside address to the business inbox, replying, checking a second mailbox and confirming important historical folders. Test forwarding rules and the account used by website notifications, not just a personal inbox.

Give staff a clear transition message: which login to use, who to contact for help and what they should report if mail appears missing. Preserve access to the previous service until the relevant information and delivery have been verified.

If mail is staying with Google Workspace or another provider, document that explicitly. This prevents an otherwise well-intentioned website change from becoming an unnecessary mailbox migration.

Protect URLs, search visibility and analytics

Keeping the domain and permalink structure reduces the number of things to change. WordPress’s migration handbook explains that files, database configuration and site URLs need to agree. When URLs change, use a supported method that handles stored data correctly.

Our recommendation is to retain your important URLs during a hosting-only move. Compare a sample of existing articles, category links and redirects. Verify that public production pages have the intended canonical addresses and are not accidentally left with staging restrictions.

Check the sitemap and inspect representative pages in your search tools. A submission is a request for discovery or crawling; it does not guarantee indexing or ranking. Monitor the outcome rather than presenting the act of submitting as an SEO win.

Also validate a normal analytics visit and an affiliate click through the intended tracking workflow. A site can look healthy while its reporting has silently stopped recording useful activity.

Troubleshoot the exact symptom after launch

Hostinger’s post-migration troubleshooting guide covers temporary-domain connections and stale cache among common issues. Identify the affected URL and which environment you are viewing before changing settings.

Our diagnostic approach is to separate appearance from function. An old image may involve caching; an unsuccessful form needs a delivery check; a missing page needs a routing check. One broad “clear everything” action will not explain all three.

Keep a short incident record containing the expected result, the actual result and the smallest change that fixed it. This helps you avoid repeating the same experiment and makes a support handoff clearer.

After the site is stable, revisit performance as a separate project. Our object-cache guide explains one possible layer, while the staging guide helps plan future changes. Verify improvements instead of assuming the hosting move solved every delay.

Is moving to Hostinger worth the effort?

A migration makes sense when it addresses a specific problem or improves the package you actually use. List your reason: resource limits, a better recovery workflow, easier management or a more suitable budget. Then compare that reason with the disruption and staff time involved.

Look beyond the introductory monthly equivalent. Check the total initial charge, renewal price, essential extras and any separate email expense. Our Hostinger renewal-price guide helps frame the comparison.

For a small editorial site, straightforward management may matter more than unused advanced features. For a busy business, a documented recovery process and clear support responsibilities can be more valuable than a small initial saving. Match the decision to the actual project.

If the plan fits, try TECHSOLV10 for a 10% discount on eligible purchases through our affiliate link. Confirm the payable amount before purchasing. A coupon helps with cost; it is not evidence that a particular plan is right for your website.

Frequently asked questions