Migrating Your WordPress Site from WP Engine to Local WP (Step-by-Step Guide)

By /

Moving a site from a managed host like WP Engine to your local machine can seem daunting at first. But whether you’re motivated by recent changes in the WordPress ecosystem (many WP Engine users felt uneasy after Automattic’s moves toward a potential takeover​therepository.email) or simply want more control via version control, it is possible – and even straightforward – to set up a smooth development workflow on your own terms. In this comprehensive guide, we’ll walk through how to take a WordPress site backup from WP Engine and import it into Local WP on macOS and Windows, then set up GitHub for version control, and establish a reliable sandbox → staging → production workflow. By the end, you’ll have your site running locally, your theme code in GitHub, and a clear path to develop confidently outside of WP Engine’s platform.

What We’ll Cover:

  • Exporting your site from WP Engine – downloading and preparing the backup ZIP.
  • Installing Local WP (on both macOS and Windows) – the local WordPress environment by WP Engine (formerly “Local by Flywheel”).
  • Importing the WP Engine backup into Local – step-by-step, with tips for a smooth import.
  • Running your site in Local – accessing the local site and verifying everything works.
  • Setting up GitHub version control (with GitHub Desktop) – putting your theme’s code into a Git repository without using the command line.
  • Organizing your dev workflow – using a sandbox (local) for development, a staging site for testing, and production for deployment, all while maintaining version control.
  • Best practices & tips for maintaining this workflow going forward.

Let’s dive in!

1. Exporting a Backup from WP Engine

The first step is to get a complete backup of your WordPress site from WP Engine. WP Engine provides an easy way to generate and download a full site backup as a ZIP file, which contains your entire WordPress installation (files and database). We’ll use that for the migration.

Step 1: Generate a fresh backup (optional). Log in to your WP Engine User Portal and navigate to your site’s Backups section. If you want the latest changes, create a new backup checkpoint. (On WP Engine, backups are automatic daily, but you can trigger one manually for safety.)

Step 2: Prepare the backup ZIP. In the Backups list, find the backup you want (usually the most recent). Click the three-dot “more actions” menu next to it and choose “Download ZIP” or “Prepare ZIP”. Select Full Backup (all files + database) when prompted​wpengine.com. This ensures the ZIP will include everything – your wp-content (themes, plugins, uploads), the database, and core WordPress files.

Step 3: Download the backup file. WP Engine will take a moment to compile the archive. Once ready, click Download ZIP and save the file to your computer (you might receive an email when it’s ready). The file will be named after your environment (for example, my-site-production.zip or similar).

  • Tip: Rename the downloaded ZIP file to something simple, like mysite.zip, for clarity. Local WP will use this name as the site name during import​wpengine.com. Avoid spaces or special characters to prevent any issues.

Step 4: Inspect the backup (optional). You don’t usually need to extract the ZIP yet – Local WP can import it directly. However, for peace of mind, you can double-click it (or use a ZIP tool) to peek inside:

  • You should see your WordPress files (perhaps in a folder). Common contents are the wp-content folder (with themes, plugins, etc.), possibly wp-config.php, and a database file (often located at wp-content/mysql.sql on WP Engine backups).
  • This confirms you have a full backup. If anything is missing (like no .sql database file), double-check you selected a full backup with the database included.

Why a Full Backup? WP Engine also offers partial backups (just the database or specific folders). But for migrating off the platform, a full backup is recommended so you have all site files and data​wpengine.com. We’ll let Local WP import everything and set up the site identically on your machine.

Now that we have the backup ZIP, we’re ready to set up Local WP and import the site into it.

2. Installing Local WP on Your Computer (macOS & Windows)

Local WP (formerly “Local by Flywheel”) is a free desktop application that makes it super easy to run WordPress sites on your own computer. It creates a local web server, MySQL database, and WordPress install with just a few clicks – no need to manually set up XAMPP/MAMP, etc. We’ll install Local WP on your system and get it ready to import your site.

