Grails 8: What’s Coming and How to Prepare Your Upgrade Path

Grails 8 is almost here, built on Spring Boot 4, Spring Framework 7, and Groovy 5, and requiring Java 21. Every one of those is a major-version jump, so if you’re running Grails 7 — whose maintenance support ends in June 2026 — this upgrade is worth planning for rather than deferring. Here’s what to expect.:

• Java 21 requirement (or Java 25 for Micronaut users).
• Switch to Gradle 9 and native dependency management.
• New Jackson 3 JSON library and tighter Groovy type checking.
• Deprecated features removed, including @MockBean, @SpyBean, and older enum serialisation formats.
• Servlet 6.1 adoption, requiring Tomcat 11 or Jetty (Undertow is no longer supported).

If your app depends on plugins like grails-spring-security or SiteMesh 3, compatibility issues may arise. A phased upgrade – starting with Grails 7, resolving deprecations, and updating your JDK and build tools – is the safest approach. Testing is critical, particularly for API behaviour, enum serialisation, and Kubernetes readiness probes.

For enterprises, staying on unsupported versions is a compliance risk. Begin planning now to avoid disruptions and ensure a smooth transition to Grails 8.

Key Features and Changes in Grails 8

Grails 8 introduces updates that impact every layer of applications built on the platform. Familiarising yourself with these changes can help your team navigate the upgrade process more effectively.

Platform and Runtime Updates

Grails 8 now requires Java 21, a step up from JDK 17 in Grails 7. If you’re using Micronaut features, you’ll need to upgrade further to JDK 25 or later. This is because Micronaut 5 relies on the finalised ScopedValue API (JEP 506).

On the build side, Grails 8 moves to Gradle 9, replacing the older Spring Dependency Management plugin with Gradle’s native platform() support. It also introduces a new bom-property-overrides plugin, which simplifies managing BOM version overrides, previously handled in gradle.properties.

Other updates include liveness and readiness probes enabled by default on the Health endpoint, which is especially helpful for Kubernetes users, and log files now defaulting to the UTF-8 charset.

These foundational changes pave the way for further updates detailed below.

Framework Changes

Grails 8 adopts Spring Boot 4.0.x and Spring Framework 7.0.x, leading to structural shifts. For instance, the previously monolithic spring-boot-autoconfigure module is now divided into domain-specific modules like spring-boot-webmvc, spring-boot-servlet, and spring-boot-mongodb. This requires updates to auto-configuration package references.

The default JSON library has also changed to Jackson 3 (tools.jackson.*), replacing Jackson 2. The new auto-configured bean is JsonMapper, which uses a builder pattern for construction. While Jackson 2 annotations are still temporarily compatible, direct usage of the mapper will need adjustments. For a smoother transition, you can enable the spring.jackson.use-jackson2-defaults: true toggle.

In alignment with Jakarta EE 10, Grails 8 moves to Servlet 6.1. However, Undertow is no longer supported until it achieves Servlet 6.1 compatibility, so you’ll need to switch to Tomcat 11 or Jetty.

Deprecated and Removed Features

Several features have been deprecated or removed to streamline the framework and improve performance.

• The @MockBean and @SpyBean annotations are now replaced by @MockitoBean and @MockitoSpyBean. Additionally, @SpringBootTest no longer auto-configures MockMvc, so you must explicitly add @AutoConfigureMockMvc to test classes that rely on it.
• Spring’s theme infrastructure (ThemeSource and ThemeResolver) has been removed. Applications requiring CSS or asset switching will need custom solutions.
• Enum serialisation defaults have shifted to a simpler string output using SimpleEnumMarshaller, replacing the verbose object format used in earlier versions.

The table below summarises key changes:

It’s worth noting that some plugins, such as grails-spring-security and SiteMesh 3, are currently incompatible with the Spring Boot 4/Spring 7 baseline (as of mid-2026). If your application relies on these, you may need to explore workarounds or wait for updated plugin releases.

These changes highlight the importance of careful planning, including managing Hibernate and database migrations, to ensure a smooth transition to Grails 8.

Preparing for the Grails 8 Upgrade

To make the transition to Grails 8 as smooth as possible, it’s crucial to prepare your existing environment. This involves tidying up your codebase, aligning your tools, and reviewing dependencies. A well-planned upgrade starts with updating to Grails 7, configuring your toolchain, and auditing all dependencies.

Upgrade to Grails 7 First and Address Deprecations

Before diving into Grails 8, ensure your application is running on the latest Grails 7.x version. It should also be compatible with Java 17 and Groovy 4, with no unresolved deprecation warnings. Since Grails 8 removes deprecated features, tackling these warnings now is essential.

