Move your WordPress site into a Slot

This guide explains how to move an existing WordPress site — including one stuck on locked-down shared hosting — onto HostSSH by capturing it as a portable .hssh account image and landing it in a Slot. It covers what you can do today, what is still on the roadmap, and where the seams are.

If you are new to the Slot model, read the Slots concept doc first — this guide assumes you know that a Slot is one movable unit of hosting capacity, and that WordPress is adapter #1: the deliberate first on-ramp onto the platform.

The big picture

WordPress is the headline on-ramp because it is the migration most people dread and most hosts do badly. The intended one-click story is:

1. Install the HostSSH Migrate plugin on your existing WordPress (wherever it lives today — shared hosting, a VPS, another managed host).
2. The plugin captures the whole site into a single portable file: a .hssh account image.
3. That image lands in a free Slot on a HostSSH Rack, with the site URL rewritten for its new home.
4. You cut DNS over to HostSSH, and the site is live in its Slot.

Status — read this before you plan a migration. The capture/restore engine (the plugin) is working today (v0.1, dogfooded on russo.girardmedia.net). The part that automatically places a captured image into a Slot — the scheduler and the "land in a Slot" wiring — is a roadmap slice, not yet shipped. Today you can produce a .hssh and restore it onto a target WordPress install by hand; the in-app "Move to HostSSH → free Slot" button is planned. The sections below mark which is which.

Step 1 — Capture: the HostSSH Migrate plugin

The mover is a WordPress plugin, HostSSH Migrate (the "Russo build"), living in the repo at wordpress-plugin/hostssh-migrate/. It is deliberately agent-less and pure PHP — no shell, no SSH, no WP-CLI required on the target — precisely so it runs on shared hosting where you have nothing but wp-admin (wordpress-plugin/hostssh-migrate/hostssh-migrate.php).

It exposes two surfaces over the same engine:

• wp-admin — Tools → HostSSH Migrate, a capture-and-download / upload-and-restore screen for hosts with no CLI.
• WP-CLI — wp hostssh export|import|info, for hosts that do have a shell.

What a .hssh account image is

A .hssh is a single Zip — the narrowest scope of the same HostSSH image model, one WordPress site captured as an "account" (wordpress-plugin/hostssh-migrate/README.md):

manifest.json   account-scoped manifest (source URL, table prefix, versions, checksums)
database.sql    pure-PHP dump of the site's prefixed tables
wp-content/...   themes, plugins, uploads (regenerable caches excluded)

This is the same "account" granularity described in the platform's account-level backup design: an account is the smallest independently restorable unit — everything needed to run that one site again, captured as one closure.

Capturing the site (today)

On the source WordPress install, with the plugin active:

# capture to a portable image
wp hostssh export --out=/path/site.hssh

# inspect what you captured before moving it
wp hostssh info /path/site.hssh

Or from Tools → HostSSH Migrate in wp-admin, use capture-and-download. Images are written to wp-content/hostssh-backups/, which the plugin protects with a deny-all .htaccess so the backup is never web-served.

Step 2 — Restore into the new home

Why the restore is safe on real-world sites

Naive file-copy migrations break page-builder sites because WordPress stores serialized PHP blobs (options, widgets, Divi layouts) whose byte-length prefixes become invalid the moment you find-and-replace a URL inside them. HostSSH Migrate's URL rewrite is serialized-safe (HSM_Replace): it unserializes → replaces → re-serializes, so those blobs stay valid. It also clears Divi's et-cache so generated CSS regenerates for the new domain — the exact failure mode that breaks a naive copy (wordpress-plugin/hostssh-migrate/README.md).

Restoring (today, manual)

You can restore a captured image onto any target WordPress install — including the one HostSSH provisions for the Slot — in pure PHP:

# restore onto the current install; takes a safety image first, rewrites the URL
wp hostssh import /path/site.hssh --url=https://new-host.example --backup --yes

--backup captures a safety .hssh of the target before it writes, so a restore is reversible. The --url value is the new home's URL and drives the serialized-safe rewrite.

Landing in a Slot (roadmap)

The intended flow is that you don't run wp hostssh import by hand at all — you click Move to HostSSH, and the platform:

• picks a free Slot of the right class (a WordPress site is a mostly-idle, burstable workload — see the capacity model in Slots),
• restores the .hssh into it, and
• rewrites the URL for the Slot's address.

This is the placeWorkload scheduler plus the "WordPress-into-a-Slot" import wiring, which the Slots doc lists explicitly under Next, not Now (docs/product/SLOTS.md). The Slot Board at /slots is read-only today; the drag-to-place and auto-restore interactions are the next slices. Until then, treat Step 2 as an operator-assisted restore onto a provisioned target.

Step 3 — DNS cutover

Once the site is restored and verified on its new address, point your domain at HostSSH. This is a standard DNS change (an A/CNAME flip at your DNS provider), the same final step as any host migration. Capturing into a .hssh is non-destructive to the source, so the original site keeps serving until you cut over — letting you verify first and roll back by simply not changing DNS.

For operator-side cutover mechanics on the Girard Media fleet (Cloudflare records, proxy/TLS), DNS is driven outside this repo; see the platform's broader docs rather than this user guide.

Available today vs planned

Capability	Status
Capture a WordPress site to a portable .hssh (wp-admin or WP-CLI)	Available (plugin v0.1)
Serialized-safe URL rewrite (Divi/page-builder correct)	Available
Manual restore onto a target install (wp hostssh import, with safety backup)	Available
Read-only Slot Board at /slots	Available (seeded; live once the 0002-slots migration applies)
One-click "Move to HostSSH → free Slot" (scheduler + auto-restore)	Planned
Per-Slot metering / billing for the landed site	Planned
Passphrase encryption, peer-key direct transfer, streaming for very large sites	Planned (plugin roadmap)
Wiring into the Go agent's WordPressAdapter	Planned

How this fits the wider transfer model

The plugin is the agent-less path — it deliberately needs nothing on the source but PHP, so it works on hosting you don't control. The platform also has a second, agent-based path for sites you do control: a one-time, scoped peer transfer key that moves a site or server onto the platform without a full local copy or any credential handover, with the source dialing out so it works behind NAT (agent/internal/transfer/transfer.go). The plugin's .hssh and the agent's image model are the same account-image format at different scopes — WordPress is just the narrowest, most common one, which is why it's the first adapter.

Where to go next

• Slots — the capacity, billing, and mobility model
• Account-level backup & restore (design) — what a captured "account" contains and how it's enumerated
• Backups and recovery (user guide)
• Getting started
• For operator runbooks (deploy, migrations, incident response), see the HostSSH operations skill: operations-and-process.

---

Doc written to be created at /Users/girardmedia/Documents/WEB/hostssh/docs/user/wordpress-migration.md. Key grounding files: wordpress-plugin/hostssh-migrate/{README.md,hostssh-migrate.php}, docs/product/SLOTS.md, docs/ACCOUNT-LEVEL-BACKUP.md, agent/internal/transfer/transfer.go. Note: I confirmed there is no WordPressAdapter in the Go agent yet (grep returned nothing), so I kept that strictly in the "Planned" column rather than implying it exists.