Installing Local WP on macOS

  1. Download Local WP for Mac: Visit the Local WP website and download the macOS installer (.dmg file). The download is fairly large (since it includes everything needed to run WordPress).
  2. Run the Installer: Open the downloaded .dmg file. You’ll see the Local icon and an Applications folder icon. Drag the Local icon into Applications to install it (just like any typical Mac app). Installing Local on macOS is as simple as dragging the app to your Applications folder. The .dmg installer will guide you with an arrow as shown above.
  3. Launch Local: In your Applications, find Local and launch it. On first run, you may get a security prompt (“Local is an app downloaded from the internet…”); click Open to proceed. Local might also ask for certain permissions (such as modifying your /etc/hosts file for creating local domain names); enter your Mac user password if prompted.
  4. Initial Setup: Local doesn’t require any complex configuration. It may check for required components on first launch. (Older versions of Local used VirtualBox for virtualization, but modern versions use native virtualization, so you shouldn’t need to install anything else manually.) If all is well, you’ll see the Local main window with a “Local Sites” list (likely empty for now) and a big plus (+) button to add a site.

That’s it for Mac! Now, let’s do Windows.

Installing Local WP on Windows

  1. Download Local WP for Windows: Go to the Local WP site and download the Windows installer (it will be an .exe file).
  2. Run the Installer: Locate the downloaded .exe (e.g., in your Downloads folder) and double-click it. If Windows shows a SmartScreen prompt (“Do you want to run this file?”), confirm that you want to run the installer. https://localwp.com/help-docs/getting-started/installing-local/ Running the Local installer on Windows. You may be asked whether to install for all users or just yourself – choose what fits your situation (installing for just your Windows user is fine). Then proceed with the Next buttons.
  3. Follow the Setup Wizard: The Local Setup wizard will guide you through installation. It’s a standard process – agree to the terms, choose an install location (the default is usually fine), and click Install. It should only take a minute to install Local on Windows.
  4. Allow Firewall Access: The first time you launch Local on Windows (and sometimes when creating your first site), Windows Defender Firewall will pop up multiple “Windows Security Alert” dialogs for various services (Local’s router, Nginx, Mailhog, etc.). Click “Allow Access” on each popup​. These are needed so that Local’s components can communicate on your machine (e.g., to create a local server). Don’t worry if you see several in a row – allow all. Windows Firewall prompts when starting Local for the first time. Click “Allow access” for Local’s components (Local by Flywheel, nginx, Mailhog, etc.) on private networks. This lets your local WordPress site run properly on your PC.
    • Tip: If you accidentally clicked “Cancel” on any of these, Local might not function fully (your site might not be reachable). In that case, you can manually adjust the firewall: go to Windows Defender Firewall > Allowed Apps and ensure Local and its components are allowed, or simply restart Local to see the prompts again.
  5. Launch Local: After installation, Local might start automatically. If not, find “Local” in your Start menu and launch it. You should see the Local main interface similar to the Mac description above. On first run, Windows might also prompt you to enable Hyper-V or other virtualization (for Local’s internals) – follow any prompts to enable those if asked, then reboot if necessary. (Most modern Windows 10/11 setups support this out of the box.)

At this point, whether on Mac or Windows, Local WP is installed and running. 🎉 You’re ready to import your WP Engine site into Local!

3. Importing Your WP Engine Backup into Local WP

Local makes importing an existing site incredibly easy – you literally give it the ZIP file and it handles setting up WordPress, the database, and updating configuration for you. There are two ways to start an import: using the menu or just drag-and-drop. We’ll cover the menu method (and mention drag-and-drop).

Step 1: Open the Import Site dialog. In the Local app, go to the top menu and choose File → Import Site. (On Windows, this is under the “File” menu; on Mac, under “Local” menu or File – depending on version.) A dialog will appear asking you to select your import file.

Drag-and-Drop Alternative: You can simply drag your mysite.zip backup file and drop it onto the Local window (anywhere in the sites list area) to initiate the import process​. This is a shortcut to skip opening the menu – Local will react the same way and prompt you for next steps.

Step 2: Select the backup ZIP file. Browse to where you saved the WP Engine backup (e.g., your Downloads folder) and select the .zip file. Local will recognize the archive and start the import workflow.

Step 3: Name your site in Local. Local will ask for a site name. By default, it uses the ZIP filename or an internal name from WP Engine if available. You can change this to whatever you like (perhaps your project or client name). No spaces is a good idea (Local will convert them to dashes for the local domain). For example, “mysite” or “mysite-local” is fine. This name will also form the local domain (e.g. mysite.local).

