• Flyway
• Team-based Development
• Integrating with Flyway

Two Small Steps to Measurable Flyway Value

In long-lived legacy systems, particularly monoliths, technical debt and complex dependencies accumulate quietly over time. Eventually, even small database changes run a high risk of breaking some other part of the system.

In such systems, database changes are difficult to track consistently, and so environments tend to drift out of sync over time. Testing becomes unreliable, code quality erodes, and bug regressions are frequent. When failures occur, teams invest long hours trying to roll back changes cleanly and return the system to a stable state. As confidence in the release process erodes, both within delivery teams and across the wider organization, delivery cycles stall.

These problems are well recognized. The harder question is how to address them, without further destabilizing teams and systems that are already fragile.

Introducing Flyway without disrupting existing workflows

In this environment, even introducing a tool like Flyway can feel difficult, especially if it’s assumed to require a wholesale overhaul of existing processes before any value is delivered. In fact, Flyway is designed to integrate simply and securely into various points in an existing workflow. In many teams, for example, the initial goal is to introduce Flyway into the release process to stabilize unreliable deployments, while leaving the established development process untouched.

A recommended adoption pattern in this case is to introduce one additional development copy of the database, managed by Flyway, which serves as a Dev-Integration database. Flyway works directly against a database rather than developer-specific tools or application models, which allows the database itself to act as a shared integration point. It provides a single, stable point where database changes can be captured and tracked, without interfering with local development processes.

The Dev-Integration database starts at a known schema version, typically matching the production schema, immediately after the last deployment. Teams can provision it from a restored production backup (with masked or obfuscated data if required) or from a schema-only backup that includes necessary static data.

Developers continue working as normal, applying local database changes using their existing tools and frameworks, whether that’s SSMS, VS Code, SQL scripts, an ER modelling tool, or an ORM such as Entity Framework. Any database changes that have not yet been delivered are applied to Dev-Integration using the same mechanisms already in place, allowing teams to extend their existing practices rather than replace them.

From this simple starting point, Flyway can deliver immediate value in two small, low-disruption steps, as illustrated below. Each of which produces a measurable improvement in control and risk reduction. This is the path to more frequent and more reliable online deployments. The example below assumes use of Redgate Flyway Enterprise, which provides schema models, migration generation, and automated code checks required for the workflow described.

• Step 1 – Gain visibility and control of database changes
  Establish the object-level state of the database (the schema model), in version control, providing clear visibility and auditability of modifications.
• Step 2 – Improve quality and reliability of SQL migration code
  Generate versioned and validated migrations that are immediately checked for any high-risk issues, such as schema changes that may cause data loss or introduce security problems.

Step 1 – Gain visibility and control of database changes

In Step 1, Flyway makes database changes visible and traceable, while making it easier for teams to work on the database with minimal conflict.

When the application code for a new release is checked in, often the accompanying database changes are handled in a more ad-hoc fashion. Maybe a script is submitted, or simply a list of required changes. Alternatively, the database changes might be an artifact of changes to the application model, such as with Object-relational mapping tools.

In either case, the planned database changes are abstracted, or only understandable by scanning through an ordered list of changes or a long migration script. This creates two related problems:

1. Lack of visibility – no easy way to see which database objects are being refactored, how they are changing, or what impact those changes might have.
2. Change order is already ‘locked in’ – The database changes arrive in a prescribed order, which makes reconciling overlapping changes (merge conflicts) much harder.

Flyway addresses both these issues by introducing object-level change tracking via the schema model. It establishes a simple representation of the current database structure that allows object changes to be captured, compared, and tracked over time, before any execution order is fixed. This makes the schema model the safest and most effective place to review differences and reconcile parallel development work.

Capturing the schema model for object-level change tracking

Having established the Dev-Integration database, teams now follow a simple workflow using either Flyway Desktop or the Flyway CLI. The create a Flyway project, linked to version control, and connect it to the Dev-Integration database.