Start by adding the org.springframework.boot:spring-boot-properties-migrator dependency as runtimeOnly in your build.gradle file. Running the application will log any configuration property warnings in your application.yml or application.groovy. Once these warnings are addressed, you can safely remove the dependency.

Next, review and update code-level deprecations. For instance, replace the @AutoTimestamp annotation with @CreatedDate and @LastModifiedDate, introduced in Grails 7.1. Similarly, migrate from grails.web.JSONBuilder to Groovy’s JsonBuilder. Don’t forget to audit your GSP tag libraries – tags like g:createLinkTo should be updated to g:createLink. These changes will help streamline the upgrade process.

Update JDK, Build Tools, and Deployment Configuration

Once your codebase is cleaned up, it’s time to update your runtime environment and build tools. Grails 8 requires JDK 21 as the minimum version for building and running applications. If your application uses Micronaut integration, you’ll need JDK 25 due to its reliance on the finalised ScopedValue API. To check your local JDK installations, run:

./gradlew javaToolchains 

This command will confirm whether your setup meets the required versions.

On the build tools side, ensure you’re using Gradle 8.14.3 or later. Update your WAR configuration by replacing providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' with providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat-runtime'. Additionally, remove any CLASSIC loader blocks from your build.gradle file.

Review Dependencies and Extensions

With your codebase and tools in order, the next step is to audit your third-party dependencies and plugins. Not all dependencies will be compatible with Grails 8, so identifying potential blockers early can save time and effort.

Start by reviewing high-risk items. For example, grails-spring-security and SiteMesh 3 are incompatible with the Spring Boot 4/Spring 7 stack. If your application relies on these, you’ll need to either wait for updated releases or implement temporary workarounds. For MongoDB users, update your configuration files by renaming all spring.data.mongodb.* properties to spring.mongodb.*. Additionally, if your application references Spring’s Hibernate 5 support classes directly, update imports from org.springframework.orm.hibernate5 to org.grails.orm.hibernate.support.hibernate5.

A practical strategy is to categorise dependencies by risk – critical, moderate, or low. This prioritisation helps focus your efforts and gives stakeholders a clear understanding of the upgrade’s scope.

Step-by-Step Upgrade Process

With your groundwork laid, it’s time to implement and verify your Grails 8 upgrade. This stage requires careful planning and execution.

Planning Your Upgrade Approach

You need to decide whether to upgrade your system in-place or run parallel instances. An in-place upgrade directly migrates your existing codebase to Grails 8, while a parallel approach involves maintaining a Grails 8 branch alongside your current production application. The latter allows you to gradually shift traffic once you’re confident in its stability. For teams that require high uptime, the parallel method is often the safer option.

Define clear success criteria for the upgrade. These should include milestones like successful compilation, passing all tests, consistent API behaviour, and unchanged database migration processes. Without these benchmarks, it can be hard to determine when the upgrade is complete. A well-structured plan ensures a smooth upgrade process.

Carrying Out the Upgrade

Begin by updating your gradle.properties or build.gradle to reference the Grails 8 release. Then address the following updates:

• Spring Boot 4 auto-configuration imports: Auto-configuration classes are now split into domain-specific modules like spring-boot-webmvc and spring-boot-mongodb. Update any direct imports to reflect these changes.
• Test mocking annotations: Replace @MockBean and @SpyBean with @MockitoBean and @MockitoSpyBean from org.springframework.test.context.bean.override.mockito. Declare these fields directly in your test classes.
• MockMvc and TestRestTemplate: @SpringBootTest no longer auto-configures these components. Add @AutoConfigureMockMvc or @AutoConfigureTestRestTemplate explicitly to any test class that requires them.
• Jackson 3 changes: The default mapper is now JsonMapper, and its base package has shifted to tools.jackson.databind. Additionally, JacksonException is now an unchecked RuntimeException, which may impact your error-handling logic.

If your application uses Undertow as its embedded server, you’ll need to switch to Tomcat or Jetty. Undertow is not supported in Grails 8 due to its incompatibility with Servlet 6.1.

Testing and Hardening After the Upgrade

Once your application compiles and runs, it’s time for thorough testing. This phase often reveals subtle issues.

Start with a full regression test suite. Pay close attention to enum serialisation. The default setting has changed to SimpleEnumMarshaller, which outputs simple strings like “SUBMIT” instead of verbose type metadata. Validate JSON responses to ensure they meet the expectations of API clients. If any clients rely on the old format, they may require updates.