Step 4: Choose an environment (Preferred vs Custom). Next, Local will ask you to choose an environment configuration:

  • Preferred – This is Local’s default recommended setup (typically Nginx, PHP 8.x, MySQL 8.x, etc., as of this writing). It’s a good choice for most cases and ensures good performance and compatibility.
  • Custom – Choose this if you need specific versions of PHP, MySQL, or web server to match your production environment exactly. For instance, if your site requires PHP 7.4 or your new host uses Apache and you want to mirror that, you can set those here.

For beginners, we suggest using Preferred. You can always adjust environment settings later if needed. (Local even attempts to match the environment from WP Engine if it can – e.g., PHP version – but Preferred is usually fine)​. Go ahead and select Preferred and click Continue.

Tooltip: If you know your WP Engine site was on an older PHP or MySQL, using Custom to match those versions can help avoid any surprises. But since WP Engine keeps things fairly updated, Preferred often already equals or exceeds those versions.

Step 5: Import and wait. Click Import Site to begin. Local will now unpack the ZIP, copy the files into a new local site folder, set up the database, and configure WordPress. This can take a few minutes especially if your site is large (it has to import your uploads, etc.). You’ll see a progress bar in Local.

  • Behind the scenes, Local is creating a folder for your site (usually under your user’s home directory, in ~/Local Sites/ on Mac or C:\Users\<Name>\Local Sites\ on Windows), putting all the WordPress files there, and loading the database file into its local MySQL. It also updates the database to use the new local domain (replacing the old WP Engine domain) so that URLs will work locally.

Step 6: Done! Test the imported site. Once the import finishes, Local will notify you. You should now see your site listed in the Local app (with the name you gave it). Make sure it’s started (Local might auto-start it after import, indicated by a green dot or “Running” status). If not, click the “Start Site” button (usually a play icon ▶️).

Now click “Open Site” or “View Site” in Local (usually in the top right, or you can click the site’s local domain URL). This should launch your web browser to your new local site! 🎉 Verify that the site loads and pages look correct. You can also click “Admin” in Local to go directly to the WordPress Dashboard (wp-admin) – use the same username/password you used on WP Engine (those were carried over in the database).

  • Note: The domain will likely be something like http://mysite.local/. Local automatically adds this to your system’s hosts file so that “mysite.local” points to your computer. If for some reason the site isn’t loading:
    • Try using the “Open Site” button in Local to ensure the URL is correct.
    • If you see a browser error that it can’t find the host, it could be a hosts file issue – on Windows you might need to run Local as Administrator so it can update your hosts file. On Mac, you might be prompted for your password when starting the site – say yes, as that updates hosts.
    • You can also open Site Settings in Local and switch the “Router Mode” to “Localhost” (which uses a localhost port instead of a fancy domain, avoiding hosts file needs). This is a fallback if domain resolution is an issue.
  • Note: If your site had HTTPS enforced, you might need to enable SSL in Local. Local allows you to create a trusted certificate: go to the SSL tab for your site in Local and click “Trust”. This will add the self-signed cert to your system so you can view the site over https:// without browser warnings. Otherwise, you can just use the http:// version locally.

Troubleshooting Import Issues: In most cases, the above steps work smoothly. If the import fails or you get an error, consider these tips:

  • Verify the ZIP content: Local expects a wp-content folder and a database SQL file inside the zip​community.localwp.com. WP Engine’s full backup should have those. If your ZIP had extra nested directories (e.g., a top-level folder containing the site files), try extracting the zip and rezipping just the wp-content folder and the SQL file together, then import that new zip. Extra files (like server logs, etc.) can sometimes confuse the importer.
  • Large Site issues: If your site is huge, the import might time out. Ensure you have enough disk space. You might import the database manually via Local’s Database tab (which provides Adminer or PHPMyAdmin) if needed.
  • WP Engine MU-Plugins: WP Engine adds some must-use plugins (in wp-content/mu-plugins). These might not be needed locally and occasionally can throw errors outside WP Engine. It’s usually fine to leave them, but if you see errors, you can temporarily rename the mu-plugins folder in your local site to deactivate those.
  • Still stuck? Local’s community forums are a great resource. But don’t worry – for the majority of cases, drag-and-drop import works out-of-the-box​deliciousbrains.com.

At this stage, you have a fully functioning local copy of your WordPress site. You’ve effectively “moved off WP Engine” into a self-controlled environment on your computer. Next, we’ll set up version control for your code, which is key to a maintainable workflow.

