Storing MODX Objects for dev -> prod migrations?

Wondering about migrating MODX objects between environments (dev to prod and vice versa). There are some cases where transport packages are not appropriate, and I'm wondering if there's a way to store MODX objects as JSON or serialized data (similar to what's in the cache) primarily to keep them easy to edit (as you might have in a config file: simple key/value pairs).

Here's one example:

We make a copy of the production website and pull it over to the development server. We need to have a series of system settings that are different on the dev server (e.g. API keys). My thought was that I could iterate over some modSystemSetting objects and overwrite the entries in the database copy and end up with a version of the site appropriate for the dev server. Although I could achieve the same effect by doing dumps and partial dumps of database tables, using MODX objects would hopefully solve the problem of related data, e.g. a user object would hopefully contain its profile data and a page would have its TV values.

I know transport packages probably fit into this, I'm just thinking there might be a simpler way...

FWIW, I'm actually working on two solutions to this. At the moment, neither is entirely practical on large projects because there is no index of changes to track for the database objects. However, in conjunction with a feature I'm trying to implement for the 2.3 release that will allow tracking changes made to any database table, one or both approaches should become more efficient and scalable.

The first is in essence a transport package build tool that uses JSON tpl's to define how a transport package is created (aka extracted) from a MODX deployment. It can reference scripts to be executed when the package is installed (aka injected) and can read/write packages to/from S3 or any valid PHP stream resource. This is based on the technology developed to power the snapshot features in MODX Cloud and we are working on providing a UX around the original CLI toolset to make it more accessible to a wide variety of MODX users.

The second is a MODX and PHP-wrapper library and CLI tool for git that serializes/deserializes the database objects to files in a special .model directory. This allows you to track data objects in the git repository alongside your files and has the advantage of allowing you to utilize git to resolve conflicts that arise between various environments.

Both currently use the same approach of serializing the data to JSON for storage. And unfortunately, both share one significant limitation to the process of migrating data across environments: they are unable to resolve conflicts when using Resource IDs in content fields, settings, and/or properties of the data objects that were created disparately in each environment. I will have more information on both approaches and this significant limitation we can work toward a solution for in the near future as I prepare to release some initial beta versions of each tool.