Mark is correct.  As with any tool that deals with a critical process such as production code promotion, you have to evaluate and allow for a transition period.

With that being said,  DBGhost has the flexibility you would need during this time.  Granted, it won't be an instant fix.  However if you can carefully communicate the DBGhost process with other database developers, in time the job of managing and promoting SQL code will become much easier.  Certainly easier and less error-prone than doing it "by hand".

And to piggy back on Malcolm's comment.  Once you start using the tool, you may decide to allow the tool to update production directly.  One reason I can see right away is due to the way it handles SQL logins.  However, being the paranoid DBA that I am, I want to see exactly what is going to be executed against my production database before I execute it.

If you decide to go this route, at the very least, you will want to generate this script in QA and look at it just before "go-live".

Of course, I'm the kind of DBA that looks at ANY tool with caution.  Including Enterprise Manager / SQL-DMO.  Just gimmie the code, the whole code, and nothing but the code...