Flyway

Transitioning from other Redgate tools

For new users looking for a database versioning and automation solution, we recommend that you start directly with Flyway.

For existing users (including SQL Source Control, SQL Change Automation, and Source Control for Oracle users), we recommend that you start learning more about Flyway now by reading this documentation and/or watching training videos on Redgate University.  You can import your existing projects into Flyway Desktop or use Flyway AutoPilot to explore a sample project. 

Although SQL Source Control, SQL Change Automation, and Source Control for Oracle are still actively supported, we will stop selling these to new users in 2024.  Support and maintenance will continue through at least the end of 2025 for existing users. 

Please let us know about any questions that you may have and whether you need our assistance with your transition.

Why Flyway?

Flyway is our next generation database versioning and automation solution and has the following advantages:

  • Performance improvements
    • If you are experiencing any performance problems with SQL Source Control, then you should move to Flyway. Flyway Desktop is a standalone tool, so unlike SQL Source Control, is not limited to the SSMS memory space. 
    • Flyway does not poll the database and requires fewer comparison operations, which greatly improves the performance.  Polling the database is especially problematic if your development database is in the cloud.

  • Breadth in database and operating system coverage
    • Flyway works with over 50 database systems including SQL Server, Oracle, PostgreSQL, MySQL and MariaDB.  It's been designed and developed with cloud databases in mind.
    • Flyway runs on Windows, Mac, and Linux.  This includes Flyway Desktop installed on developer machines as well as the Flyway CLI in CI/CD pipelines.  The Flyway CLI is also available in a docker container, which can easily be integrated into CI/CD pipelines.
    • If you need to connect with Azure Interactive Authentication (Multi-Factor Authentication or MFA), then Flyway is required as this is unavailable in SQL Source Control.

  • Improved Git integration
    • Flyway Desktop allows you to open projects from version control, which will clone the repository to your local disk.
    • You can switch branches and/or create new branches from the Flyway Destkop GUI.
    • Version control actions are easily accessible from a side panel displaying the number of changes to commit, push, and pull.

  • Option to use migration scripts for deployments
    • With the ability to customize migration scripts, Flyway supports a more robust continuous delivery process for database deployments. 
    • A migrations-based deployment approach is essential if you have "complex" data motion or schema changes that require human input.
    • With Flyway Enterprise, you can auto-generate undo scripts as part of a roll back strategy.

  • Additional improvements


Considerations before moving

We encourage you to try Flyway and give us your feedback ASAP so we can try to make the transition as smooth as possible and you can start planning for your transition.  There is a 28 day free trial of Flyway Enterprise that you can use or get in touch with Sales to talk about a license that will allow users to use both tools during this transition phase. 

There are some capabilities that are not in Flyway yet that are still work in progress:

  • Object level history - You currently need to use your own version control tool or command line (git status) to view the history of changes to your database objects and migration scripts.  We hope to include the ability to view Git history in the Flyway Desktop GUI in mid year 2024.
  • Automated state-based deployments using SQL Change Automation (SCA) PowerShell and/or SCA CI/CD extensions - We plan to incorporate state-based deployments into Flyway in H2 2024 and there will be more support for this transition then.  Currently, you can use the SQL Compare and Schema Compare for Oracle command lines to automate your deployments using a state-based approach from the schema model.  We also recommend exploring a migrations-based approach for deployments so that you have full control over the deployment script. 
  • Non-Git version control systems. If you are using a different VCS, you'll need to use a separate version control client alongside Flyway Desktop.
  • Pre/Post deployment scripts - This capability is available for migrations-based deployment. Let us know if you require this capability for state-based deployments.
  • Object Locking - As more users move to dedicated development databases, there is less of a need for this.  We are not planning on adding this until we hear from more users about this need.
  • For Oracle databases - TNS connections are not supported yet.  Let us know if you need this capability.

Please let us know about any questions that you may have about these plans. 

Learn more


Any Questions?

If you have any questions about transitioning to Flyway, please get in touch with our Database DevOps Team.



Didn't find what you were looking for?