I Let AI Migrate My WordPress Site to Hostinger. It Went Horribly Wrong.

The backup almost killed the migration.

I thought moving a WordPress site to a new host would take an hour. Instead, I spent an entire evening fighting a 460MB backup file, a full disk quota, three failed FTP attempts, a PHP upload limit, broken JavaScript, and a lazy-loading plugin that intercepted dynamically-set image attributes.

The strange part? AI caused some of the wrong turns — and helped me get out of almost all of them.

Here’s what happened.

Why I Was Migrating at All

My site had been on a budget shared host for years. Cheap, functional, increasingly frustrating. When the renewal came up, I asked Claude to run the numbers on switching to Hostinger. The math came out clearly in favour of moving — better specs, lower annual cost over a 24-month plan, and infrastructure that would actually hold up if traffic grew.

So I decided to migrate. With AI as my technical advisor. What could go wrong?

The Accident Report (What Actually Happened)

Before I get into the how-to, here’s the honest version of events — because the failures are the useful part:

Tool	Why I Needed It	What Actually Happened
Hostinger	New hosting platform	Fast upload, clean hPanel, one-click SSL — the smooth part of this whole story
All-in-One WP Migration	Export full site backup	Created a 460MB file that maxed out the old server’s disk quota, blocking all future exports
Hostinger hPanel (PHP settings)	Configure server limits	Default 64MB upload limit silently rejected my 148MB backup; needed manual fix
LiteSpeed Cache	Performance (pre-installed)	Intercepted a dynamically-set image src, breaking the QR code display post-migration
Claude AI	Technical advisor throughout	Diagnosed most failures correctly, but couldn’t predict environment-specific limits in advance

Step 1: Make a Backup (This Is Where It Went Wrong)

Standard advice: back up your site before migrating. I installed All-in-One WP Migration and ran a full export. The plugin is free, installs in two minutes, and wraps your entire WordPress installation — database, plugins, themes, media — into a single .wpress file.

The AI’s plan looked sensible. Three steps. Should have been straightforward.

The export completed. 460MB. Great.

Then I tried to download it.

Pitfall #1: 4 Hours to Download from a Cheap Host

The browser showed an estimated four hours remaining for a 439MB file. This is the moment I understood exactly what I’d been paying for.

158 of 439 MB downloaded. Two previous attempts already cancelled. The bar barely moved.

I cancelled. The AI suggested FTP. The host’s passive mode had data port restrictions that blocked external connections. We tried three different approaches. All failed.

Pitfall #2: The Disk Quota Catch-22 (The Real Problem)

This is the part of the story I think is actually worth reading, because you won’t find it in any migration tutorial.

After the download failed, I tried creating a second backup — smaller this time, without the media library. It failed. Third attempt. Also failed. The terminal finally showed what was actually happening:

errno=122 Disk quota Exceeded — the first 460MB backup had consumed the entire available disk space on the server.

The 460MB backup had silently maxed out my hosting account’s disk quota. No more writes were possible — not to a log file, not to a new export, not to anything.

And here was the catch-22: to free up disk space, I needed to delete the backup. But deleting it meant losing the only full copy of my site. If something went wrong mid-migration with no backup, I’d have nothing to roll back to.

Standard migration tutorials tell you: back up your website.
What they don’t tell you: the backup itself can fill your server and make everything worse.

The fix, once the AI diagnosed it: delete the large backup to free space, then immediately re-export a smaller version without media files. The new file came in at 148MB — manageable, and fast enough to actually download.

Lesson: Before running a full WordPress backup export, check your disk usage in your host’s control panel. If you’re above 60-70% full, the backup file itself may push you over the limit.

Pitfall #3: PHP Upload Limit (The Hidden Wall)

I installed All-in-One WP Migration on the new Hostinger site and tried to import the 148MB file. Failed immediately: “Upload failed — connection lost or timeout.”