4. Running and Testing Your Site in Local

Before configuring Git, let’s quickly ensure the local site is working as expected and review how to interact with it:

  • Access the Site: Use the View Site button in Local or open your browser at the local domain (e.g., http://mysite.local). Click around on the pages. Because this is an exact copy of your WP Engine site (just at a new domain and environment), everything should work. Some dynamic aspects (like contact forms sending email) might not function on your local — that’s normal (Local intercepts emails via Mailhog). Focus on layout, content, and basic functionality.
  • Log in to WP Admin: Click Admin in Local (or go to http://mysite.local/wp-admin). Enter the same admin username and password you used on WP Engine. All your users and settings were retained from the database. Once inside, you can confirm things like plugins are present, theme is active, etc. It’s a good idea to put the site in offline mode or privacy mode (Settings → Reading → “Discourage search engines”) even though it’s local, just as a reminder that this is not a live site.
  • Check Permalinks: Sometimes after a migration, you might need to re-save permalinks. If pages other than the homepage aren’t loading (e.g., 404 errors), go to Settings → Permalinks and just click Save Changes to flush rewrite rules.
  • Performance vs WP Engine: The site runs on your computer now, so performance depends on your machine. It might even be faster for admin tasks since no network latency. Don’t be alarmed if it’s a bit slower or faster; this is mainly for development and testing, not serving real traffic.

Now you have a sandbox where you can safely play with your site. Next, we’ll integrate GitHub version control for your code (especially your theme) so you can track changes and collaborate easily.

5. Setting Up GitHub Version Control for Your Theme (Using GitHub Desktop)

One major benefit of moving off a managed host is that you can now fully manage your code using version control. Git is the de facto standard for version control, and GitHub is a popular cloud service for hosting Git repositories. Don’t worry if you’re new to Git; we’ll use GitHub Desktop, a friendly GUI tool, to avoid command-line complexity.

Why use Git? By putting your theme (and any custom code) into a Git repository, you gain a history of changes, the ability to rollback if something breaks, and a workflow to push updates to staging/production in a controlled way​wpengine.com. It’s like an insurance policy for your code, and it enables collaboration if you have teammates. GitHub will host your code repository in the cloud (you can choose to keep it private or open-source).

Step 5.1: Install GitHub Desktop and Sign In

  1. Download GitHub Desktop: Go to the official site desktop.github.com and download the installer for your OS (Mac or Windows are supported; the interface is nearly identical on both). Install it by dragging to Applications (Mac) or running the setup .exe (Windows).
  2. Launch and Sign In: Open GitHub Desktop. It will prompt you to sign in to GitHub. If you have a GitHub account, enter your credentials. If not, you can quickly create a free account on GitHub.com. (You can use free private repositories for your site if you prefer not to share code publicly.) This sign-in lets GitHub Desktop link to your online GitHub account for publishing repositories.
  3. If it’s your first time, you might see a “Let’s Get Started” screen with options (clone a repo, create a new one, etc.). We’ll be creating a new repository from our existing code.

Step 5.2: Initialize a Git Repo for Your Theme

We want to create a Git repository that tracks our theme code. The theme is where most customizations typically live (and perhaps custom plugins if you have any – you can version control those similarly). WP Engine sites often didn’t use Git, so currently your theme folder is not a repo. We will initialize one.

There are a couple ways to do this with GitHub Desktop, and we’ll use the drag-and-drop method for simplicity (no commands needed):

  1. Locate your theme folder on disk. In Local, click on your site, then click the “Go to Site Folder” or “Open site folder” button (usually an icon of a folder). This will open the folder where your site’s files live on your computer. Navigate to app/public/wp-content/themes/. Inside, you’ll see your theme’s folder (for example, if your theme is called “CustomTheme”, there will be a folder named customtheme).
  2. Drag the theme folder into GitHub Desktop. With GitHub Desktop open, drag the theme folder from your file explorer (Finder on Mac, Explorer on Windows) onto the GitHub Desktop window. GitHub Desktop will detect you dragged a folder with no Git repository and will offer to create a repository for it​wpengine.com.
  3. Confirm repository details: A dialog will appear asking for the Name of the repository, the Local Path, etc. The name should auto-fill with your theme folder’s name. Make sure the local path is pointing to the parent directory of your theme (it usually does this automatically when you drag-drop). Essentially, it should indicate it will create (or rather, initialize) the repo in the existing folder. You can add a Description if you like (optional, e.g. “WordPress theme for MySite”). For Repository Type, you can keep it as Git (default).
  4. Add a .gitignore (optional but recommended): In that dialog, there’s usually an option to add a .gitignore template. A .gitignore tells Git which files to ignore (not track). Since this repo is mainly for your theme code, you might not have many extra files. However, if your theme has node modules or build files, or if you just want to be safe, choose a Git ignore template for WordPress or Node depending on your case. (If unsure, selecting “WordPress” or “Node” from the dropdown is a good start – it will, for example, ignore OS junk files like .DS_Store, and perhaps ignore node_modules.) If there’s no built-in template option in the drag-drop flow, you can manually add a .gitignore later. This step is not critical for basic use, but it’s good practice to keep your repo clean.
  5. Create the Repository: Click “Create Repository”. GitHub Desktop will initialize the Git repository in that theme folder and automatically do an initial commit of the files. You should see your theme files now listed in GitHub Desktop’s interface, likely marked as new changes ready to commit (if it didn’t auto-commit).
  6. Initial Commit: On the left side of GitHub Desktop, you’ll see the list of files. At the bottom, there’s a Summary field for a commit message. Type something like “Initial commit of theme”. Then click “Commit to main” (or it might say “Commit to master” if you haven’t changed the default branch name; newer GitHub uses main as the default). This creates the first commit with all your current theme code. Great!
    • Note: We are only tracking the theme folder. This keeps the repository lean and focused​wpengine.com​wpengine.com. We’re not version-controlling WordPress core or most plugins – those can be reinstalled or managed separately. By tracking just our custom code (theme and maybe custom plugins), we avoid clutter and conflicts. This is a common approach: as WP Engine themselves advocate, keep the Git repo focused on the code you or your team write, not the whole CMS​localwp.com.

Step 5.3: Publish the Repository to GitHub

Right now, the Git repository is only local (on your computer). The power of GitHub is to have a remote copy of this repo on github.com, which serves as an offsite backup and allows collaboration. Let’s publish it to GitHub:

  1. In GitHub Desktop, there should be a button on the top bar that says “Publish repository”. Click that. (It might prompt you to login or authorize if you haven’t already – but we did in Step 5.1.)
  2. A dialog will ask for details before publishing:
    • Name: It will use the repo name (e.g. “customtheme”). You can change the name for GitHub if you want, but it’s often fine to keep it the same.
    • Description: You can add something like “Theme for XYZ website”.
    • Privacy: Choose Private unless you’re okay with making your theme code public. Private means only you (and people you invite) can see the code on GitHub. Since this is your site’s code, you likely want it private.
    • Ensure the Owner is your GitHub account (or an organization if you’re using one).
  3. Click Publish Repository. GitHub Desktop will now create a new repo on your GitHub account and push the local commit up to it​wpengine.com. After a moment, it should succeed, and you’ll have an online copy of the repo.
  4. Verify on GitHub (optional): Go to github.com and navigate to your profile or repos – you should see the new repository listed. Inside it, you’ll see your theme files. Congrats, your theme is now version-controlled!

From now on, any time you make changes to the theme files on your computer, GitHub Desktop will show those changes. You can commit them with a message (e.g. “Add new header image to homepage”) and press Push to upload those commits to GitHub. This way, your changes are tracked and backed up. You can always look at the commit history to see what was changed when.

GitHub Desktop recap: We effectively did: initialize repo → commit → publish, entirely through the GUI. No command line needed​localwp.com​wpengine.com. Whenever you want to update the GitHub repo, just open GitHub Desktop, make sure the correct repository is selected (it should list your theme repo now), and commit/push changes. It’s good practice to commit often with clear messages (e.g., “Update styling for mobile menu”).

6. Organizing Your Development Workflow: Sandbox → Staging → Production

Now you have: a local sandbox (your site running in Local WP) and your theme code tracked in GitHub. The final piece is planning how to use these tools effectively moving forward, especially if you want to maintain a workflow similar to WP Engine’s Dev-Staging-Prod pipeline. The idea is to avoid cowboy-coding on the live site and instead promote changes methodically from dev to live.

Let’s define the environments in this new setup:

  • Sandbox (Local Development): This is your Local WP environment – essentially your personal dev playground. Here you can experiment freely: install new plugins to test, edit theme code, update WordPress, etc., without any fear of affecting the live site. It’s offline and isolated. In our case, the sandbox is the site we just imported into Local.
  • Staging (Testing Server): A staging environment is a clone of your site on a server, used for final testing of changes in an environment that’s as close to production as possible. Typically, this is online (so that others like clients or team members can also access it for review), but it’s not public to regular visitors. You might protect it with a password and it usually lives on a separate URL (like staging.yourdomain.com or a temporary address). On WP Engine, you had a staging site – outside WP Engine, you can set one up on your new hosting or any server that can run WordPress.
  • Production (Live Site): This is your actual live website accessible to users at your domain (e.g. yourdomain.com). It should only receive thoroughly tested, stable code and content. Any changes here should be minimal (like emergency fixes), because ideally you’ve tested everything on staging first.

Now, how to maintain these:

Using the Sandbox (Local) for Development

  • Do all development work in Local. For example, if you want to redesign the homepage, you’d edit the theme files on your local site. Because your theme is version-controlled, you can make incremental commits as you try things out. Test the changes locally – click around, maybe even generate some test content. This is your safe space. If something breaks, no users are affected.
  • Keep GitHub updated: As you achieve milestones or fix bugs, commit them in Git and push. This creates a nice log of what you’ve done. For instance, “Fix footer layout on mobile” can be a commit. If you totally mess up, you can revert to a previous commit easily. Commit early and often (you can always squash or refine history later if needed).
  • Use branches for big features (optional): If you’re comfortable, you can use Git branches in your workflow. For example, you might have a main branch that reflects production-ready code, and a dev branch for ongoing work. You’d do your commits on dev (in your local), and once ready to deploy, merge those to main. This is more of an advanced Git strategy but it’s something to consider as you grow. In any case, the sandbox is where branches and experiments live – don’t code on the live server.

Setting Up a Staging Environment for Testing

With WP Engine, you had a convenient staging site. Outside of WP Engine, you can create your own staging. There are a few options:

  • Use your new host’s staging feature: If you moved to a host that offers 1-click staging sites (many managed WordPress hosts do), use that. Typically, you can push your production site to a staging copy. You would then update the staging with new code when ready.
  • Manual staging site: If no built-in staging, set up a subdomain (like staging.yourdomain.com) or even a subdirectory, and install WordPress there as a clone of your live site. You can periodically copy the live database and files to this staging site, or vice versa. Basically, it’s another WordPress instance you manage. Protect it with a simple password (many use a plugin or basic auth) so search engines or users don’t stumble in.
  • Local as pseudo-staging: In a pinch, you could treat your Local site as both dev and staging by being very rigorous in testing. But it’s better to have a staging on a server, because it will mimic production environment (same PHP version, same server type, etc.) more closely. Also, others can see it.

Deploying to Staging: So how do you get your changes from local (sandbox) to staging? Here’s where your GitHub repository shines:

  • One approach: Pull code from GitHub to staging. If you have access to the staging server (FTP, SSH), you can either clone the repo or download a ZIP of it. For instance, you could SSH into the staging server and do git clone of your repo into the wp-content/themes folder. If command line isn’t your thing, an alternative: go to your repo on GitHub, click “Code → Download ZIP”, get the latest code, and upload it via SFTP to the staging site’s theme directory (overwriting the old theme files). This ensures the staging site now has the same code as your local dev.
  • Another approach: If you used a separate branch for staging, you could integrate an automation (CI) to deploy that branch to the staging site. But that’s a more advanced continuous deployment setup (using tools like GitHub Actions) – optional if you grow into it.
  • Simpler: Some hosts allow connecting to GitHub and auto-deploying when you push to a certain branch. You can check if your new host supports that (WP Engine had its Git deployment in certain plans; others like Netlify, Vercel do for static, etc. – but for WordPress, often it’s manual or via plugins).

For a beginner-friendly route, manual upload or git pull on the server is fine for deploying code. The key is to avoid making code changes directly on staging; use it just to receive changes from your dev workflow.

Once the new code is on staging, test the site thoroughly:

  • Click through all pages, test forms, check if any plugin needs reconfiguration due to environment change, etc.
  • If the database schema or content needed changes (like you added a new plugin that requires DB updates), you might have to also apply those on staging. Sometimes just deploying code isn’t enough if you need new content; you might import the latest DB or configure content on staging as needed.
  • Make sure things like caching or performance settings on staging are akin to production for realistic testing.

Think of staging as your rehearsal – it should closely mimic production, using the same PHP version, similar database, and data. If something breaks in staging, you’ve saved yourself from it happening on the live site.

Deploying to Production (Going Live)

Finally, when you’re confident in staging, it’s time to deploy to production (the live site). This usually means updating the live site’s theme (and any other code changes) to match what you tested.

  • Backup production first: Before making changes, always have a current backup of your live site (most hosts do nightly backups; you can also use a plugin like UpdraftPlus or WP Engine’s backup if you still have it enabled). You likely won’t need it, but it’s a safety net.
  • Deploy code: Similar to staging, you can deploy via Git or manual upload. For example, you could git push to a main branch that your production listens to (if set up), or just manually upload the theme files updated. If you have shell access to the server, you might do a git pull in the theme folder to grab the latest commits from GitHub. Many small teams simply use SFTP: they keep a local copy (your GitHub repo clone is your local copy) and upload the changed files to the server. Using an SFTP client or your host’s file manager works – just be careful to upload only the theme (or relevant plugin) files, not the entire WordPress, to avoid overwriting content or configs.
  • Database changes: If your changes involved database content updates (like new pages or settings), you’ll have to replicate those on production. Some changes (like plugin settings) might be in the DB, so consider documenting what needs to be redone on production. In some workflows, you’d push the entire staging DB to production when going live, but that’s risky if production had new orders or comments in the meantime. Often, code deployments don’t involve replacing the whole DB – you just make sure any needed changes are done manually on prod (or via a migration script if complex).
  • Test live site: After deployment, quickly run through the site live. Check critical functionality – forms, checkout (if e-commerce), etc. Since you tested on staging, this is more of a sanity check. If something went wrong, you can quickly revert: either by restoring the backup or by fixing the issue and redeploying. With your code in Git, if you realize a commit caused a problem, you can revert that commit locally and push again to fix.

Congratulations – you’ve now taken a change from Sandbox → Staging → Production! This mirrors the WP Engine workflow (Development → Staging → Live) but now you control the process. You might even find it more flexible: you can use any tools you like in development, and you’re not tied to WP Engine’s interface or limitations.

7. Tips for Maintaining Your Workflow Going Forward

To ensure long-term success with this workflow, keep these best practices in mind:

  • Make frequent backups – Even outside WP Engine, make sure your production site has regular backups (most hosts offer this, or use plugins). Also consider backing up your local environment or at least the database if you do significant work (Local has an Export feature to zip a site​wpengine.com). And of course, your Git repository is a backup of your theme code.
  • Sync content periodically – If your site’s content (posts, WooCommerce orders, etc.) is constantly changing, you’ll occasionally want to refresh your local and staging with recent data. You can export the prod database and import into local to update your sandbox’s content, for example. This helps you test with real data. Tools like WP Migrate (formerly “WP Migrate DB Pro”, now owned by WP Engine) can make pushing/pulling databases and media between environments easier, even directly with Local​deliciousbrains.com.
  • Keep environments consistent – Try to use similar versions of PHP, MySQL, and WordPress on all environments. If your production moves to PHP 8.2, set Local’s PHP to 8.2 (Local allows changing PHP version in site settings). This prevents “it works on my machine” issues. Local’s Preferred environment will update over time, so check that it still aligns with your production. You can create a Custom environment in Local if you need to match exactly.
  • Only work on Sandbox (Local) – Discipline yourself (and your team) not to edit plugin code or theme files directly on the live server via the WordPress Editor or FTP. It may be tempting for quick fixes, but you’ll end up with discrepancies that aren’t tracked. Instead, make the change locally, test it, commit it, push, and deploy. This way, everything is captured in version control. If you must hotfix on production, be sure to later copy that change back into your Git repo so it’s not lost.
  • Use Git branches for collaboration – If you’re working with others, consider a Git branching strategy. For example, each feature or bug fix is done on its own branch, then merged into a main branch after review. This goes hand-in-hand with pull requests on GitHub. It adds a bit of process but greatly reduces the chance of messy conflicts when multiple people edit the code. Even as a solo developer, branches can help separate “in progress” work from “ready to deploy” code.
  • Document your workflow – Write a short README (you can add one to your GitHub repo!) describing how to set up the project, how to deploy, etc. This is useful if someone new joins or if you come back to the project after a break. Include notes like “to deploy to staging, do X” or “our local domain is Y; update hosts if needed”.
  • Maintain the sandbox – Treat your local site somewhat well: apply WordPress core and plugin updates on it regularly (you can test updates locally first!). This way, you know in advance if an update will break something. Once verified, you can update on production with confidence. Essentially, use the sandbox to vet all changes, including maintenance updates. Local makes it easy to snapshot (export) before big updates, in case you need to roll back.
  • Leverage Local’s tools – Local WP has some nice extras: for example, Live Links (to share your local site temporarily over the internet), and Add-ons (like a link checker, image optimizer, etc.). Explore them as you get comfortable. Also, since Local and WP Engine are connected, if you ever needed to push back to WP Engine (should you decide to keep an environment there), the Connect to WP Engine feature could directly sync your local and WPE staging (though given current sentiments, you might not use that now).
  • Stay organized with GitHub – Your GitHub repo can also serve as an issue tracker for your site. You can open Issues on your repository for tasks/bugs and close them via commits. This is optional, but if you like to keep track of tasks, it’s a convenient place to do so (especially if working with a team or a client who can post issues). It keeps your to-dos tied to the code.
  • Confidence through version control – Over time, you’ll gain confidence deploying changes because GitHub will show exactly what changed. If something goes wrong after a deployment, you can glance at the diff (changes) in the last commit and often spot the culprit quickly. This is much better than trying to remember what you changed in a file via FTP at midnight. As one WP Engine developer blog notes, committing changes “early and often” to Git lets you track the history throughout the project lifecycle​wpengine.com. Embrace that, and you’ll never want to go back to manual editing without Git!
  • Keep the repository lean – Avoid adding huge files or secrets to your Git repo. For example, don’t include the entire uploads folder in Git – use backups or other means for media. Also, don’t put wp-config.php or sensitive keys in the repo. Your config on each environment should stay outside version control (each environment can have its own config as needed). Typically, only code (PHP, JS, CSS, theme templates, custom plugin code) goes into Git. This keeps it small and focused.

By following these tips, you’ll maintain a solid, professional workflow going forward. Initially, it might feel like more steps than just clicking “deploy” on WP Engine, but the trade-off is freedom and control. You’re not reliant on WP Engine’s platform (which some feared could be influenced by Automattic’s direction​sitelock.com), and you’ve built a workflow that is transferable to any host, or even to other projects.

Conclusion

Moving your WordPress site from WP Engine to a local development setup (and eventually to another host for production) is a journey that empowers you as a developer. We started by exporting a full backup from WP Engine, then imported it into Local WP with just a few clicks. Now you have a sandbox where you can hack away without fear. We set up Git and GitHub Desktop to manage your theme’s code, bringing the benefits of version control – accountability, history, and teamwork – to your project. Finally, we outlined how to mimic the tried-and-true Dev → Staging → Prod workflow outside of WP Engine, using Local (Dev), a staging site, and your live site, with Git as the glue holding your code together through the moves.

By investing time in this workflow, you’ve gained:

  • Autonomy: No lock-in to WP Engine; you can host your site anywhere and still develop smoothly.
  • Insight: A deeper understanding of your WordPress site’s structure (since you moved it yourself) and the confidence to troubleshoot issues in a controlled environment.
  • Professionalism: Version control is a hallmark of modern development. Your future self (and any collaborators) will thank you for it when you can track exactly who changed what, when, and why​wpengine.com.
  • Adaptability: Should Automattic or any company make changes you’re unhappy with, you now have the skills to migrate and set up workflows independently.

Remember, the key to a successful workflow is consistency. As you grow more comfortable, you can refine the process (for example, automating deployments or adding tests). But even at its simplest, the workflow you set up today is robust and scalable. Keep using Local for development, keep committing to GitHub, and you’ll find site maintenance and upgrades become far less stressful than before.

Good luck with your development, and happy coding! Your WordPress site is now truly yours to develop and deploy on your terms. 🚀

Sources:

Related Posts

Scroll to Top