Once connected, Flyway tracks the structure of each database object as changes are applied. It uses schema comparison to extract the CREATE definitions for every object and save them as individual files in version control, organized by object type. Together, these object-level DDL files form the schema model, a precise, reviewable record of how each object changed, with each new database version, which is then committed to version control.

If teams can simply extend the same automated process already used to apply database changes during development to the Dev-Integration database, then Flyway’s object-level change tracking comes almost “for free” and delivers immediate value.

What teams gain

The schema model captures the database structure as a set of independent scripts, giving teams clear, auditable visibility into how each object changes from version to version. The following diagram shows object change tracking in GitHub:

Instead of reviewing long migration scripts in isolation, the schema model gives them a single place to track how individual database objects have evolved over time. This makes it much easier to understand when and why a change was introduced and reduces the time spent interpreting and cross-checking database updates.

Although the schema model captures the current state of the database, it is effectively stateless in the same way application code is stateless: it describes the result, not the history or execution order that produced it. This allows teams to reconcile the inevitable “messiness” of real-world development, safely resolving conflicts and merging changes, before they are turned into ordered migration scripts for downstream environments.

As a result, teams can:

• Trace historical datatype or column changes whose impact only became apparent later, through performance issues or changes in application behavior
• Identify index changes or additions that might aid performance
• More easily reconcile conflicting or overlapping changes early by checking which objects are affected by recent commits

Once changes move beyond the schema model and into versioned migration scripts, in the next step, execution order starts to matter, which is why reconciling differences early, before order is fixed, is so important.

Step 2: Improve the Quality and Reliability of SQL Migrations

In Step 2, Flyway turns database changes into reliable, versioned migrations and automatically surfaces high-risk SQL early, reducing uncertainty and deployment risk.

In many teams, SQL migration scripts are written by hand or generated indirectly through modelling tools or ORMs. As databases grow in size and complexity, these approaches become higher-risk. Even small oversights can result in missed dependencies, changes applied in the wrong order, or operations that have unintended side effects on performance, data integrity, or security. Without consistent validation, these issues tend to surface late in testing or during deployment, when they are hardest to diagnose and fix.

Large teams need systems where these small mistakes are caught early, before they affect code quality or slow down delivery. The same safeguards also make it easier for developers with different levels of experience to contribute safely and effectively, without increasing risk or review overhead.

Flyway can bring structure and reliability to how database changes are turned into SQL migrations, so that they can be deployed safely. Changes are treated as explicit, versioned transitions between known database states, and potential risks are surfaced early, reducing uncertainty around how a change will behave when deployed, without requiring major changes to how developers work.

Generate migrations between two known versions

With the latest development changes reconciled and saved in the schema model (Step 1), Flyway turns each set of changes into an ordered, versioned set of migrations.

Flyway uses its built-in schema comparison engine to determine what has changed between this development state and the current releasable version of the database, represented by the migrations folder, to capture the new development changes for release.

To do this, it will:

1. Build the current releasable version in the shadow database
2. Compare it with the schema model to get a list of object-level differences
3. Generate and verify the required migration (V) and undo (U) scripts, containing the exact changes needed to move forward to the next version or safely revert to the previous one.

Flyway’s schema comparison engine discovers all object-level differences and accounts for missing dependencies when generating the script. So, if you change a table and forget to update a dependent function, Flyway will notify you that it automatically included the function and amended it as required. It also warns of changes that may result in data loss.

The following example shows a warning raised in Flyway Desktop, caused by columns being dropped. You can automate the same workflow using the CLI. Either way, teams can review and address them before the change reaches testing or deployment.

Run automated code reviews

Flyway can automatically analyze pending SQL migration scripts and alert teams to any faults in the code before those scripts are used in testing or deployment. The aim is not to block change, but to ensure that risky or questionable SQL is identified early, when it is easiest to review and fix.

