Set spring.flyway.enabled=false in the profile-specific configuration file. For example, to disable Flyway in the test profile, add that property to application-test.properties or application-test.yml. When the application starts with that profile active, Spring Boot will skip Flyway's automatic migration execution entirely.

# application-test.properties
spring.flyway.enabled=false

1# application-test.yml
2spring:
3  flyway:
4    enabled: false

That single property is all it takes. The rest of this article covers the details: how profiles interact with Flyway, alternative approaches for more complex setups, and the traps that catch teams in production.

How Flyway Integration Works in Spring Boot

Spring Boot auto-configures Flyway when it detects org.flywaydb:flyway-core on the classpath. On startup, the FlywayAutoConfiguration class creates a Flyway bean, points it at the configured datasource, and calls flyway.migrate(). This happens before any JPA/Hibernate initialization so that the schema is ready when entity managers start.

The spring.flyway.enabled property controls whether this auto-configuration runs. When set to false, Spring Boot does not create the Flyway bean at all, and no migration SQL executes.

Profile-Specific Configuration Files

Spring Boot resolves configuration in a well-defined order. Profile-specific files override the base application.properties or application.yml:

1application.properties          <- base (always loaded)
2application-dev.properties      <- loaded when dev profile is active
3application-test.properties     <- loaded when test profile is active
4application-prod.properties     <- loaded when prod profile is active

Properties in a profile-specific file take precedence over the base file for the same key. This means you can keep spring.flyway.enabled=true (or omit it, since true is the default) in your base configuration and override it to false only in the profiles where you want Flyway disabled.

Full Configuration Example

Here is a typical multi-profile setup:

# application.properties (base)
spring.datasource.url=jdbc:postgresql://localhost:5432/myapp
spring.flyway.locations=classpath:db/migration

# application-dev.properties
# Flyway runs normally in dev (inherits default enabled=true)
spring.datasource.url=jdbc:postgresql://localhost:5432/myapp_dev

1# application-test.properties
2# Disable Flyway for integration tests
3spring.flyway.enabled=false
4spring.datasource.url=jdbc:h2:mem:testdb

# application-prod.properties
# Flyway runs in production
spring.flyway.locations=classpath:db/migration,classpath:db/migration/prod

Activate a profile at startup through any of these methods:

1# JVM system property
2java -jar myapp.jar -Dspring.profiles.active=test
3
4# Environment variable
5export SPRING_PROFILES_ACTIVE=test
6java -jar myapp.jar
7
8# Gradle
9./gradlew bootRun --args='--spring.profiles.active=test'
10
11# Maven
12mvn spring-boot:run -Dspring-boot.run.profiles=test

Using YAML Multi-Document Syntax

If you prefer a single YAML file over multiple profile-specific files, use Spring Boot's multi-document syntax with the spring.config.activate.on-profile key:

1# application.yml
2
3spring:
4  datasource:
5    url: jdbc:postgresql://localhost:5432/myapp
6  flyway:
7    locations: classpath:db/migration
8
9---
10spring:
11  config:
12    activate:
13      on-profile: test
14  flyway:
15    enabled: false
16  datasource:
17    url: jdbc:h2:mem:testdb
18
19---
20spring:
21  config:
22    activate:
23      on-profile: prod
24  flyway:
25    locations: classpath:db/migration,classpath:db/migration/prod

The --- separator creates distinct configuration documents within a single file. The on-profile key replaces the older spring.profiles syntax that was deprecated in Spring Boot 2.4.

Disabling Flyway Programmatically

For advanced scenarios where a boolean property is not flexible enough, you can exclude Flyway's auto-configuration class:

1@SpringBootApplication(exclude = FlywayAutoConfiguration.class)
2public class TestApplication {
3    public static void main(String[] args) {
4        SpringApplication.run(TestApplication.class, args);
5    }
6}

Or conditionally exclude it using a profile-specific configuration class:

1@Configuration
2@Profile("test")
3public class TestConfig {
4
5    @Bean
6    public FlywayMigrationStrategy flywayMigrationStrategy() {
7        // Return a no-op strategy instead of disabling Flyway entirely
8        return flyway -> {
9            // Skip migration but keep the Flyway bean available
10        };
11    }
12}

The FlywayMigrationStrategy approach is useful when you want the Flyway bean to exist (for example, to call flyway.clean() in test setup) but do not want automatic migration on startup.

Comparison of Approaches

Testing Without Flyway

When Flyway is disabled in tests, you need an alternative way to set up the database schema. Common approaches include:

1# Let Hibernate generate the schema from entity classes
2spring.jpa.hibernate.ddl-auto=create-drop
3
4# Or use a schema.sql file
5spring.sql.init.mode=always
6spring.sql.init.schema-locations=classpath:schema.sql

For Spring Boot integration tests using @SpringBootTest, annotate the test class with the profile:

1@SpringBootTest
2@ActiveProfiles("test")
3class UserServiceIntegrationTest {
4
5    @Autowired
6    private UserService userService;
7
8    @Test
9    void shouldFindUserById() {
10        // Flyway is disabled, schema managed by Hibernate ddl-auto
11        User user = userService.findById(1L);
12        assertNotNull(user);
13    }
14}

Common Pitfalls

Environment variables overriding profile-specific properties. The environment variable SPRING_FLYWAY_ENABLED=true takes precedence over application-test.properties because environment variables have higher priority in Spring Boot's property resolution order. If Flyway runs despite your profile setting it to false, check for conflicting environment variables or command-line arguments.

Forgetting that Flyway creates its schema history table. Even on first run, Flyway creates the flyway_schema_history table. If Flyway is disabled in a profile, that table does not exist. Other code or scripts that query this table will fail. Design your tests to not depend on it.

Running tests against a database that expects migrations. When Flyway is disabled, the database starts empty. If your tests assume tables exist, use spring.jpa.hibernate.ddl-auto=create-drop or a test-specific schema.sql to bootstrap the schema.

Using the deprecated spring.profiles key in YAML. In Spring Boot 2.4+, spring.profiles inside a YAML document was replaced by spring.config.activate.on-profile. Using the old key may cause the profile activation to silently fail, leaving Flyway enabled when you expect it to be off.

Activating multiple profiles with conflicting Flyway settings. If both dev and test profiles are active and application-dev.properties enables Flyway while application-test.properties disables it, the last profile listed wins. Be explicit about profile ordering or avoid contradictory settings across profiles.

Summary

• Set spring.flyway.enabled=false in a profile-specific configuration file to disable Flyway for that profile.
• Use profile-specific .properties or .yml files, or the multi-document YAML syntax with spring.config.activate.on-profile.
• For tests, pair disabled Flyway with spring.jpa.hibernate.ddl-auto=create-drop or a schema.sql to ensure the database schema is available.
• Watch out for environment variables and command-line arguments that override your property file settings.
• The FlywayMigrationStrategy bean offers a middle ground where the Flyway bean exists but does not run migrations automatically.