Check your health endpoints as well. Liveness and readiness probes are now enabled by default in Spring Boot 4. These changes could affect Kubernetes deployments or load balancer configurations if your infrastructure wasn’t designed for them. If these probes aren’t needed, disable them in your configuration.

Finally, conduct a performance benchmark against your Grails 7 baseline. Changes introduced in Spring Boot 4 and Spring Framework 7 may alter the request lifecycle. Verify that response times and memory usage remain within acceptable limits before moving the upgrade to production. These tests are critical for confirming the upgrade’s stability and performance.

“The Spring Boot properties migrator… is the fastest way to find deprecated or relocated configuration properties in your application.yml.” – Grails Documentation

Once you’ve resolved all warnings flagged by the properties migrator, remove it from your dependencies. It’s a diagnostic tool, not something intended for long-term use.

Enterprise Considerations for Grails 8 Adoption

Adopting Grails 8 isn’t just a technical upgrade; it’s a decision with broader organisational and compliance implications.

Risk Management and Compliance

Transitioning to Grails 8 involves more than just updating code. By June 2026, Grails 7 will no longer receive active maintenance. This lack of support can raise red flags during compliance audits, as unsupported software is often seen as a liability.

Grails 8 addresses several compliance challenges head-on. It supports Jakarta Servlet 6.1 (via Tomcat 11), enables reproducible builds through the SOURCE_DATE_EPOCH environment variable, and integrates CycloneDX for SBOM licence mapping. These features are critical for sectors that require transparency in their software supply chains. Additionally, upgrading to Java 21 ensures access to the latest long-term security patches, reducing risks tied to outdated runtimes.

For organisations unable to upgrade immediately, commercial end-of-life support for Grails 7 is available. However, this should only serve as a short-term solution. A phased, multi-quarter upgrade plan is recommended, prioritising applications based on their security exposure.

“Treat the dependency cliff as a critical engineering constraint and allocate resources accordingly.” – Steve Poole, HeroDevs

To minimise risks, start with less critical services, thoroughly test the upgrades, and then move to core systems. It’s also crucial to have a documented rollback strategy, such as the parallel-branch approach discussed earlier, to handle any unexpected issues that arise during production.

While these compliance measures are vital, preparing your team for the technical changes in Grails 8 is equally important.

Team Training and Knowledge Transfer

The updates in Grails 8 are substantial, and assuming that existing knowledge will suffice is a risky approach. Teams need proper training to adapt to the new tools and frameworks.

“Upgrading Grails means upgrading Spring Boot, which means upgrading Java, which means re-validating every integration point, every test suite, every deployment pipeline.” – Steve Poole, HeroDevs

Key areas for training include the transition from Jackson 2 to Jackson 3 (with its package changes and immutable JsonMapper builders), understanding the modularisation in Spring Boot’s autoconfiguration, and working with the updated testing infrastructure, such as @MockitoBean and @MockitoSpyBean. Developers must also adapt to Groovy 5’s stricter @CompileStatic type checking, which may reveal compilation errors that weren’t flagged before.

If your stack integrates Micronaut, ensure the team is aware of its JDK 25 requirement (beyond JDK 21) due to dependencies on the Scoped Values API. Overlooking this detail has caused NoClassDefFoundError issues in early adoption scenarios. Updating CI/CD pipelines to reflect the correct JDK version early can help avoid these pitfalls.

Embedding knowledge transfer within the upgrade process is often more effective than separate training sessions. Pair experienced developers with those less familiar with the new APIs, and treat the migration as a practical learning opportunity. Document decisions around plugin compatibility and configuration changes to ensure the knowledge is shared across the team, not confined to those directly involved in the upgrade. This collaborative approach reinforces the broader upgrade strategy.

How Tucanoo Solutions Ltd Can Help with Grails 8 Migration

Grails 8 brings significant changes to its framework, demanding a detailed and deliberate approach to migration. Tucanoo Solutions Ltd, with its extensive experience from Grails 1.x to the latest release, has successfully handled a wide range of upgrades, new builds, and legacy system conversions. This expertise allows them to craft a customised and effective upgrade plan tailored to each project.

Assessment and Upgrade Roadmap

Before diving into migration, it’s essential to fully understand the existing setup. Tucanoo carries out comprehensive audits of codebases, examining areas like system architecture, GORM data modelling, security configurations, and CI/CD pipelines. This thorough review helps identify potential obstacles early, avoiding surprises during the migration process.