Flyway’s check -code command combines structural, parser-based analysis (SQLFluff) with pattern-based rules (regexes). Its built-in Enterprise rules library places a deliberate emphasis on catching high-risk changes that are easy to overlook during manual review but can cause serious problems if deployed. For example:

• Destructive changes that risk data loss, including dropped tables or columns and unsafe datatype modifications
• Security-sensitive changes, such as overly broad permissions or unexpected modifications to roles or users.
• Structural or design problems, such as finding tables with no Primary key or that lack documentation. These may not cause immediate failures, but can degrade performance or maintainability over time

The code reviews run automatically during migration generation, providing immediate feedback, and can also be integrated into an automated workflow, such as running on every pull request, using code like this:

flyway check -code -failOnError=true

Teams can easily add custom regex rules to enforce and maintain their own standards and coding practices.

What teams gain

Database changes are now captured automatically as discrete, versioned migrations, with Flyway validating that each new version of the database can be created successfully and checking the SQL for a range of potential issues.

Instead of ad-hoc scripts, tool-generated artefacts, or abstracted changes whose effects are hard to reason about, teams now have a set of tested, verified migration scripts designed to upgrade a target database from one known version to the next.

Deployments that follow a known, validated path between versions become more predictable and easier to test efficiently. Automated code reviews surface risky changes immediately, allowing teams to focus testing effort where it matters most. Regressions also become less frequent, as developers are far less likely to accidentally overwrite or remove changes made by others during merges.

Teams can measure this value directly using standard DORA metrics and other common indicators of code quality and delivery efficiency, such as:

• Higher test coverage — tests can be targeted at a clearly defined set of database changes
• Lower change failure rate — fewer escaped defects leading to late-stage fixes or rollbacks
• Shorter lead time for changes — less rework and faster review cycles for database changes
• Lower regression frequency — fewer unintended changes that cause existing database behavior to break
• Increased deployment frequency — predictable upgrades lower the risk of releasing changes more often

Next steps – Controlled Deployment with Drift Checks

With versioned migrations, automated code checks, and object-level visibility in place, teams now have the foundations for more stable and predictable online deployments. At this point, the remaining source of risk is often not the migration itself, but differences that have accumulated between database environments over time.

Each time Flyway successfully migrates a database to a new version, it can capture the resulting schema as an immutable, lightweight snapshot, providing a stable reference for what the database should look like at that version.

By comparing this reference with the schemas in other environments, Flyway can identify and help reconcile unintended differences before they cause problems. Addressing these discrepancies early removes one of the most common causes of deployment failures: environments that are assumed to be equivalent but are not.

Flyway integrates simply with all common CI/CD platforms, so these checks can be automated and applied consistently as part of an existing release process, without introducing new tooling or custom scripts. Datafaction (an affiliate of City National Bank), for example, was running monthly releases and deployment issues were routine rather than exceptional. They used similar drift detection and environment reconciliation techniques to reduce the failure rate to almost zero.

With these foundations in place, teams typically also find that release cycles shorten and the required deployment window shrinks, because deployments move from being cautious, manual events to predictable, validated migrations between known states

Summary

Introducing Flyway does not require a wholesale change to existing development practices. Instead, it allows teams to improve the reliability and consistency of database deployments incrementally, often addressing long-standing operational pain points without disrupting how developers work, day to day.

By integrating Flyway in a small number of incremental steps, teams working with complex or legacy databases can begin to regain control, reduce risk, and see measurable improvements quickly.

Starting with object-level visibility and traceable change history, then moving to validated migrations and automated code checks, teams establish a reliable foundation for better testing and safer, more predictable deployments.

Take the first step today. Whether you’re starting a trial or already evaluating Flyway Enterprise, these two steps can deliver measurable improvements in deployment reliability within days, not months: Start Your Free Trial | Talk to Us.

Tools in this post

Redgate Flyway

Bring stability and speed to database deployments

Find out more

Redgate Flyway Enterprise

Enterprise-grade automation to scale database delivery

Find out more