How to Move WordPress from a Local Server to Live Site in 2026

To move WordPress from a local server to a live site, copy the files, import the database, replace every localhost URL with the live one, then flush permalinks and caches. The fastest route is a single command: instawp migrate push . --name <site-name> --source-url http://<yoursite>.local/ does all four steps for you from your own terminal, with no public URL and no tunnel. This guide covers that method first, then the ZIP import, the manual SFTP transfer and the migration-plugin route, and finishes with the fixes for what usually breaks afterwards.

Why do developers build WordPress sites locally first?

Before we get to how to move WordPress from a local server to a live site, it is worth being clear about why local WordPress development is still the default for so many developers and agencies. Local environments such as LocalWP, XAMPP, MAMP and WAMP remain the default for good reasons.

LOCAL WORDPRESS DEVELOPMENT

Benefits of Local WordPress Development

Standardized Environments

Ensures consistency across team setups.

Cost Savings

Eliminates hosting fees during development.

Version Control

Integrates with Git for code management.

Local WordPress Development

Offline Capability

Allows development without internet access.

Safe Experimentation

Offers a disposable sandbox for testing.

Zero Latency

Provides instant server responses.

The problem is the handover. Everything you gain while building, you pay back at the moment you have to transfer WordPress from localhost to a server. That step is where projects break, and it is what the rest of this guide is about.

What are the ways to move WordPress from a local server to a live site?

Once your website is ready in LocalWP, XAMPP, MAMP or WAMP, the next step is moving it to a live hosting environment. The official WordPress guidance on moving a site covers the same ground at the core level. There are four practical routes: a one-command CLI push, a direct ZIP import, a manual files-and-database transfer, or a migration plugin. The right choice depends on how big the site is, how comfortable you are with the command line, and how much control you want over the database.

InstaWP recommends starting with the CLI push, which is the shortest path and the only one of the four that does not ask you to touch the database. If you are coming from LocalWP specifically, InstaWP also documents how to build locally and then push to InstaWP end to end.

Method 1: How do you push a local WordPress site live with one command?

Run instawp migrate push . --name <site-name> --source-url http://<yoursite>.local/ from your WordPress root. InstaCLI archives the files, exports the database with mysqldump, creates a hosted site in your InstaWP account, uploads both over SSH, restores them and health-checks the result. That is the whole migration, and your local site never has to be reachable from the internet for it to work.

InstaCLI is InstaWP’s official npm command line tool. It replaces the older InstaWP Connect plugin push (wp instawp local push), which has been retired. The plugin is no longer part of this workflow at all, and InstaCLI deliberately excludes instawp-connect, instawp-helper and iwp-migration from the copy, so the site that lands on the server is a faithful copy of your local files rather than a copy carrying migration scaffolding.

The push works from localhost because of the direction the traffic runs. On your own machine InstaCLI archives the WordPress root and dumps the database. It creates the destination site in your InstaWP account through the API, then opens an outbound connection from your computer to that new site and uploads both archives. The server unpacks them and runs the restore. Nothing ever connects in to your machine, which is why a local WordPress site with no public address can still be pushed live.

Step 1: Start the local site and open its shell

Start your local environment and leave it running for the whole migration. InstaCLI reads the live database through mysqldump, so a stopped site means a failed export. In LocalWP, select the site and click Start site, then confirm it loads in a browser.

Now open a terminal at the WordPress root, meaning the folder that holds wp-config.php and wp-content. In LocalWP, Site shell does this for you. On other stacks you change into the folder yourself:

• LocalWP (Windows and macOS): right click the site and choose Open Site Shell. It opens at the site root.
• XAMPP (Windows): open Command Prompt or PowerShell and run cd C:\xampp\htdocs\yoursite.
• XAMPP (macOS): open Terminal and run cd /Applications/XAMPP/htdocs/yoursite.
• WAMP (Windows): open Command Prompt and run cd C:\wamp64\www\yoursite.
• MAMP (macOS): open Terminal and run cd /Applications/MAMP/htdocs/yoursite, or your custom document root if you set one.
• A plain macOS or Linux setup: change into whichever directory holds wp-config.php, for example cd ~/Sites/yoursite or cd /var/www/yoursite.