Take the example of Shogo’s ecommerce platform migration from Grails 2.1 to Grails 4.x. This platform handles over US$25 billion in sales data and manages 12 million accounting entries. Tucanoo adopted a phased strategy for this project. They first ensured the existing functionality worked on the updated version, then restructured the system into a four-tier architecture: Core, REST API, Web, and a React JS front-end. This redesign improved scalability and reduced server load on AWS. This step-by-step approach reflects Tucanoo’s commitment to careful planning and execution, ensuring a smooth transition.

“Tucanoo use efficient planning tools to track software development so that all concerned with a project know the state of play – what issues are outstanding and what has been accomplished.” – Dr. Richard Tannenbaum, CEO, Propertissimo

Their upgrade roadmap incorporates best practices developed from earlier migrations, addressing namespace and package-level changes introduced with Grails 8.

Implementation and Ongoing Support

Once the roadmap is in place, Tucanoo handles the migration with precision, updating configurations, refactoring code, implementing automated tests, and setting up CI/CD pipelines. Post-migration, they continue to provide consultancy, debugging, and quality assurance to ensure the application remains stable as it adapts to the new framework.

A key strength of Tucanoo’s approach is their focus on empowering internal teams. Instead of creating long-term dependency on external support, they provide developers with the knowledge and tools needed to independently manage the upgraded system.

“Dave collaborated across timezones and provided the tools and insights needed.” – Anil Nair, CTO, Lifelink Systems

“David is also very professional as he has a keen interest in quality, focusing on automated tests, and he didn’t hesitate to go the extra mile to ensure the long term viability of our application.” – Sébastien Galtier, Project Manager, United Nations

This emphasis on sustainability is particularly critical for Grails 8. By prioritising automated testing, clean configurations, and thorough documentation, Tucanoo ensures that any issues are addressed during migration, preventing potential problems from arising in production.

Conclusion: Key Takeaways and Next Steps

Grails 8 brings a host of updates that make it far more than a simple version change. With the shift to Java 21 (or Java 25 for Micronaut users), Spring Boot 4, and Spring Framework 7, this upgrade impacts your runtime environment, dependencies, ORM, and testing setup. It’s a significant leap, not just a routine update.

This transition requires careful planning and execution:

“Upgrade is an action, not a strategy. Treating it as a strategy rather than an action ignores the complexity of real-world systems.” – Steve Poole, HeroDevs

As outlined earlier, starting with dependency audits and updating CI/CD pipelines is crucial. Teams that address deprecation warnings in Grails 7 and update their toolchains before making changes to production code will navigate the process more smoothly. With Grails 7 support ending in June 2026, it’s wise to begin preparations now.

For applications with complex architectures, heavy data demands, or dependencies on plugins like grails-spring-security or SiteMesh 3, a phased and well-documented approach is essential to avoid disruptions.

Tucanoo Solutions Ltd has been supporting organisations with Grails migrations since the early days of Grails 1.x. Their expertise spans codebase audits, implementation, and knowledge transfer. If you’re planning your Grails 8 upgrade and need professional guidance – whether for assessment, implementation, or ongoing support – reach out to Tucanoo Solutions Ltd to discuss your specific needs. Following the steps outlined in this guide will help ensure a secure and efficient upgrade path.

FAQs

Do I need a phased upgrade, or can I jump straight to Grails 8?

Upgrading to Grails 8 involves significant changes, including updates to Spring Boot 4.0.x, Spring Framework 7.0.x, and Java 21. These updates introduce breaking changes, making a phased approach a smarter choice – particularly for teams upgrading from versions earlier than Grails 7.

For organisations managing several applications, handling the upgrade as a well-structured programme can help ensure smoother transitions while keeping projects stable. This method allows teams to tackle challenges systematically, minimising disruptions along the way.

What will break first in my app when moving to Spring Boot 4 and Jackson 3?

Upgrading to Spring Boot 4 and Jackson 3 can introduce challenges in three main areas:

• Serialization tests: Jackson 3 has shifted its group IDs and package names from com.fasterxml.jackson to tools.jackson, which can interfere with data mapping in existing tests.
• javax.* imports: These imports must now be replaced with jakarta.* to comply with Jakarta EE 11 standards.
• Deprecations: Spring Boot 4 eliminates all features deprecated in the 3.x versions, which means any code depending on these will no longer work.

How can I check whether my plugins and dependencies are Grails 8 compatible?

To ensure compatibility with Grails 8, include the Spring Boot properties migrator as a runtimeOnly dependency. This tool helps by logging warnings about any deprecated or relocated configuration properties in your application files.

Additionally, go through your codebase carefully to identify updates related to Spring Boot 4.0.x and Spring Framework 7. Pay particular attention to relocated auto-configuration packages. Also, verify that your setup meets the new minimum requirement of Java 21.