Skip to main content
SSH migration

Shell access? We will come and get it

Give us shell access to your current server and we do the rest - find the WordPress installation, move the files with rsync, import the database, and rewrite the config on arrival. Nothing to install on the source, and nothing on it changes.

14 days free. No credit card. No commitment.

Nothing to install

No plugin on the source

Same price

On renewal, every year

99.99%

Uptime, last 12 mo

Daily

Backups kept up to 30 days

E

190+

Tasks Ellie handles

How it works

Connect, confirm, and walk away

You supply credentials and pick an installation. Everything after that is ours, and you can watch all of it.

  1. Connect

    Give us the host, the user and one of three ways to authenticate. We open a session and prove it works before anything else happens.

  2. Discover

    We scan the server for WordPress installations and read the version, the plugin list and the database size out of each one.

  3. Choose

    Pick the installation you want from the list, or browse the remote filesystem and point at it yourself.

  4. Transfer

    Files come over with rsync, the database is dumped and imported, and the log streams while it happens.

  5. Live

    We rewrite wp-config, run the URL search-replace, and your site answers on Hostney.

Nothing is queued until the connection is proven

The test opens a real session, finds WordPress and reads the installation before any work is scheduled. It takes about a minute, and it means the usual failures - wrong port, key not installed, no permission on wp-config.php - surface immediately rather than halfway through a transfer.

What you need on the source server

SSH on any portRoot or sudo preferredAn existing WordPress installPassword, key, or ours

Access

Three ways in, and one of them costs you no secret

You are about to give a hosting company access to another company's server. That deserves to be a considered choice rather than a form field, so here is the honest ranking.

  • Our public key

    We show you a public key. You append it to authorized_keys on the source server and tell us when it is there. You never send us a password or a private key, and you revoke our access by deleting one line when you are done. This is the one to use.

  • Your private key

    Paste a key you already have. RSA of at least 2048 bits, ECDSA, or Ed25519 - anything weaker is refused rather than quietly accepted. Best paired with a key made for this job and removed afterwards.

  • A password

    The fallback for hosts that allow nothing else. It works, and it is the method we would least like you to pick. Change the password once the migration is finished.

Revoke our access when you are done

Delete the line from authorized_keys, change the password, or remove the key you issued - whichever applies. Nothing about the migration needs that access once your site is live here, and leaving standing access to a server you are about to stop paying for is how forgotten doors are left open.

Discovery

You do not have to know where anything lives

The most common reason a migration stalls is nobody being sure which directory the live site is actually served from. We look.

  • You do not need to know the path

    Plenty of people inherit a server and have no idea whether the site lives in public_html, htdocs, or somewhere a previous developer invented. We scan for it and list what we find.

  • It reads the install before it moves it

    Discovery pulls back the WordPress version, the plugin list, the table prefix, the database size and the size on disk - so you can confirm you are about to move the right site, and roughly how long it will take.

  • Or browse the server yourself

    If auto-discovery finds several installs, or the one you want is somewhere unusual, there is a remote file browser in the panel. Click through the source filesystem and point at the directory.

  • It refuses a directory that is not WordPress

    A path has to contain both wp-config.php and wp-load.php before we will queue anything against it. Being told "that is not a WordPress install" immediately beats finding out during the transfer.

What discovery reports back

For every installation it finds, before you commit to moving anything:

  • Full path
  • WordPress version
  • Site URL
  • Table prefix
  • Plugin list
  • Database size
  • Files size

The plugin list is the useful one nobody expects: it is where you notice the caching plugin or the security plugin that will need attention on the other side.

The transfer

What the transfer does

Read on your side, write on ours. Nothing on the source server is modified at any point.

On your server

We read your config, we do not guess

The database name, user, host and table prefix are parsed out of your wp-config.php, and the site URL out of the config or the database. This is why root or a sudoers account is worth having - without it we cannot read the file that tells us where the database is.

The database is dumped at the source

A dump is taken on your server, transferred, and imported here. Nothing is streamed row by row over the internet the way the plugin has to.

Files move with rsync

The right tool for the job - it moves what it needs to, preserves permissions and timestamps, and does not care that your uploads directory has forty thousand files in it.

On ours

A clean config, with your keys

We generate a fresh wp-config with the new database credentials, and carry your existing authentication keys and salts into it so logged-in sessions survive the move.

Your original config is kept

The old one is preserved beside the new one as wp-config.migrated.php. Any custom constant you had defined is still there to copy over.

The URLs are rewritten

A search-replace runs across the database from your old address to the new one, so links, image sources and serialized option values all follow.

Before you switch

Check the whole site before you touch a DNS record

The cutover is the frightening part of a migration, so we take it out of the critical path.

The config we generate makes WordPress answer on whichever hostname the request arrived on. Your migrated site is usable on its Hostney address the moment the import finishes - log in, click through the admin, check the theme, place a test order.

When you eventually point the domain at us, the same site keeps working on the real hostname with nothing else to change. No second search-replace, and none of the redirecting-back-to-the-old-domain misery that makes people attempt this at 2am.

And the old server keeps running

