How to Deploy a LocalWP Site to a Host That Is Not WP Engine

You built a site in Local, the client’s hosting is not WP Engine or Flywheel, and now you need to get it live. Local’s one-click push and pull only covers those two hosts, and for everything else its own documentation points you to a migration plugin. This post walks through what you actually have to do, three ways to do it, and the checks that catch the usual mistakes.

What has to move

Whatever tool you use, a WordPress deploy is the same four things:

1. Files: the wp-content folder (themes, plugins, uploads) at minimum.
2. The database: posts, options, users, plugin settings.
3. URLs: every reference to mysite.local has to become the live domain, including inside serialized data (here is why a plain find-and-replace breaks things).
4. Configuration: wp-config.php on the server keeps its own database credentials. Do not overwrite it with the local one.

Option 1: do it by hand

This costs nothing and teaches you what the other options automate.

1. Export the local database, for example with wp db export.
2. Run wp search-replace from the local URL to the live URL on the export, or import first and replace afterwards. WP-CLI handles serialized data; a text editor does not.
3. Upload wp-content over SFTP or rsync. On a first deploy that is simple. On later deploys you must decide what happens to files that exist on the server but not locally, such as client uploads.
4. Import the database on the server, using the host’s tool or SSH.
5. Fix wp-config.php if you copied it, then flush permalinks.

It works, but every step is a place to make a mistake on a live site, and the second deploy is harder than the first.

Option 2: a migration plugin

Plugins such as WP Migrate package the database with the URL replacement done for you and can push it to a remote site. This is the route Local’s documentation suggests for other hosts. It is a good fit for a one-off move. For repeated deploys you are installing a plugin on every site and keeping it updated, and large sites can run into PHP time and memory limits on the server.

Option 3: SiteShift

SiteShift is the app I build for exactly this gap. You connect a host with SSH or SFTP details (for several hosts the integration pages have the exact settings), and then push or pull from the site’s page. Before anything is sent you get a review screen with the file and database changes. The push only adds and overwrites files, it never deletes anything on the server. The remote database is dumped and backed up first, and the local database is exported with the URL replacement applied.
It needs SSH access to the host, which not every plan includes. It is paid (€9/month excluding VAT), runs on macOS with Apple Silicon and on Windows, and it does not import sites from Local directly. The practical route is to put the site on the host once with Option 1 or 2, then clone it into SiteShift over SSH and use push and pull from there.

Checks before you call it done

• PHP version: match the version you developed on. A fatal error after a deploy is often a PHP version difference.
• Permalinks: save the Permalinks screen once so rewrite rules are regenerated.
• Cache: purge it. A stale cache looks exactly like a failed deploy.
• HTTPS: make sure the live site URL is https and that there are no mixed-content warnings.
• Mail: send a real form submission. If DNS changed too, check SPF.
• Search engines: if “Discourage search engines” was ticked while building, untick it on launch.

There is a longer checklist for moving a site between hosts in moving a WordPress site to a new host. And if your client is on WP Engine after all, skip all of this: Local’s built-in connection is free and works well there.