I am posting this question because I would like to know what the best development workflow is for someone who wants to manage all aspects of an online store.

As with all web development of course, having a live copy and at least one development copy of the entire software solution is of course very important. However managing Magento stuff is not like managing other "file-based" software because there is also a database component which comes into play, so, besides the fact that I can use a tool like Git as a VCS tool for source control, how would I go about managing differences in the database between the live and development versions?

I could of course make backups of the live database via cron, and insert the SQL INSERT statements from backup into source control, but after that two databases will evolve separately while customers register and place orders on one hand which go into the live database, and as updates are made to the development database separately. When it will come to merging development and live versions, the php files can be updated no problem via git (using gitignore on the single file which host database configuration details), but what about the database files? How can I merge the two files containing INSERT SQL statements from the two backups without causing a disaster and wrecking the system?

This is the shady area of the Magento development lifecycle which I am facing: managing database differences.

It seems to me, like the only solution to synchronizing the database contents which differ between the development/testing and live versions of the Magento store is to write down on a piece of paper all changes made in the development version via the Magento Admin Panel, and hope not to make any mistakes, and then once everything is tested and works file, to go over to the live version and carry out those exact same changes while Magento is taken offline and is put into maintenance mode. Since this is a manual process, is it prone to error.

So, what is the better way to handle database synchronization between the test magento server and the live magento server?



4 Answers 4


Options that I am aware of

1.) Manual - in other words repeating your actions manually in the back-end = as you mentioned prone to error, slow

2.) On the database level with direct SQL queries = prone to error

3.) Create an extension which adds, makes changes through sql setup/upgrade scripts. These files are part of your repository and can be deployed. This approach mostly bypasses the UI.

4.) There has been some work going on in trying to make some of this workflow more pleasant in projects like this, but I think it is not quite ready for prime time just yet.

Out of all these options I currently favour 3.)

  • Yeah, me too, favour 3 as well. Who wouldn't. However, since 3 is the only real option and it isn't stable as of yet I am going to bypass all suggestions and just do testing for the purpose of comprehending how the UI works on the local server, and carry out all product catalog and products and other updates directly on the live server, possibly taking it offline for some time, or better, just being careful to make products active just when they're ready, since, I will have to be careful anyways, why not be careful in this way, which probably can do the least damage out of 1 and 2 anyways. Thx Commented Oct 23, 2013 at 15:31
  • 3.) is stable, repeatable and file based - the downside is it requires a more work to set up. Commented Oct 23, 2013 at 15:50

There is mageploy which might solve this problem too.

  • As for now, nobody at mageploy has updated its website. It still states that it is only for Magento
    – Max
    Commented Mar 15, 2017 at 15:48

There are database tools such as Quest Software's (now Dell's) Toad for MySQL. This database management tool has data and structure comparison features which you can use to see changes between two databases. Just keep backups (or git commits) of the database versions you want to compare, and voila. There is even a script generator for bringing the two into sync.


We solved this issue by creating a remote DB for the local and staging developments to read/write. Really helps with time and efficiency; no more cloning, uploading the DB to everyone's environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.