We only ever read from it. Your site stays live on your current host with its files and database untouched, so the switch happens when you say it does - and cancelling the old account is a decision you make afterwards, at your own pace.

While it runs

A real status, not a progress bar

Every phase is named, and the log streams underneath it.

  1. Connecting

    Opening the session and authenticating. If this fails you find out in seconds, not after a long wait.

  2. Scanning

    Reading the WordPress installation, its config and its database.

  3. Transferring

    Files coming across. The longest phase, and the log tells you what is moving.

  4. Importing

    Database import, config rewrite, search-replace.

  5. Completed

    Live on Hostney, with the full log kept in your migration history.

  • Streaming logs

    The log appears as it is written, so a slow migration and a stuck one look different. When something fails, the message names the file or the table.

  • Cancel at any point

    Stop a running migration from the panel. Nothing on your source server is affected, because nothing on it was ever changed.

  • Run it again

    Migrate into the same destination a second time to pick up content published since the first run. Useful as a final catch-up right before you move DNS.

Other ways in

No shell access? There are two other routes

SSH is the fastest way in when you have it. Most people on shared hosting do not.

  • The WordPress plugin

    Install one plugin on your current site, paste a token, and we pull the site across through it. No shell, no FTP, no export archive - it was built for exactly the hosts that will not give you a terminal.

  • Have us do it

    Included on every paid plan. Tell us what needs moving and our team runs the migration, checks the result, and tells you when to switch DNS.

Pricing

Simple, transparent pricing

Every plan includes managed WordPress, SSH access, daily backups, and enterprise-grade security. Start with a 14-day free trial.

Startup

Great for growing businesses

$7.99/mo

$94.99 billed annually

  • 1 website
  • 10 GB storage
  • ~10,000 visits/month
  • 5 MySQL databases
  • 250,000 inodes
  • 5 FTP users

What's included:

SSL & Domain

  • Free SSL certificate
  • Free starter domain

Apps & CMS

  • 1-click WordPress
  • Managed WordPress
  • WordPress staging
Most popular

Advanced

For professional websites

$14.99/mo

$179.99 billed annually

  • 5 websites
  • 20 GB storage
  • ~110,000 visits/month
  • 10 MySQL databases
  • 500,000 inodes
  • 10 FTP users

Everything in Startup, plus:

Backups

  • 14 days of backup history

Performance

  • Memcached

Pro

Maximum performance and features

$22.99/mo

$274.99 billed annually

  • 10 websites
  • 40 GB storage
  • ~200,000 visits/month
  • 20 MySQL databases
  • 750,000 inodes
  • 20 FTP users

Everything in Advanced, plus:

Deployment

  • 2 SSR applications

Backups

  • 30 days of backup history

Migration is free

Point us at your server

Add the credentials, let discovery find your site, and start the transfer. Nothing on your current host changes, and nothing moves in public until you point your domain at us.

Questions

Frequently asked questions

What do I need on my current host?
SSH access to the server your WordPress site runs on, and an existing WordPress installation. Root or a sudoers account is strongly preferred, because we read the database credentials out of your wp-config.php - without permission to read that file we cannot find your database. Any SSH port works.
Which authentication method should I use?
Our public key, if your host allows it. We show you a key, you append it to authorized_keys on the source server, and you have sent us no secret at all - no password, no private key of yours. When the migration is done you revoke our access by deleting that one line. Pasting your own private key works too, and a password is the fallback for hosts that allow nothing else.
What should I do with the credentials afterwards?
Remove them. If you added our public key, delete that line from authorized_keys. If you gave us a password, change it. If you pasted a private key, remove the matching public key from the source server. This is ordinary practice for any migration with any provider, and it takes a minute.
Can it migrate something that is not WordPress?
Not today. SSH migration is WordPress-specific end to end - it looks for wp-config.php and wp-load.php, reads your database credentials out of the config, and finishes with a WordPress-aware URL search-replace. For a non-WordPress site, upload the files yourself over SFTP or the file manager and import the database, or ask us to move it for you.
What if there are several WordPress sites on the server?
Discovery lists all the installations it finds and you pick one per migration. You can run two migrations at once per account, and repeat as many times as you need to move a whole server across.
How is this different from the plugin?
Speed and access. Over SSH we dump the database on your server and move files with rsync, which is faster than reading them out through the WordPress REST API in batches, and none of it depends on how your host has configured PHP. The plugin exists for the far more common case where you have no shell access at all.
Does my site go down during the transfer?
No. We read from your server; we do not modify it. Your site keeps serving traffic from your old host until you decide to point DNS at us.
Can I see what it is doing?
Yes. The log streams live while the migration runs, with a real status - connecting, scanning, transferring, importing - rather than a bar that could mean anything. It is kept afterwards, so you can answer questions about a migration weeks later.
What if the connection test fails?
You find out before anything is queued. The test opens a real SSH session, locates WordPress and reads the installation, so the usual causes - wrong port, wrong user, key not installed, no permission on wp-config.php - surface immediately with a message that says which one it was. It takes about a minute.
Is it included in my plan?
Yes. SSH migration, the plugin, and the imports they produce are part of every plan at no extra cost, with no per-site charge.