The default PHP upload_max_filesize on most WordPress installations is 64MB. My file was 148MB. The fix is straightforward once you know where to look — in Hostinger’s hPanel under PHP settings:

upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 300
memory_limit = 256M

Path: hPanel → Websites → your domain → PHP → PHP Options → update the four values → Save.

After that, the upload actually moved. And Hostinger’s upload speed made the old host look embarrassing:

455 KB/s sustained upload through Hostinger’s file manager. My old host couldn’t serve 155 KB/s on a download.

The Migration Options and Import Process

Hostinger’s migration wizard offers two paths when setting up WordPress:

Option A: enter your old WP admin credentials for automatic migration. Option B: upload a backup file. I used option B.

During import, All-in-One WP Migration asks for your destination URL. Enter it exactly as it appears on your old site — including https://www if that’s what you used — and the plugin handles all database URL replacements automatically.

DNS and SSL

After import: update your DNS A record to point to Hostinger’s IP. While waiting for propagation, install SSL — one click in hPanel, free Lifetime SSL, covers both root domain and www:

Install SSL after DNS propagates — the certificate is issued for both the root domain and www in one go.

Within 30 minutes of changing DNS, the site was live on Hostinger:

Hostinger’s hPanel: database management, weekly automated backups, file manager, LiteSpeed cache, and resource usage all in one place.

Post-Migration Bugs the AI Helped Diagnose

Getting the site live wasn’t the end. Three things needed fixing that I’d never have diagnosed on my own:

Homepage showing QR codes as post thumbnails — posts had no featured images set, so the theme extracted the first image from post content. The AI wrote a small plugin to display a default thumbnail instead.
WordPress encoding breaking JavaScript — WP’s content filter was converting & to & inside a JS block, silently breaking a URL parameter. The fix: use String.fromCharCode(38) to generate the ampersand at runtime.
LiteSpeed lazy-load intercepting a dynamic image — the cache plugin was interfering with a dynamically-set img.src attribute. Fixed by using createElement() to build a fresh image element instead of modifying the existing one.

What This Experience Actually Taught Me About AI

The honest version isn’t “AI migrated my WordPress site.” It’s closer to this:

AI was good at:

Giving the next step when I was stuck
Reading error messages and identifying root causes
Explaining unfamiliar technical concepts in plain language
Writing quick scripts and code fixes on the spot
Verifying whether a proposed fix actually made sense

AI was not good at:

Knowing my server’s actual disk quota in advance
Predicting environment-specific limitations before we hit them
Guaranteeing the first approach would work
Taking any of the actual risk

The most accurate framing I can offer: AI is a troubleshooting partner, not an autopilot. It significantly raised my ability to navigate problems I had no business solving on my own. But it didn’t make the problems disappear — it just meant I wasn’t facing them alone.

My Honest Take on Hostinger (After Less Than 24 Hours)

So far — and I want to be clear this is early — the new hosting environment feels noticeably better. The upload speed, the hPanel layout, the one-click SSL, the automated weekly backups: all of these are meaningful improvements over what I had.

But it’s far too early to make any real verdict. I’ve been on Hostinger for less than a day. I’ll update this post after I’ve actually lived with it for a few months and can speak to uptime, support quality, and whether the speed difference holds under real traffic.

If you’re considering making the switch yourself, here’s my referral link — same price for you, small commission for me, full disclosure: 👉 Hostinger Web Hosting

Quick Checklist: WordPress Migration to Hostinger

Check disk usage on old host — stay below 60% before exporting
Install All-in-One WP Migration → export without media if file is large
Sign up for Hostinger → install fresh WordPress
hPanel → PHP settings → set all upload limits to 256M
Upload backup via hPanel file manager → restore via plugin
Update DNS → wait for propagation → install SSL
Test every plugin and any custom JS or caching behaviour

How much of this article was written by AI? AI helped me diagnose the problems, research solutions, and structure this write-up. The migration itself, every mistake, every screenshot, and every final decision were mine. The failures are real. The fixes are real. The embarrassment is entirely real.