Run ls (or dir on Windows) and confirm you can see wp-config.php. If you cannot, you are in the wrong folder and the push will refuse to run.

Step 2: Install InstaCLI and sign in

Check the three prerequisites, then install InstaCLI from npm and authenticate. Five commands in total.

node --version
npm --version
mysqldump --version

npm install -g @instawp/cli@beta
instawp --version

If mysqldump --version reports that the command is not found, install the MySQL client tools for your platform before going further. LocalWP ships mysqldump inside its own bundle, so the Site shell usually has it already. InstaCLI is published on the beta channel at the time of writing, which is why the install command pins @beta rather than taking the default tag.

Now authenticate. instawp login opens a browser window where you approve the session, and instawp whoami confirms which account the CLI is holding, which matters if you belong to more than one team.

instawp login
instawp whoami

Step 3: Preview the migration with a dry run

Add --dry-run and InstaCLI validates the WordPress root, the source domain and the new site name, then prints the plan it would execute. Nothing is created and nothing is uploaded. This is the cheapest way to catch a wrong --source-url before it becomes a site full of unrewritten links.

instawp migrate push . --name dummysite-cloud --source-url http://dummysiteforinstawp.local/ --dry-run

Three arguments do the work, and a few optional flags change what the destination looks like:

Step 4: Run the push

Run the same command with --dry-run removed. Leave the terminal open and the local site running until it finishes.

instawp migrate push . --name dummysite-cloud --source-url http://dummysiteforinstawp.local/

InstaCLI works through the migration in order and reports each stage as it goes. It archives the files, exports the database with mysqldump, creates the hosted site, prepares SSH access, uploads both archives, restores them on the server, and health-checks the finished site. How long it takes depends on the file count, the database size and your upload speed. The run ends with Migration complete and prints the Site URL and the WP Admin URL.

Step 5: Log in and check the new site

Open the Site URL from the terminal output. Log in with the same WordPress admin username and password you use locally, because InstaCLI migrates the users table along with everything else. There is no new password to find and no account to recreate.

InstaCLI rewrites your local URLs to the new site address during the restore, including URLs stored inside serialized data, so you do not run a search and replace yourself. Two checks are still worth a minute. Open a page built with a visual builder such as Elementor or Bricks and confirm its images and links resolve, since builders store some settings as serialized objects where a stale URL can survive. Then open any page that uses a custom font or an external script and confirm nothing is still requesting http:// from your old local address.

The push always creates a new site. It never overwrites an existing destination, so running it twice gives you two sites rather than a replaced one. If you want to move changes into a site that already exists, InstaCLI has instawp sync push for wp-content and instawp db push for the database instead.

Method 2: Import a Local Site Using a ZIP File

This method exports the site from your local environment and uploads it through the InstaWP dashboard. It needs no plugin, no terminal command, no SSH and no publicly reachable local URL. Check first that your exported ZIP is inside InstaWP’s current 1 GB upload limit. The walkthrough below uses LocalWP as the example.

Open LocalWP and select the site you want to move. Click Start Site and wait for it to come up. Right-click the site name, or use the three-dot menu beside it, and select Export.

Choose where to save the file and wait for LocalWP to build the archive. It packages the database, media, plugins, themes and the rest of your content into one ZIP. Leave it compressed, because you upload the ZIP itself to InstaWP.

Sign in to your InstaWP account, open the Sites page and click Import Site.

An import modal opens with the available backup sources. Open the drop-down and select Local WP.

That tells InstaWP how the archive was created and how to process it. Click the upload area, select the ZIP you exported from LocalWP, and choose the hosting plan you want the site to run on.

