When handling different environments for dev and live sites, how to pass on changes that are only saved to the database to the other environment without having to export the whole database? Say for example I disabled an extension, changed the content of a static block, created a new static cms page, added a new shipping method, tax rule, or what have you. How do I pass on small changes like this to the live site without having to export and import the entire database? Obviously there is information on the live site that I wouldn't want overridden.

I'm sure someone else must have run into this, specially when using version control. We have implemented git, but that only works for file level changes. The files in both environments can be exactly the same but some config in the database can change so they behave differently.

I could keep track of all the changes I make in the admin panel, and then reproduce them in the other environment, but that seems very unpractical. The number of changes can be quite large as we are continuously tweaking the site to our satisfaction. Besides, other developers are working as well, and we even set up an environment for outsourced developers and technical support from Magento extension providers. I can't keep track of everything they do.

I've seen tons of posts on exporting products only, so that is not really the problem. I would like the other way around. Maybe someone has made a list of all tables required to clone a Magento site without products and orders and customer information. Just everything that is configurable in the admin panel.

Has anybody done this before?

UPDATE: For the readers, I'm marking @mbalparda's answer on manual deploy files as accepted until something else comes up that does as required. I will enforce rules to keep logs on the changes in the admin panel from all developers involved so we have one unified list at the end. It isn't actually the answer to the question but it is the method I will use to solve this until I find a better process.

3 Answers 3


core_config_data and core_resources are two good places to start. cms_* should have most of the relevant information about blocks, cms and widgets. Beside those tables, most of the core_* tables have some relevant information about the website you are running.

The list is far from complete.

Another good option is to keep a version of the database in GIT and use a diff tool to see what changed between releases but it might have some security issues since personal info might be in the repo.

A good practice i often use is to have a manual deploy file to save all the changes we made in another environment and once the code is deployed, the next step is to check the manual deploy file to see if something needs to be done. This is used in cases where not all the changes can be made with sql/data updates, the regular Magento way to make sql/data changes.

As a note, moving the databases between environments is not always the best choice since changes an admin might have made in the live site will be lost if they are not replicated in the DB you are using in the other environment.

  • This sounds interesting. What exactly do you mean by manual deploy files? How do you make these files?
    – Vic
    Commented Jul 23, 2014 at 15:35
  • Something like a text file with a predefined structure and the steps to follow to make the changes in the live environment. For example: "Go to System - Configuration - Section and change the input with label Url to www.google.com. Save."
    – mbalparda
    Commented Jul 23, 2014 at 15:48
  • Ah, I see. Well, I thought about that, and like I said in the question, I could keep track of my changes, and maybe make the other devs (specially the outsourced ones) keep a file like this, but it still does not guarantee that all changes will be applied, or in the correct order (multiple copies of the dev environment with different changes). I appreciate the advice, but I am looking for something more practical. Just export into a file and import into the other Magento installation. Maybe it isn't as feasible as I thought..
    – Vic
    Commented Jul 23, 2014 at 15:53
  • I updated the question. I will mark this method as the answer because it's the one I will use. If I ever find the time to complete that list of tables I will post it!
    – Vic
    Commented Jul 23, 2014 at 17:37

The Magento database is not your usual database. It's large and complicated.
Moving parts of it from one environment to an other is no small task.
That's why I usually avoid changing config settings or adding blocks and/or pages manually.
I let the client do that only on the live server.

What I need to do while developing I do it via upgrade scripts.
This way everything is versioned and portable.
I know it's kind of a drag to write an upgrade script just for removing the list display mode for product pages for example, but I didn't find a better way so far.

Here is a small example of how you can change a config setting via upgrade script.

The following enables the flatrate shipping:

$path = 'carriers/tablerate/active';
$config = Mage::getModel('core/config_data')->load($path, 'path');

I guess this could work if you put it in an upgrade script inside sql/[resource_name_here] but for data manipulation I use data/[resource_name_here].

Here is an other script that adds a static block.

$block = Mage::getModel('cms/block');
$block->setTitle('Some title here');
$block->setContent('This is the content');
$block->setStores(array(0)); //make it available in all stores

You can basically do this for every entity you have.

  • 1
    This looks nice if I know what changes will be made. What about the changes I couldn't track? I need to figure out which changes where made to one environment to be able to replicate them in the other. As per avoiding changing config settings, this site isn't for a client, but for ourselves. My boss wants to see the site in dev environment exactly as it will look like live. Creating blocks and pages is only a tiny fraction of the problem in comparison to finding what settings where changed, specially when they were made in a different scope than default.
    – Vic
    Commented Jul 23, 2014 at 15:36

I found a lovely tool to export and import configuration settings https://github.com/Zookal/HarrisStreet-ImpEx

This does a lot of what you guys and me are looking for I think.

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.