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:

Totally new project (local install)

Deploy local to live

Migrate/clone live site to development site.

Migrate/clone development site to brand new live site.

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 ofDesktop 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

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?

Reader Interactions

Comments

Basically the same process here. I had actually been using Desktop Server for a little while before I discovered the Blueprint feature. My mind was blown. It’s incredibly helpful, especially if you have a plugin, or group of plugins, that you always include with a site that require licensing (i.e. Gravity Forms).

Been using DesktopServer since the beginning of the year… I’ve deployed from local to live, I’ve set up a local from a live site to tinker and then manually pushed out changes. I just yesterday set up a site on Flywheel and they moved it all for me, that was fantastic! Should be launching very soon.

Glad to hear you like their local to live process! I’m hosting this site with Flywheel and I love it. So easy to set up dev environments and pass billing to a client, but I wish they had a playground, so to speak, where I could play on a live environment, but not necessarily transfer that to a client at some point.

Hi, Carrie — first time commenter. Super helpful post as I’m just getting started. Also a MAMP user, but intend to play around with ServerPress to see what it’s all about. I do use ManageWP, but have yet to try the cloning feature. Thanks so much for the help! Looking forward to the office hours! Sandee

Thanks for the mention here as well. I just finished reading the article you posted a couple of days ago, so I’ll just say thanks again and if anyone has any questions about DesktopServer, please feel free to ask!

I build all client sites live on a test domain, then use BackupBuddy to move them to the client’s server (assuming it’s a brand new site). I’ve been considering ServerPress but for right now, I see no reason to change up my workflow since it works well. PluginBot is a great tool for live builds since I can install all my preferred plugins at once.

I’ve done basically the same thing as you, Andrea, but using ManageWP instead of backupbuddy and just manually going through the migration process in the rare instance it doesn’t work (I encourage clients to host on my server, and as long as the server is quick enough, that has seemed to work even on larger sites).

I’m probably going to switch over to DesktopServer, though, after watching a few of their demo videos. Actually found this blog entry while looking around for DesktopServer coupon codes. Main advantage for me would be that on a local server it’s just so much faster to refresh, change settings, etc.

Glad to see other people looking at this sort of a tool, too. I feel like a cheater when I use some of these one-click solutions for things that I know how to do, but just don’t enjoy doing.

Thanks for sharing this, my friend. I love (honest) workflow posts! I recently started using Desktop Server as well, and am loving what I see so far (but still have a long ways to go, I think). You got me hooked on ManageWP a year ago, but I’ve had similar issues with cloning so will check out the other option now. So thanks!

Hi Carrie… I’m sort of a WP newbie started a few months back. But, i am a computer tech by trade. Just thought I would share that haven’t learned all the tricks people talk about but I really do appreciate all the help I get around here.. especially with all the God loving people using Genesis.

I use Siteground and have used another host just prior and no comparison. I like SG due to the fact it is really fast, support is great when I need it and they have a staging feature that I love.. I can stage up to 10 sites and push them to live in a matter of seconds. Takes about 30 seconds each way. I still have a ton to learn and love your dedication to help people like myself. Thanks for all you do.

Siteground also allows me to refer someone and they can get a basily a year free after they pay for only a month. I’m not here to post the affiliate link but if anyone would like that deal they can certainly request it from me and I will send. I actually have their Geek acct. and could not be happier. I have about 10 sites I and working on and finished up 3 so far.

This is awesome. You’ve opened up the curtain to let us see inside all things Awesome Carrie! That is super cool and very helpful. We probably need to discuss workflows more so that we all can learn from one another and improve. I’m definitely sharing with my team!

Better is a subjective term. Note that Vagrant out of the box, doesn’t have copy or blueprint features. Keep in mind that DesktopServer runs natively on your computer without a Virtual Machine. There is no “booting” up, virtual hard drive, virtual network drivers, file system transfers, or anything like that. It uses less memory, less CPU, and runs faster than Vagrant. It works on your local computer just like “Word” or “Excel” and is built specifically for your computer’s microprocessor and operating system. You can edit your files directly in your favorite editor without having to mount a virtual file system, etc.

Both DesktopServer and Vagrant are open source. I think what you mean is that Vagrant is “free-er” as in “free beer”, “I don’t have to pay for anything” for access vs SaaS, updates, or support. Not to be confused with “free” open source which pertains to copyright (or “copyleft” as us FOSS developers like to call it).

