One of the most common reasons new developers and perhaps existing WordPress developers resent WordPress sometimes is because of how it stores so much application configuration in the database, and most commonly, stored in different structures and in different locations.

More traditional web applications would be coded up and the database is essentially stateless. By that I mean the database only contains content, and users. It means traditionally, you could run a web app locally and on the production server, and not really have to sync the database and forth (unless there were schema updates etc).

This isn’t completely WordPress’ fault. Most developers are are comparing an application built in a framework like Laravel, to an application built on top of WordPress with a CMS included. This is an entirely different argument, one that is best left for another day.

The point remains, that if you do professional WordPress development, you’re going to have to deal with database migrations.

Larger and more professional WordPress deployments require the ability to push databases around from local development, to staging environments, and production environments. This problem becomes exponentially harder when your production site is a fast moving site with content and comments being added.

So, what options are out there?

WP-CFM

WP-CFM is a relatively new plugin that is based on a similar concept in Drupal. In a nutshell, WP-CFM allows you to monitor values in the wp_options database (where a lot of configuration happens in WordPress).

It’s a nice plugin but from my experimenting with it, it’s value is limited.

WP-CFM will be handy if  you assume all your configuration settings are in the options table, in very simple key value pairs.

This assumption is risky, I’ve seen so many plugin developers build their plugin to save settings in all kinds of ways that I can’t safely assume that config will actually be in the options table.

For example, if you use Advanced Custom Fields – it currently stores all it’s config in it’s own custom post type. So if you wanted to make some config changes on your local environment and then push up to a production server(s) – you couldn’t.

Another common example, is changing configuration values within a Gravity Form – you want to test some changes locally, then once you’re satisfied, push them up to the production site. Again, you could’t use WP-CFM, because Gravity Forms stores all the form configs in it’s own database tables.

RAMP

RAMP, by Crowd Favorite makes it easy for sites that may require sign off by clients or different organisational departments to move content around multiple environments with ease.

Although I haven’t used this plugin, I’ve heard many good things about it.

RAMP does not help when it comes to moving configurations or plugin settings around, or between different staging environments.

DB MIGRATE PRO

DB Migrate Pro is probably one of the most flexible tools available.

Where DB Migrate Pro excels:

Small client sites where you do local development

Pulling the database from production environment to local or staging

Pulling the database from a live site to a staging site to test content

Pushing specific, new pages or ACF configurations

Fixing / dealing with serialised data

I have found where DB Migrate Pro struggles includes:

Moving specific bits of data, eg: specific records and merging in with existing systems

Pulling down very large data – downloading a 4GB database via AJAX / the browser is not the fastest way to do it, compared to a mysql dump and rsync.