Hostinger bundles a free, unlimited migration service into every hosting plan, built around a wizard that lives inside hPanel. It comes down to three real options.
- Login details, the path Hostinger recommends, connects directly to your current site and pulls everything over automatically
- Backup upload, for static sites or anyone who would rather hand over a file than share a login
- Fully manual, skipping the wizard entirely for the handful of situations neither of the above covers
The tool only appears once you have an active hosting plan, and Hostinger’s plans start around $2.99 a month on longer terms, though which tier actually makes sense depends on how much storage and traffic your current site uses rather than the cheapest number on the page.
If you want to find out more about Hostinger’s large array of plans and see a full breakdown comparison between them, our Hostinger review covers pricing and performance across the full range. And once you’ve made your decision, don’t forget to check if there are any available Hostinger coupons.
Watching a Real Migration Happen
With the three options laid out, I picked the one Hostinger itself recommends and went hands-on with it, so you see what actually happens rather than what the marketing page promises.
I wanted to see the recommended path from the inside rather than take Hostinger’s word for how smooth it is, so I ran an actual WordPress site through it, start to finish, using the login-details method.
Before I Started
A few things needed to be in place before the wizard would do anything useful.
- The URL of the site being moved
- A decision on how to connect: a WordPress dashboard login or a cPanel login, whichever the current host actually offers
- Two-factor authentication and CAPTCHA protection turned off temporarily on the site’s admin login, since the wizard connects the same way a person logging in would, and either one blocks it outright
- My own backup of files and database kept on the side, not because the tool needed it, but because a fallback costs nothing if something does go wrong
Getting Started
In hPanel, I clicked Websites in the left-hand sidebar first, and a submenu dropped down underneath it, WordPress, AI Builder, Web Apps, PHP/HTML, and Migrations. Migrations is what I actually wanted, so I clicked that next.
That took me to a page laying out the whole pitch before asking for anything. Migrate your site from another provider, for free, share a few details and the rest gets handled automatically, and the original site stays up the entire time.
Four pieces sat right on the page as a simple visual, Website URL, Login details, Backup, Database, so I knew upfront what the process would eventually ask for. A line near the bottom set the timing plainly too, usually 30 minutes, but it can run as long as 24 hours.
Next, I clicked Migrate Website in the top corner of that same page to actually start things moving.
Instead of asking about the site I wanted to bring over, a modal opened asking where it should land. A dropdown listed my existing hosting plans alongside an option to get a new one.
I picked one of my existing plans from that list, and the dropdown settled into a single selected option with Cancel and Continue sitting beneath it. Clicking Continue is what actually carried things forward.
That is when the wizard finally asked the question that actually mattered, how I wanted to migrate. Two options sat side by side, Use Login Details, marked Recommended, and Upload Backup Files, each one listing what it actually works with underneath it, a WordPress dashboard sign-in or cPanel credentials for the first, static HTML and CSS sites or WordPress and PHP sites for the second.
I went with Use Login Details, the recommended path, since it skips the two places a manual migration usually goes wrong, an oversized database export, and a small misconfiguration during a manual restore that breaks the site’s connection to its own database.
The Migration, Step by Step
- Enter the site’s address. With the method chosen, the wizard moved to a single field asking for the URL, a progress bar ticking up in the corner as I went.
- Pick WordPress or cPanel access. The wizard asked which kind of login I had before asking for anything else. I chose “WordPress”.
- Hand over the login. I typed the WordPress username and its password straight into the form. What I appreciated here, and what a lot of tools skip, was a plain statement right on that screen that this information was only being used to run the migration, not kept anywhere afterward. Handing over an admin login to a third party is not a small ask, and Hostinger did not pretend it was.
- Let it confirm the login works. A short automated check ran before anything real started moving, just confirming the credentials were valid.
- Review the summary and submit. The last screen before anything committed laid out where the site was coming from, where it was headed, what platform it had picked up on automatically, and a clear line telling me not to touch DNS until the migration finished.
The Migrations page had already set expectations before I got this far, usually 30 minutes, but as long as 24 hours for something larger or more complex.
My original site stayed live and reachable the entire time, since the tool builds a fresh copy on Hostinger’s side rather than pulling the source offline mid-transfer. Once I submitted the request, progress tracked from the same place I started, under Websites, Migrations, no separate dashboard to go hunting for.
What I Think
The part that stood out was not any single screen, it was how little the wizard asked me to already know. No file paths, no database terminology, just a login and a domain.
For anyone who has done a manual migration before, files here, a database export there, a configuration file to edit by hand, skipping all of that for a login screen and a wait is the entire pitch, and it held up.
When the Other Paths Make More Sense
That is the path most people will use, and it worked cleanly. It’s not the only path, though, and knowing when to reach for something else matters just as much as knowing how the recommended one works.
The login-details method is not always the right call, and Hostinger builds in real alternatives rather than forcing everyone through one door.
| Path | Best for | Typical time | What it needs |
| Upload Backup Files | Static HTML sites, or anyone who would rather not share a login | Same range as login details | A file archive of the site plus a database export |
| Non-WordPress via wizard | Sites on other CMS platforms | Around 20 hours on average | A login URL and admin credentials for that platform |
| Fully manual | Wizard-unsupported setups, or full control over every step | Varies, entirely hands-on | Files, a database export, and manual upload and configuration |
A few things about each path go beyond what the table shows.
- On the backup path, get the export right before uploading it. A database over roughly 50 MB will not export reliably through a standard export tool and needs an alternative method instead
- Non-WordPress sites still run through the same wizard, just with a platform selector in place of WordPress-specific fields, so the interface itself does not change even though the timeline does
- The fully manual route only makes sense in a narrower set of cases, a Hostinger product where the wizard is not available, a platform it does not support, or a deliberate choice to control every step rather than hand any of it to an automated tool
For the exact click-by-click on any of these, including the manual export and upload process step by step, our guide to migrating from SiteGround to Hostinger walks the full backup path and the manual rebuild in detail, and the screens look the same regardless of which host you are actually leaving.
Having three real alternatives rather than one rigid path is what makes this feel like a tool built by people who have actually migrated messy real-world sites, not just the clean common case. A wizard that only handled the easy scenario would leave a lot of real websites with nowhere to go.
What Actually Happens to Your Data
None of that, the wizard or the alternate paths, answers the questions that actually matter once real data is involved, a live store’s orders, a certificate, what happens if something breaks halfway through.
Hostinger’s public migration FAQ stays quiet on all three, so I put them to Kodee directly.
1. If You Run a WooCommerce Store
The migration is not limited to the product catalog. Here is what actually transfers, according to Kodee.
- Products, variations, categories, and inventory
- Historical orders and order statuses
- Customer accounts, addresses, and customer metadata
The one real catch, orders or changes made while the migration is actively copying the database may not make it into that snapshot. Schedule the move during quiet hours, and pause new orders if possible, to protect against that gap.
A few things still need separate reconfiguration afterward rather than arriving automatically.
- Payment gateway credentials
- DNS records
- Email accounts
- Cron jobs
- Some external integrations
2. SSL Certificates Do Not Carry Over
Custom SSL certificates are excluded from the migration entirely. Once the site is on Hostinger, the sequence is simple. Point the domain to Hostinger first, then issue a new certificate through hPanel under Websites, SSL, and confirm HTTPS is working with no mixed content warnings before calling the migration finished.
3. A Failed Migration Is Not a Dead End
If something goes wrong, the usual cause is credentials, a blocked security check, or an access issue on the source side. That can be fixed and the request resubmitted, and Hostinger can help troubleshoot a failed attempt directly. Up to five migration requests can run at once, so a retry does not mean starting over from nothing.
4. You Can Preview Before Your Domain Switches
The migration builds a copy on Hostinger’s side that can be checked on a preview URL while the original site stays live and untouched on its current host. Test it before pointing the domain over, since it will not switch automatically on its own.
- Pages and images
- Forms
- Customer logins
- Checkout, if a store is involved
After the Migration Finishes
A completed migration is not the same as a finished one. A few checks catch most of what slips through before you switch DNS for real.