You can also drag and drop the file into the upload area. Wait for the upload to finish and do not close or refresh the tab while it runs. When the file is ready, click Next.

Now enter the details for the imported website. Give it a site name you will recognise in your dashboard, and pick a server location close to the audience or client the site is for. Review any remaining site or plan settings, then click Import Site.

InstaWP restores the files and database into the new cloud environment. The time it takes depends on the archive size and your connection. Keep the dashboard open until the status confirms the site is ready. Installation starts automatically once you submit the import.

When the import finishes:

1. Return to the Sites page.
2. Find the newly imported site.
3. Open the frontend and confirm the website loads.
4. Use Magic Login or the admin login option to get into WordPress.

Keep the original LocalWP site and its exported ZIP until you have finished checking the new one.

When to use this method

ZIP import suits you when you want a dashboard-based workflow and your export sits inside the upload limit. For larger sites, or when uploading a big archive is impractical, push the site with instawp migrate push instead.

Method 3: Manually Migrate a Local WordPress Site to InstaWP

Manual migration gives you direct control over the files, the database and the URL replacement. Use it when you would rather work with SFTP, database exports and WP-CLI than an automated tool.

Step 1: Export the local database

Open the database manager your local environment provides. In phpMyAdmin, select the database your local WordPress site uses and click Export.

Select the Quick export method, choose SQL as the format, and download the .sql file.

You can do the same with WP-CLI:

wp db export local-site-database.sql

Keep the SQL file somewhere safe.

Step 2: Package the local files

Find the root directory of your local WordPress site. It normally contains wp-admin, wp-content, wp-includes, wp-config.php and index.php.

Compress the WordPress files into a ZIP or TAR archive, and leave the local wp-config.php out of it. The destination site already has a configuration file holding the database credentials InstaWP needs. You can also skip files that are no use on the live site, such as wp-content/cache, wp-content/updraft, wp-content/ai1wm-backups, error_log and debug.log.

Step 3: Create the destination site

Sign in to InstaWP and create a new WordPress site. Go to Sites, click Add Site, then choose From Scratch.

Worth reading alongside this: Create Site.

This new site is the destination. InstaWP builds a complete hosted WordPress environment, so there is no database to create by hand through cPanel. Copy the temporary InstaWP URL, because you will use it to replace the local URLs stored in the database.

Step 4: Connect over SFTP and upload the files

In the InstaWP dashboard, click the three-dot menu and select SFTP/SSH.

Turn on the SSH/SFTP toggle and copy the host, username, password and port shown.

The same credentials work for both SFTP and SSH. InstaWP supports clients such as FileZilla and Cyberduck. Open FileZilla, create a new connection, set the protocol to SFTP, enter the host, port, username and password from InstaWP, then click Quick Connect.

Once connected, find the WordPress root directory on the destination server and upload your archive there. Extract it over SSH or with the file manager, overwriting the existing WordPress files where needed.

Step 5: Import the database

You can import the database through InstaWP’s DB Editor, or over SSH with WP-CLI.

Step 6: Replace the local URLs

The imported database still points at your local address. Every reference to http://example.local has to become the InstaWP site URL. Use WP-CLI for this, because it handles serialized WordPress data safely. Unlike Method 1, the manual route does need WP-CLI installed and on your PATH. Preview the replacement first:

wp search-replace 'http://example.local' 'https://your-instawp-site-url' 
  --all-tables-with-prefix 
  --skip-columns=guid 
  --dry-run

Read the results. If they look right, run it for real by dropping --dry-run:

wp search-replace 'http://example.local' 'https://your-instawp-site-url' 
  --all-tables-with-prefix 
  --skip-columns=guid

The WP-CLI search-replace command rewrites serialized PHP data correctly. A plain SQL find-and-replace does not, and it will corrupt the serialized settings stored by themes, widgets, page builders and plugins. Leave the guid column alone as well: WordPress treats it as a permanent identifier, not as the current permalink.

Step 7: Update home and siteurl, then flush

