Last updated on May 17th, 2018 at 05:27 pm
Back in 2012 I wrote a blog article called “moving from test to a live environment with WordPress” and it was how I manage my migrations – but something I had neglected to includes – was that I normally use dev.mydomain.com – or ww3.mydomain.com – or vvv.mydomain.com – and the happy accident of migrating from one three-character sub-domain to another (www.mydomain.com) is that the process just works.
The reason it might not work if you have a different number of characters in the test to live environments, is how WordPress stores variables as SERIALIZED DATA.
So because I had always chosen dev.mydomain.com – not ‘test.mydomain.com’ – my migration was working. My blog article, used ‘test.mydomain.com’ though – and that meant that my blog posts was inherently WRONG.
So – here is an article on how to fix serialized data – it’s not my article, here it is:
http://alexscammon.com/2011/06/migrating-wordpress-blogs-fixing-the-serialization/
That said – his link to a script to unserialize + serialize the data again, does not work (the site is either down – or gone. So I found a script from David Coveney – and link a copy here (in-case his site goes down as well). I claim no ownership, credit or rights over this script – it’s all David’s work!
Please note – his script has the options table hard-coded as ‘wp_options’ – if you have changed your DB prefix – you’ll need to change the table name – it’s right under the Database variables in this script.
Another option for migrating sites (as yet untested by me) – is the Plugin: WP Migrate DB
Either solution is used at your own risk – and we recommend both DB + Filesystem backups before installing or running ANY php scripts or WordPress Plugins.