Deploying WordPress

Deploying WordPress: What’s your Workflow?

I recently posted some general tips and tricks for WordPress beginners on how to edit WordPress files. The discussion came up in the comments about workflow when it comes to setting up a fresh WordPress install or deploying to a site live.

Below I’ll share the tools and workflow I use.

Please note there are affiliate links in this post for products I use and love. You can read my full disclosure here (if you care). 🙂

Situations for Deploying WordPress

Here are some situations where you need to set up WordPress, clone or migrate a site:

  1. Totally new project (local install)
  2. Deploy local to live
  3. Migrate/clone live site to development site.
  4. Migrate/clone development site to brand new live site.
  5. Push changes from development site to an existing live site.

I’ll break out each of these below and which tools I use for which job

Totally New Project

For a local development environment, I used to use MAMP and a single WordPress install. Before you scream at me for just a single install, I’ll explain why: I could drop my entire library of themes and plugins into that install without replicating them a million times.

But then I screamed at myself and how terrible one install was. About this time I met Gregg Franklin at WordCamp Las Vegas and he ran me through a demo of Desktop Server. I fell in love with it.

The beauty of it is that I can set up my Perfect (or “Blueprint”) Install (i.e. already have my basic settings , favorite plugins, etc.) and copy it all over the place. So, when I need to start a new project, I fire up Desktop Server, click a button, and voila! It gives me a fresh local install of WP based off my Blueprint. In all of two minutes I’m up and running with a local development site.

You can use the free version of Desktop Server for this.

Deploy Local to Live

Desktop Server is still my choice here, but you’ll need to upgrade to their premium license ($99.95) to use the direct deploy to live server feature.

The process is ridiculously easy (unless you’re pushing to a WPEngine server, in which case there are extra hoops to jump through). Desktop Server deploys both your database and your files and updates all instances of your site URL along the way. The premium version also supports MultiSite, if that’s something you need.

Now, Migrate DB Pro (which I’ll talk more on shortly) has the ability to push a local database up to a staging or production database. I discovered Migrate DB Pro after Desktop Server, so I haven’t tried out that feature yet.

Migrate Live Site to Development Site

Migrate DB Pro
I like Migrate DB Pro so much that I’m an affiliate for them. Use coupon code SUPER20 to save 20%.

Depending on the nature of a project, I might never do a local install and just develop on a designated development site. In this case, I want to take an existing site in its entirety and pull it over to a development site where I can tinker.

Enter Migrate DB Pro, which is easily the best $199 I’ve spent all year. An important distinction to note for this software… it’s Migrate DB Pro – not Migrate All Site Files Pro.  This tool is best for moving databases from one spot to another, although they recently added a Media Files add-on that pulls over a site’s media gallery (super handy!). You’ll need to manually upload any themes or plugins you want.

So, my workflow looks like this: On the development server, I install WP, activate the same theme and plugins being used on the live site, and lastly do a database pull using Migrate DB Pro. Working in that order means that when the data comes in, it’ll automatically put widgets where they belong and restore any plugins or settings from the live site. If you work in the reverse order and bring over your data and then install theme/plugins, you’ll miss out.

Migrate Development Site to a Brand New Live Site

A year or so ago I started using ManageWP‘s site clone feature to copy a site (files + database) from one spot to another. While I loved the idea of the clone feature, it turned out a little clunky. For instance, the automated search/replace for dev URL to live URL was incomplete (URLs in widgets needed to be manually updated). Also, the clone feature seemed to only work on small sites. Larger sites timed out or just crapped out. I still like ManageWP for general site management tasks and scheduled backups, but I no longer use it for cloning sites.

I make the distinction of a “brand new live site” here because I want to emphasize that I’m doing a full clone of the development site to the new site – any existing data on the live site be damned and overwritten!

Migrate DB Pro is the winner here. Note that I do need a WP install plus theme and plugin files already set up on the live server, but once that’s done I can pull in the dev database and 1 minute later have my entire dev site replicated perfectly on my live server.

Push changes from development site to an existing live site

