What table data should persist when migrating Orchard CMS data into multiple environments?

With Orchard CMS 1.6, I have four environments set up: Development, Testing, Staging, and Production.

I have made a lot of changes from the Orchard UI Dashboard in Development and I want to migrate those changes into other environments. A related question shows this can be done manually through the Orchard Dashboard using Import/Export modules, but I'm looking for a solution for data migrations that I can automate. Really, I'm looking to nail step three for SQL Server 2005/2008 database in the accepted answer for this related question: that states, "Migrate your db to production environment."

There is not much documentation out there when it comes to setting up and maintaining Orchard CMS in multiple environments outside of Azure and I have 88 tables in my current Orchard database. Obviously, anything I can do to automate data deployments would be a huge help.

I ran a Schema and Data compare between Development and Testing(which currently reflects Production). After backing up databases and replicating schema, I noticed there are a lot of data differences in almost every table. Before migrating data, I want to be sure I've isolated the tables I do not want changed. Environmental variables such as connection strings are going to have to stay unchanged.

What tables should persist in their environments?

Right now I am thinking they are:

1. Orchard_Users_UserPartRecord - I have users in Production I do not want to have anywhere else.
2. Environmental Data - I have connection strings I put in a table for a custom module that are different for each environment.

Am I missing anything? What other data should be retained in tables on destination environments?

I really wouldn't recommend a database migration: you are going to have huge problems with ids, relationships, etc. Content items are distributed onto many tables, sometimes in ways that are hard to predict, and there's no guarantee that the same id hasn't been attributed on different environments to different items or records. This is why a higher-level procedure like import/export is the recommended approach.

Automating it is absolutely something we want, and there is a feature branch doing exactly that for a future version of Orchard (feature/deployment IIRC).

In the meantime, I'm pretty sure import and export also exist as commands for the CLI, which should enable you to automate it to a degree.