Migration tools

WordPress Migration Challenge from SiteGround to My Own Server

Migrating a WordPress site from SiteGround to a self-hosted VM involved FTP and SSH transfers, MySQL dump and import, DNS updates, and Let’s Encrypt setup. This post details how I automated each step - verifying file integrity, syncing databases, cleaning SiteGround plugins, and securing the new server for full WordPress functionality on my own infrastructure.

by Attila Macskasy 3 min read 651 views

For years, my WordPress site ran smoothly on SiteGround: fast, stable, and easy to manage. But as the hosting plan renewal approached, I realized the cost had quietly grown too high for a personal tech blog. So I decided to take on a challenge: migrate the entire site (files, database, and SSL) to my own self-hosted LAMP server running on Proxmox, with automation powered by AI-assisted Bash scripts.

Step 1: Building the Local LAMP Stack

The foundation was an Ubuntu 24.04 VM on my Proxmox host.
We automated the entire setup with a shell script that:

  • Installed Apache, PHP-FPM 8.2, and MariaDB
  • Created a self-signed certificate for early testing
  • Configured the cloudmigration.blog virtual host
  • Tuned PHP settings to match SiteGround’s environment (using phpinfo() as a reference)

A verification script ensured everything — from modules to sockets and firewall — was correctly configured before proceeding.

Step 2: Migrating Files

Initially, I used FTP to pull down all files from /public_html on SiteGround.
That worked — but it was painfully slow.
So we switched gears and used SSH with key-based authentication to compress the entire directory remotely, then transfer it securely via SCP.

To ensure integrity, we compared:

  • File counts
  • Directory trees
  • Byte sizes

When both the FTP and SSH copies matched perfectly, we knew the content was identical.

Step 3: Exporting and Importing the Database

WordPress data lives in MySQL, so the next step was exporting the remote database.
Using SSH, we:

  1. Parsed wp-config.php to extract DB credentials.
  2. Ran a remote mysqldump with gzip compression.
  3. Downloaded and imported it locally into MariaDB.

We didn’t just stop there — a comparison script listed every table and row count between the remote and local databases.
When all 74 tables matched, we could confidently say:
the database migration was perfect.

Step 4: Replacing the SiteGround SSL Certificate

After DNS was moved from SiteGround to GoDaddy, I pointed cloudmigration.blog to my public IP (46.139.14.94) via my MikroTik router’s NAT.

Once HTTP and HTTPS ports were open, a script verified DNS propagation across multiple resolvers (Google, Cloudflare, Quad9).

Then we used Certbot to automatically:

  • Request a Let’s Encrypt certificate
  • Replace the old self-signed cert
  • Update Apache’s virtual host configuration
  • Enable HTTPS redirection

Now the blog loads securely from my own VM with a trusted certificate.

Step 5: Cleanup and Fine-Tuning

A final script handled:

  • Removing SiteGround-specific WordPress plugins
  • Fixing folder permissions (especially wp-content/uploads)
  • Setting recommended Apache and PHP security options

With that, the migration was complete — fully automated, reproducible, and clean.

Step 6: Backup and Recovery

Disaster recovery is often overlooked — but not here.
I built a dedicated backup script that:

  • Exports the WordPress database
  • Archives the entire site directory
  • Stores both with timestamps and checksums under /home/attila/backups

Using these files, I can restore the entire site — from OS-level disaster to a working WordPress — in minutes.

Step 7: The Final Test

To confirm the migration was truly live:

  1. I created a new post — TEST POST FROM VM.
  2. Flushed local DNS and viewed the site from a mobile network (outside my LAN).
  3. The post appeared instantly, served over HTTPS from my home IP.

That was the moment I knew:
cloudmigration.blog was officially running on my own infrastructure.

Lessons Learned

  • Automation saves time and ensures reproducibility.
    Each script was modular — from setup to verification.
  • DNS propagation takes patience.
    It can take hours for global resolvers to catch up.
  • Self-hosting is empowering.
    With a modest VM, I now host a production-ready WordPress site with full control and zero recurring fees.

What’s Next

I plan to publish these scripts as an open-source toolkit — a fully automated “WordPress Migration Lab” anyone can use to move from shared hosting to their own infrastructure.
Future plans include containerizing the setup with Docker Compose and exploring multi-site replication across clouds.