Appearance

Migrating from Redgate SQL Source Control to VersionSQL ​

VersionSQL can pick up where Redgate SQL Source Control leaves off. Keep your repository and its history.

Redgate SQL Source Control has served SQL Server teams for years. If you've decided to move, review your first commit carefully. Different scripting engines produce different text, so that first commit records the change of tools in your history.

This video shows automatic detection. VersionSQL 2.7 also adds a connection-dialog button that applies the same Redgate compatibility preset manually.

1. Install VersionSQL ​

Download VersionSQL and open SSMS. The two tools can be installed side by side. Choose a database already connected to Redgate SQL Source Control.

Do not alternate commits between the two tools during the move. Their scripting differences would flip-flop in your history with each switch.

2. Connect with Redgate compatibility mode ​

Right-click the database and select "Connect to Version Control". Enter your existing repository URL, then check the branch and database folder.

Before you save, click "Advanced Options", open the "Scripting" tab, and click the "Redgate SQL Source Control" preset button. It applies Redgate compatibility mode right away, so you can check the paths before your first commit. (If you skip this, VersionSQL still applies the mode on its own if it clones a repository with RedGate.ssc at its root.) The preset covers folder layout, filenames, permissions, role memberships, and security-policy placement. It also enables security objects and the GO batch separator.

Check that the resulting paths match your existing repository layout. Link the static data you want to include, and connect SQL Server Agent separately to include jobs. See Static Data Scripting and SQL Server Agent jobs.

3. Review and commit the baseline ​

Start a commit and inspect the differences. Expect formatting differences, but check apparent object additions, removals, permissions, and file moves individually. Commit the reviewed baseline with a message that identifies the tool change.

Open "View History" and check earlier Redgate SQL Source Control commits alongside the new one. Reusing the repository preserves its commit history. Each object's history depends on matching its existing path and layout.

What changes? ​

You keep:

  • Your repository and its commit history. Each object keeps its own history as long as its file path stays the same.
  • Undo scripts, static data, and security scripting as part of your workflow.

You gain:

  • Commits for an individual object or an object type, as well as the whole database or connected databases across an instance.
  • Deployment scripts from any revision, generated right in SSMS.
  • SQL Server Agent jobs in source control.
  • Other VersionSQL features, such as scheduled commits.

VersionSQL supports object locking only with Subversion. If your team depends on Redgate's object locking with Git or TFVC, stay with Redgate SQL Source Control.

Licensing ​

See personal and team pricing for perpetual and subscription options.

Try VersionSQL. If you want me to check an unusual repository layout, email me.