That being said, Vagrant has some bonuses if you have the extra hardware to run it. You might not be creating a site in under 5 seconds like you can on the latest Macbook Air with DesktopServer, but once you do boot up a Vagrant, you can customize it to look more like your hosting provider’s hardware. That can be advantages if you want a more seamless environment (provided your hosting provider reveals their internal specs. or you do the research to find out what those are).

I use VVV for much of my development, but also use DesktopServer alongside it. They hit two different markets if you ask me, and actually work well for me side-by-side. Vagrant is amazing at providing a full server environment that can mimic your live environment for fuller testing and VVV specifically gives you a great WP environment. DS brings an unmatched ease-of-use that many designers and beginning developers will prefer and has some pretty sweet features with their deploy method and blueprints.

I’d hesitate to say that one is really “better” over the other. It’s all a matter of how you develop and what your needs are.

Great post, Carrie, as usual! I’ve been using Migrate WP Pro, DesktopServer (Loves it), along with Git and DeployHQ. Although, Siteground and WP Engine’s Git push capability are pretty amazing.

I’m intrigued by setting up Vagrant and Grunt, but not seeing too enough benefits to abandon what I have. Though, with that line of logic I may be going the way of the WebKing (http://www.webkinglasvegas.com/) sooner than later.

Oh, how I struggle with workflow. Thanks for sharing yours. The hardest part is pushing changes to an existing site. I wish it were more straightforward. You can set up Git and deploy changes to your files, but then there is still that pesky database! I wish that WordPress would enhance its native export/import to include everything (menus, widgets, etc). I’m not sure why they don’t or if there are any plans to in the future, but it sure is a pinch point in the process. I also struggle with the idea of writing over the entire db when you only want to update certain things. I haven’t tried WP Migrate DB Pro yet, but I know I need to, as it seems to be the best solution as of now.

Great post! Just found your site. I’m new to Genesis and really love it.

Here’s what I do…

New site:

– create on dev domain on my own hosting acct – once complete, clone entire site using WP Twin by Rapid Crush software, but Backup Buddy would probably work well, too. I love WP Twin as it copies the db, changes all urls, never times out. – deploy with WP Twin on live url. WP Twin deploys is seconds.

Existing site:

– clone with WP Twin and deploy to a dev domain – make changes and reclone – wipe live WP install, create a fresh install of WP and deploy cloned update.

A few nuggets (especially in the comments!) that I haven’t heard of. I want to start playing with Desktop Server – I need a deploy to live solution that works better than the old FTP one 😉

My biggest problem comes with deploying to a live site that has its own content on it. Depending on what is on the old site – if all they want to keep is the posts/postmeta – I might pull the database and then merge the two SQL backups (from development and live) before dropping all the tables in the database and re-importing the new, merged, one (of course I make sure to keep a full backup in case I mess up royally, which never happens <– , 😀

Thanks Matt! Not sure of a coupon for DS (the one I mention is for Migrate DB Pro). I’d suggest starting with the free version of DS – it’s still a really awesome piece of software. The primary capability of the paid version is deployment to live server.

Austin, thanks for the comment. Actually, you can create a blueprint and put it in your xampplite/blueprints directory and it will show up in the dropdown. The main difference is that the blueprint you create will not have the plugins activated, whereas with the paid version, you can use the “export” feature which has all of your plugin registration information along with whether or not it was activated.

And we don’t like to develop locally, but for clients who are first-time web owners or established clients that are getting a new domain but have not decided on it yet, we often develop the client site on a local iMac ( via XAMPP) or on one of our domains we use for testing on our dedicated server (at Pair.com.) We then migrate it to the client’s server and domain.

Over the years, we find that the WP Codex migration instructions work just fine and without any added expense. In the past we’ve been bitten on our “bottoms” with 3rd party plugin tools and pay-per-month services.

Do understand: I’m sure that the services and products mentioned in the comments here are fine… but we like being in as much control as we can, to say nothing about the costs involved.

The really big ‘gotcha’ in migrating WP sites from a development platform to a client’s production domain is the fact that WP (for some dumb reason I’ll never understand) decided to serialize the site URL in some of its tables.

Lots of people will do an SQL dump of the database to plain text and use a text editor to search and replace… i.e development-domain-name.com –> client-domain-name.com. Well, because of string lengths and other issue with serialized data, that method can also bite you on the “bottom.”

So, what is the answer? Simple. There is a terrific free tool that has never failed to work for us.

We dump the development MySQL file and load it to the client’s site (both via phpMyAdmin) and then upload this little PHP program and run it with the database’s user, passwords, DB-name, sever info (same stuff in wp-config.)

My guess is that there is code similar to to what is in the above in the routines by the various services and plugins that seek to make migration easier.

If you follow the WP Codex methodology ( and I can’t believe that professional developers would have any trouble doing so) AND use the little PHP program by InterConnect/It you will get flawless results and won’t have to pay 3rd party costs.

Yes, it takes us a tad more time but we get to control the process which is one way we protect our “bottom.”

Hope this is of value to someone.

(And Carrie, we love your blog. While you are a strong supporter of WP ( and Genesis, which is our weapon of choice) you are also one of the few writers in the genre not afraid to be critical of WP or some of the products (themes, plugins, services) when criticism is warranted. You’re the best of the best!)

Hey Al, Great points you bring up – you’re right that serialized data has always been the biggest PITB (Pain in the Bottom) when it comes to moving sites around. Thanks for sending the Interconnect link – I hadn’t seen that.

I start everything with a git repo in Beanstalk. I clone that locally and build my site, committing along the way. (Beanstalk automatically deploys to my staging server when I do a local commit and push). Once I’m ready for the client to see the site, I use Sequel Pro to export my local db and import into the staging server’s db and replace the appropriate URL strings.

And of course I have this whole process automated down to a few clicks using Alfred. 😉

I came across your site while looking for information about DesktopServer and other deployment methods. What I can’t find is a good way to handle https (SSL) situations. Do you (other anyone else “listening”) have any ideas? Testing e-commerce sites locally would be much more preferable than testing live. Even SiteGround’s staging prevents you for doing SSL teseting.

So I did some more research last night and came across a product called WampDeveloperPro (www.devside.net). According to its specs and features list, it supports SSL (self-signed) and somehow allows you to install SSL certificates. Of course the problem here is, this is really “stretching” what I know how to do… not that that is a bad thing, but it’s hard to evaluate when learning the technology at the same time…

With regard to DesktopServer and its ability to do SSL, while you are correct that the current iteration dust not support it, Version 4.0 will make it possible. We are at the tail end of alpha testing right now and are just weeks away from the beta testing which we feel will be a short period (but as with all software, may be subject to change).

I realize that does not solve your immediate need but it might help to know that it’s coming down the pike. 🙂

Hi Carrie, I just discovered WP Stagecoach (https://wpstagecoach.com/) which handles that last piece of the puzzle: merging changes from staging to live. They’re currently in beta and free at the moment so I’ve signed up to give it a whirl this month.

If you have a chance to check it out, I’d be interested in getting your thoughts on WP Stagecoach.

There certainly is a lot of love going around for Desktop Server! A lot of people I have been talking with at WordCamp London this weekend like it to. I think you’ve pushed me into giving it a spin. Here is what I do:

I use MAMP Pro which makes it reasonably fast to set up local sites, with ‘proper’ urls: i.e. mynewsite.dev or whatever. I do have to create a database manually using the built in phpMyAdmin but this all takes less than 5 minutes. Add on the 5 minutes for the world famous WordPress install process and I am good to go in about 10 minutes all in. Not exactly light speed, but fast enough.

I always start a new entry in 1Password for any new site too.

I create a ‘one-size-fits-all’ wp-config file. I configure this to work with my local, staging and live servers. Set this once and I can then forget about it and get on with the ‘fun’ stuff. Here is an example of my wp-config:

By setting the site url in the config means I don’t need to mess around with a find and replace in the WordPress database. If I add links or images as I develop I just give them relative urls instead of the full URL including domain name. i.e: example.com/my-new-link becomes /my-new-link

So when it comes to deploying the site. I used good ‘ole sftp and a phpMyAdmin export and import of the database. Not exactly cutting edge, but it’s tried and tested. 😉

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.

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!

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?

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?

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. 🙂

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.

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 -> https://datahawk.io/ It’s from the guys over at Migrate DB Pro and looks like it could be a Christmas miracle.

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!)