Based on your saying, it seems that we can take Better advantage of dbghost only if source control system exists. But in real world, this may not be true sometimes.

I’d like to raise the following questions / scenarios for your considerations:

1. Can dbghost migrate some tables with some of the records, say for sales table, I need to migrate the sales table together with top 10 largest transactions in each year? For other tables, I may / may not need to populate them with specific business rules?
2. How can I change the job schedule from original monthly running to weekly running during the migration?
3. Can you show to your clients what you will do upfront with a simple and clear document so everyone can understand and make a comment? (I know dbghost can generate a report later, but to me I need the report first to get the review and approval and my client can even add their own business rule in the document, which I will use to generate my migration scripts directly, and I will not change a letter.)

 Yes, for 1 & 2, we can have additional scripts to achieve the purpose but that's not what I want.

Saying all these, I think maybe dbghost does not have a similar target function space as my approach tries to achieve. I’d say my approach has the limit as far as VBScript can reach (to interpret the self-defined protocols)