SQL Source Control 3.6 and later includes a beta version of the new Migrations V2 functionality. This works quite differently to the V1 migration script functionality introduced in SQL Source Control 3.0.

Migrations V2 is still in beta, and SQL Source Control uses Migrations V1 by default. To use Migrations V2, you need to enable it in the engine and comparison options.

• What migration scripts do
• Enabling the Migrations V2 beta
• Disabling the Migrations V2 beta
• How V2 migration scripts are used in deployment
• Setting the location of the temporary database
• Example V2 migration scripts
• Example - renaming a table without data loss
• Example - writing a V2 migration script that affects objects not yet in the target database

About Migrations V2

Migrations V2 supports:

• all source control systems (including Git and Mercurial)
• branching and merging
• better integration with CI systems for automated deployment
• SQL Azure databases

Unlike V1 migration scripts, V2 migration scripts don't need to be saved in a separate folder in the repository. Instead, when you commit a migration script, it's added to a table-valued function in the database. For more information, see How V2 migration scripts are used in deployment.

What do you think?

We want to hear what you think about Migrations V2.

• Suggest and vote for ideas on the SQL Source Control user suggestions forum
• Discuss the new migrations feature in the Migrations V2 Google group
• Report bugs to support
• If you find mistakes in this documentation, or it doesn't answer your questions, use the "Mistake on this page?" email link at the bottom of each page