I'm not going to get technically involved with this matter because @brian and @Webdongle will leave me for dead. I think @brian's suggestion has merit and worth investigating; as he wrote, it's something you should examine for yourself.
As far as your overall strategy was outlined, in going from developement -> test -> production, there are some scenarios that may impact your choices. Managing the change from a mature, stable production environment through to a new, "improved" environment needs stakeholder involvement, of course.
If the two environments are quite different to one another—if there are changes within the database structures, that is—then the change will be non-linear
. The non-linear change, in this situation, involves structurally
modifying the original (production) data
—the content—when the switch-over to the changed state takes up content
additions, modifications or deletions that occurred from the time the two states were in last in continuum with one another. It depends, of course, on the complexity and duration of the project life cycle.
If, for example, we were discussing a project that involved updating a website from J! 3.8.10 to J! 3.8.11 and the customer wanted a demonstration of the "new site" before committing to the work, then this could be accomplished by creating a demonstration website as a feasibility study; allow the customer (or a team of players, a "business focus group" as I've used the term myself) to play with the demo site and, once the customer is satisfied that the process is sound, the actual work could be carried out on the production site. Of course that's a facile example.
In a situation where a project runs over several weeks or months, the approach I've just mentioned may not be workable. In that situation, @brian's suggestion looks like it has the necessary version control mechanisms in place and may be a more practical way to go. Perhaps the solution lies somewhere in-between?