topskills

Guide

How to migrate a website to a new host with an AI agent

Use hostinger-api-mcp-skills and its migrate-to-hosting skill: it takes a WordPress site from a files archive plus a SQL dump, or a static, PHP or Node.js site from its source, stands the copy up on the real domain, and only then moves DNS. It is the only Skill in this catalogue that migrates an existing live site, and the sequence it enforces is the part worth taking away even if you migrate by hand — build the copy, prove it works while the old host is still serving every visitor, and change DNS as the last step rather than the first.

Updated September 30, 2026 · first published September 30, 2026

At a glance

Side by side

What migrate-to-hosting moves, and what it does not
Covered
WordPressFiles archive of the whole root plus a .sql dump, imported and detected
PHPFiles archive, plus a .sql dump when the app has a database
StaticThe files, deployed as an archive
Node.jsFrom source or a Git repository
Cron jobsNot moved — they do not travel with the files, and the skill says so
The old hostUntouched. It keeps serving until DNS changes
DNS at another registrarYou add the verification TXT and the final record; the skill names both

Step by step

How to do it

  1. 1

    Export the site from the old host

    For WordPress that is an archive of the whole WordPress root, including wp-content and wp-config.php, plus a database dump. Over SSH: tar -czf site.tar.gz -C /path/to/site . and mysqldump --single-transaction -u USER -p DBNAME > db.sql. A static site is just the files.

  2. 2

    Record what already works in DNS

    dig +short NS DOMAIN, then A, MX and TXT. Email and verification records have to survive the move, and the only way to preserve them is to know them before anything changes.

  3. 3

    Create the new site on the real domain

    Not on a free subdomain. WordPress keeps its home URL in the database, so the copy has to answer on the same name it will serve on. For a domain still pointing elsewhere this needs an ownership check: the skill returns a TXT record you add at your current DNS provider, alongside the existing ones.

  4. 4

    Import the files and the database

    The WordPress import uploads the archive and the dump together, extracts and imports, then polls until the install is detected as valid. Large sites take several minutes. Imports overwrite the target, so confirm which site you are importing into before each one.

  5. 5

    Prove the copy works before any visitor sees it

    Point only your own machine at the new server with a hosts-file entry and browse the site. This is the step that makes the whole sequence safe: the old host is still serving everyone else, so a broken import costs nothing.

  6. 6

    Move DNS last, then re-check email

    Only once the copy is proven. Carry the MX, SPF and DKIM records across first if you are switching nameservers, then change the record. Re-run dig +short MX DOMAIN afterwards and confirm it still matches what you recorded in step 2.

Why the order matters more than the tooling

Most bad migrations are not import failures. They are a DNS change made before anyone checked the copy, which takes the site down for real visitors while somebody debugs a database import. The sequence this skill enforces — copy, verify privately, then switch — removes that entire failure mode, and it costs nothing but patience.

The hosts-file test in step five is the piece people skip and the piece that makes the rest safe. Pointing one machine at the new server lets you click through the real site on the real domain while the world still sees the old one. If the import is wrong, you find out with an audience of one.

This is also why cron jobs are worth a specific mention. They do not travel with the files, nothing will warn you, and the symptom appears days later as a backup that stopped running or an email that stopped sending.

What no Skill does

There is no general-purpose migration Skill: nothing in this catalogue moves a site from one arbitrary host to another arbitrary host. What exists is a destination-side skill, which works because the destination is the company that wrote it and can therefore create the site, import the archive, install the certificate and read back the result.

The source side stays manual. You export from the old host yourself, through its panel or over SSH, and you add the verification record at whatever DNS provider you are using today. That is the same credential boundary that limits every other skill in this cluster — a skill can only reach the API of the company that published it.

FAQ

Common questions

Can an agent migrate my site without taking it offline?

Yes, and that is the design rather than a happy accident. The copy is built on the real domain while the old host keeps serving every visitor, tested through a hosts-file entry that affects only your machine, and DNS changes last. Downtime is whatever the DNS TTL is, not the length of the migration.

Will my email break when I move hosts?

It will if you switch nameservers without copying the MX, SPF and DKIM records across first — that is the single most common casualty of a host move. Record them with dig before you start, carry them into the new zone, and verify MX again afterwards.

Does anything migrate between two hosts that are not Hostinger?

Not in this catalogue. Migration skills are written by the destination, because that is the side with an API to create the site and import into it. For any other destination the export and the import are both yours to run; the sequence in this guide still applies.

What gets left behind?

Cron jobs, which the skill calls out explicitly. Also anything living outside the site root or the database — server-level config, mail queues, and certificates, which are reissued on the new host rather than moved.

Related

Keep reading