wp option update home 'https://your-instawp-site-url'
wp option update siteurl 'https://your-instawp-site-url'

Confirm both values came back as the destination URL:

wp option get home
wp option get siteurl

Then clear the cache and rebuild the rewrite rules:

wp cache flush
wp rewrite flush

If you would rather do the last step in the admin, go to Settings → Permalinks and click Save Changes without altering the structure. Finish by clearing any caching plugin the migrated site uses.

Method 4: Using Migration Plugins

If the manual route sounds tedious, a WordPress migration plugin automates most of it. Three are worth knowing for a WordPress local to live migration.

1. All-in-One WP Migration

All-in-One WP Migration is the simplest of the three, with over 5 million active installations. It packages the whole site, database, media, plugins and theme into a single .wpress file. You click export on the local site, download the file, and import it on the live server. No technical knowledge required.

The catch is size. The free version caps imports at roughly 512 MB, so a site with a substantial media library will hit that wall and need the premium extension to finish.

2. Duplicator

Duplicator takes a more transparent approach. Instead of a proprietary format it produces a standard ZIP archive of your files plus a standalone installer.php script, so you can inspect exactly what is being moved. The installer wizard walks through database configuration, URL replacement and validation, and it handles serialized data correctly.

It also runs a pre-migration scan that flags incompatible server configurations, oversized files and problematic plugins before you start.

3. Migrate Guru

Migrate Guru runs the migration in the cloud. Rather than downloading files to your computer and re-uploading them, it transfers the site from source to destination through its own infrastructure. That makes it a good fit for large sites, or when your connection cannot handle a multi-gigabyte upload. It supports one-click migration to most major hosts and handles sites up to 200 GB with no local storage needed.

The tradeoff is control. You are trusting the service to handle every step, and you cannot see inside the process the way you can with Duplicator.

The walkthrough below uses Duplicator, because it automates the parts that are easy to get wrong (serialized data, URL replacement, validation) while still showing you what happens at each step.

Step 1: Install and Activate Duplicator

In your local WordPress dashboard, go to Plugins → Add New, search for Duplicator, install the plugin by Snap Creek and activate it.

Step 2: Create a New Package

Go to Duplicator → Packages and click Create New in the top right.

Enter the details for your backup.

Duplicator runs a system scan that checks for large files, server compatibility and problematic plugins. Review any warnings and fix what needs fixing. In most cases you can carry on.

The scan finishes quickly and the backup is ready to build.

Click Build. Duplicator packages the entire WordPress installation, all files and the complete database, into a single archive.

Step 3: Download Your Package Files

When the build completes you have two files to download:

• installer.php, the standalone script that unpacks and configures your site
• archive.zip (or similar), your complete WordPress site in compressed form

Download both to your computer.

Step 4: Upload Files to Your Live Server

Using FileZilla, Cyberduck or your host’s file manager, connect to the live server and open your domain’s root directory, usually public_html or www. Upload both the installer and the archive there. Do not unzip the archive, because the installer does that itself.

Step 5: Create a Database on Your Live Server

The installer needs an empty database waiting for it. Log into your hosting control panel (cPanel, Plesk or similar) and:

1. Create a new MySQL database and note the name.
2. Create a new MySQL user with a strong password.
3. Add that user to the database with all privileges.

Keep those credentials to hand, because the next step asks for them.

Step 6: Run the Installer Wizard

Open https://yourdomain.com/installer.php in your browser. The Duplicator wizard launches and runs in four stages:

Step 7: Clean Up

Once the site works, finish the job:

1. Delete the installer files. Duplicator prompts you to remove installer.php and its related files. Do it straight away, because leaving them in place is a security risk.
2. Regenerate .htaccess. Go to Settings → Permalinks and click Save Changes.
3. Test properly. Check pages, posts, images, forms and any custom functionality.
4. Clear caches. If a caching plugin is running, flush it so visitors get the migrated site.