It’s confession time. This is the weakest area as far as a deployment routine. Let’s say I’m building a new theme for a client. The end deliverable is an installed theme on their server with their data. Doing a database overwrite isn’t ideal, but neither is waiting until the theme is live on the client’s site to go through all the settings and options ideal either.

For simple sites, there’s no true deployment. I just upload new theme files, activate a maintenance plugin, and work as fast as I can to bring the site back online (typically an hour or less). Can’t believe I just confessed that out loud.

For complex sites, I again go with Migrate DB Pro, but I ended up pulling the latest db files over to development, completing the site setup, and then pushing everything back over to live (so, overwriting the database). That means minimal downtime for the live site (typically 10 minutes or less). But, something in my gut doesn’t feel right about this and a database syncing option would be better.

Keep Learning & Evolving…

Interested in seeing the full development cycle of a WordPress site from setting up a local development environment to pushing the code live and then making changes and doing it all over again?

Check out my WP Development Workflow course.

* Featured image photo credit to U.S. Army

63 thoughts on “Deploying WordPress: What’s your Workflow?”

  1. I tried the free Desktop server version and it kept crashing. It wouldn’t even start up the server for me. It worked for about 10 minutes, and then I started having problems and went back to Mamp. I’m experimenting right now, trying to find out an ideal work flow using Git, I guess we’ll see.

  2. Hi John,

    I’m sorry this is happening to you. I am sure that if you shot us an email, we’d be happy to help you troubleshoot. It should not be crashing every ten minutes. And, obviously, if it was a common occurrence, we’d be out of business!

  3. Curious to know if I need to go with Desktopserver Pro or not?

    We are looking to set up a system with WP on local but also have a Stash/Git repository and deploy to a cloud VM. Can I do this without desktop server limited? I’m not really sure what the ‘live deploy’ system is?

  4. Carrie, Thanks so much for this post! Your content and (teaching on Lynda) is legendary 🙂 I made the leap to DesktopServer after reading this, and the difference it’s made is day and night. Using the Widget Data Settings import and export app to migrate widget data but its still a bit fiddly, besides Migrate Pro wondered if you had any tips for preserving widget data when releasing to live site?

    1. Thanks, Rich! If you’re using Migrate DB, that’ll include all of your widget settings! I’m sure there are other tools to do that (like the plugin you mentioned), but Migrate DB does such a good job I’ve got no reason to change. 🙂

  5. Hi Carrie. What do you do in the event of making changes to an already live site where the data on your local version is different to the data on the live version? Therefore a push/pull wouldn’t work as it would copy over either version. It’s more of a merge.

    In a real life situation, it’s when a client asks for new features but continues to edit the live site.

    1. Hey Rob,
      That’s a major rub for everyone. I’d pull down a latest copy of the site, do any development locally, then copy the live site to a staging site (most managed WP hosts have this feature). At this point you’re working with the latest data, sans your new development. Push your new _files_ to staging site and integrate your updates. Of course, this is a PITA if your new development involves any database config. For most sites I work on, clients are not publishing content daily (or even weekly), so coordinating the effort is easier.

      You might keep an eye on this -> It’s from the guys over at Migrate DB Pro and looks like it could be a Christmas miracle.

  6. Yeah think everyone struggles with it… I keep asking everyone in the hope that someone has solved it. Yep the developer gave me a heads up about that… no timeframe of when it’s coming out though.

  7. Hello,

    Thanks a ton for the tutorial — resources like these allowed me to become a web developer in the first place.

    I have a question – do you have any experience with pushing/pulling sites using WP CLI? I’m reluctant to buy WP Migrate DB Pro when WP CLI allows you to export/import databases with a single command, including serialization/unserialization as necessary. The only downside that I can see is that the old database is replaced upon import, but with a quick search-replace you can make the new database virtually identical.

    Is there something major I’m missing here? I’d prefer not to spend $200 if I can avoid it, but if there’s some hidden downside to my approach then I’d definitely get Migrate DB Pro (with your affiliate link of course!)


Leave a Comment

Your email address will not be published. Required fields are marked *

Carrie Dils uses Accessibility Checker to monitor our website's accessibility.