title: Best practices for managing migrations that update several databases?
body: <p>My team is evaluating tools and processes for managing database migrations/database refactoring as described by Martin Fowler, Pramod Sadalage, et. al.  We're interested in automated, repeatable, testable processes, so we're not interested in techniques like manually running SQL Compare every time we deploy.  We're currently using CruiseControl.NET for continuous integration.</p>
  
  <p>Our production environment has multiple SQL Server 2000 database servers with replication  between them.  Our migrations will thus making changes to the schema on both the source and target database server.</p>
  
  <p>To perform such a migration with a tool such as dbdeploy, it seems we would need to run the migration against one of the servers, and we would have to add the other servers as linked servers.  A single script running against the main server could thus execute DDL against any of the linked servers.</p>
  
  <p>My question is this:  would this approach be considered a best practice, or is there a better technique for applying migrations that touch multiple database servers?</p>