Duplicator Pro adds scheduled backups, cloud storage integration, multisite support and the ability to install into an existing WordPress installation, which is useful if you run migrations often.

What breaks after you move WordPress live, and how do you fix it?

Most of the problems that appear straight after a migration come back to a URL that was missed or replaced badly. Work through them in this order.

Why are images and internal links broken after migration?

If images fail to load and internal links still point at example.local, the replacement missed rows. WordPress stores URLs across many tables, and plugins add their own, so run the search-replace against every table with your prefix rather than just wp_posts. Check that you matched the exact local URL, including the protocol and any port number such as :10004, which LocalWP often uses.

Permalinks return 404 after migration

The homepage loads but every other URL 404s. That is the rewrite rules, not your content. Go to Settings → Permalinks and click Save Changes without altering the structure, which rebuilds .htaccess. On Nginx there is no .htaccess, so the try_files rule in the server block has to be right instead.

Why do I get a white screen after migrating WordPress?

A blank page almost always means a PHP fatal error that is not being displayed. Set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php and read wp-content/debug.log. The usual culprits are a PHP version gap between local and live, a plugin calling a function the live PHP version removed, or a memory limit that is too low. If the site loads but behaves oddly, our guide on WordPress site not loading covers the wider set of causes.

How to change the WordPress site URL after migrating

If home and siteurl still hold the local address you will get redirect loops or be locked out of wp-admin. Fix them with WP-CLI as shown above, or add these lines temporarily to wp-config.php:

define('WP_HOME','https://yourdomain.com');
define('WP_SITEURL','https://yourdomain.com');

Remove them once the database values are correct, because leaving them in place makes the setting impossible to change from the admin later. If you land on a database error instead, our walkthrough for error establishing a database connection takes it from there.

Where Should the Live Site Actually Go?

The destination decides how much of the work above you have to do at all, so it is worth deciding before you start rather than after.

On traditional shared hosting you create the database yourself, set the PHP version by hand, request an SSL certificate, and fix file permissions after the FTP upload. Those four steps are where most of the failures in the table above come from.

On managed WordPress hosting the environment is built for you. InstaWP provisions the database, the PHP version, the SSL certificate and a working URL when the site is created, which is why Methods 1 and 2 above have no database step at all. You also get SFTP and SSH access, WP-CLI, a database editor, and automatic WordPress backups by plan, so the recovery path exists before you need it.

What does a local-to-live migration actually cost you?

Migration is where WordPress projects break. You can spend weeks building a flawless site on localhost and watch it fall apart in an hour. Experienced developers hit these problems too, so it is worth knowing what you are up against.

Worth reading next: WordPress local development challenges and the alternative.

Database URL problems

The search-and-replace step looks trivial until you meet serialized PHP arrays. WordPress stores URLs inside them, one wrong character invalidates the whole array, and that data sits in theme options, widget settings, page builders and countless plugins. Some plugins store URLs with a trailing slash and some without, and an http reference on an https site produces mixed-content errors.

Environment mismatches

Your localhost runs PHP 8.2 and your host defaults to PHP 7.4, so the plugin that worked perfectly now throws fatal errors. MySQL version differences (strict mode in particular), PHP memory limits, maximum upload sizes and disabled PHP functions cause the same class of surprise.

File permission errors

Files uploaded over FTP often arrive with the wrong permissions. You will see a white screen, “installation failed: could not create directory”, media uploads that fail silently, or plugin and theme installs that will not complete.

Works locally, breaks live

Everything runs perfectly on localhost, then the live site shows missing images, broken internal links, CSS that will not load, 500 errors or redirect loops. Tracking those down can take hours, sometimes days. Add DNS propagation, SSL setup and testing to that, and a redesign launch carries a stretch where the site may be broken for real visitors.

Is there a way to skip the migration entirely?

There is a way to avoid all of this: do not move WordPress from local to live in the first place.

Instead of building locally and then transferring, you develop directly in a cloud environment. All-in-one cloud platforms such as InstaWP create a working WordPress site in seconds with your chosen PHP version, an SSL certificate and a shareable URL. You configure no server, install no XAMPP or MAMP, and open the site from any browser.

Building WordPress on cloud changes four things:

• No migration required. Your development site and your live site are the same kind of environment, so going live is a deployment rather than a migration.
• Consistent environments. The PHP and MySQL versions that run your staging site run production too, which removes the “works on my machine” class of bug.
• Instant sharing. Client feedback needs a link, not a local tunnel or a throwaway server.
• Built-in staging. Clone a site, take a snapshot, roll a change back, none of which touches your machine. If you want to try this before committing, a WordPress sandbox takes seconds to create.

The tradeoff developers expect

When developers hear “cloud-based development” they usually raise the same four objections. They want VS Code with their own extensions. They want Git version control on their theme files. They find editing through the WordPress admin too slow for real work. And they need to work offline sometimes.

Those are fair. Editing code through a dashboard or a web file manager cannot match a proper IDE for search across files, syntax highlighting, linting and keyboard shortcuts. That is the reason InstaWP built Local Mount.

With Local Mount your cloud-hosted InstaWP site appears as a folder on your computer. Open it in Finder or File Explorer and the whole WordPress file structure is there: wp-content, wp-config.php, themes, plugins. Edit a file in VS Code and save it, and the change is live on the cloud site straight away, so there is no upload step to remember and nothing to migrate later.

You keep managed cloud hosting with its consistent environments and shareable URLs, and you keep local file access with your own IDE and tooling. The walkthrough below shows it running on macOS, Windows and Linux.

How does Local Mount let you edit a cloud site locally?

Local Mount uses standard network file sharing to expose your InstaWP site’s filesystem to your operating system. When you enable it, InstaWP gives you a server address, a username and a password. Your computer mounts that as a network drive on Windows or a network volume on macOS and Linux, and from then on the files behave like local ones.

Getting started with Local Mount

The prerequisites are below.

Step 1: Enable Local Mount in InstaWP

Open the Sites page in your InstaWP dashboard and click your site to open its settings.

Select Local Mount in the left panel and switch Enable Mount on, then copy the server address, username and password shown.

Step 2: Connect from Your Computer

On Windows, open File Explorer, go to This PC and click Map Network Drive in the toolbar.

Paste the server address into the Folder field and click Finish, then enter the username and password from InstaWP. Tick “Remember my credentials” if you want to skip that next time. Your site now shows up as a drive letter under This PC.

On macOS, open Finder and choose Go → Connect to Server, or press Command K.

Enter the server address with https:// in front of it.

Click Connect and enter the username and password from InstaWP. Your site appears in the Locations sidebar in Finder.

On Linux, use your file manager’s Connect to Server option, or mount it from the command line:

sshfs username@host:/remote/path /local/mountpoint

Move into the mounted folder and you will find the usual WordPress structure: wp-admin/, wp-content/, wp-includes/ and wp-config.php. Open wp-content/themes/your-theme/ in your IDE and start working. Every save syncs.

How do you manage the live WordPress site with AI after launch?

Launching the site is a one-off task. Updating content, plugins and users afterwards carries on for as long as the site exists.

Once the site is running on InstaWP, InstaMCP makes it MCP-ready with a single toggle. You do not set up a server, write a JSON config file or generate an application password. From there an AI client such as Claude Desktop, Claude Code, Cursor, ChatGPT or VS Code can work on the site through prebuilt tools for posts, pages, media, users, comments, categories and plugins. Our guide to the WordPress MCP server explains how the connection works.

Conclusion

Building locally and then migrating made sense when cloud tooling was limited. It is still the step in the process most likely to fail, and it fails at the point where the site is meant to go in front of real visitors.

If you have to move an existing local build, use Method 1 or Method 2 and work through the troubleshooting table before you point the domain. If you are starting something new, consider building it on the cloud instead, so there is no migration to get wrong.

FAQs