Stop Guessing What's Running in Production: A Fast Grails Estate Inventory

A Fact-Based Assessment Guide

This guide describes a fast, evidence-driven way to inventory a Grails estate. 

The goal is not to produce a perfect audit. It is to generate enough verified data to understand your current technical posture and where meaningful drift may already exist.

 In the advice that follows we urge caution  in adopting it without a basic understanding of your environment.  There are many ways for the information you need to be intentionally or unintentionally obfuscated. 

In practice, most of the useful signal comes from three areas: the Grails versions in production, the Spring Boot and Java baselines beneath them, and any plugins or dependencies that may constrain forward movement.

‍

Step 1: Establish the Grails Version Reality

Teams are often confident they know which Grails versions they run. In mature portfolios, that confidence is frequently optimistic. Services accumulate over time, ownership shifts, and older versions persist longer than expected.

Start by inspecting build descriptors (build.gradle or pom.xml) across your repositories and extracting the declared Grails versions. For most estates, a simple workspace-wide search is sufficient to surface the real distribution.

find . -name "build.gradle" -exec grep -H "grailsVersion" {} \; | sort -u

‍

or for Maven:

find . -name "pom.xml" -exec grep -H "<grails.version>" {} \; | sort -u

‍

What you are looking for is not perfection but shape. A single version line suggests relatively contained upgrade dynamics. Multiple major versions in parallel usually indicate higher coordination overhead later. Very old versions may warrant closer review depending on your support requirements.

By the end of this step, you should have a simple service-to-Grails version map.

‍

Step 2: Map the Spring Boot Baseline

Once the framework layer is clear, the next meaningful signal usually appears in the Spring Boot foundation. Grails releases are tightly coupled to specific Spring Boot lines, and the broader Java ecosystem tends to move with Spring’s expectations. Even when application code has remained stable, Boot drift can materially affect upgrade posture.

Inspect each service for its resolved Spring Boot version, paying particular attention to explicit overrides or unusual dependency management blocks. Inside a repository, Gradle’s dependency insight is typically the fastest way to confirm the effective version:

./gradlew dependencyInsight --dependency spring-boot

When reviewing your findings, it is useful to compare them against the typical Grails alignment shown below.

‍

Grails ↔ Spring Boot Compatibility (Typical Baselines)

‍

These pairings reflect the standard expectations of each Grails line. Deviations are not automatically incorrect, but they do deserve scrutiny, particularly where heavy version overrides are present or where older Boot generations remain widely deployed.

At the end of this step, you should understand whether your estate sits on a single Boot generation or spans multiple Boot generations.

‍

Step 3: Verify the Java Runtime Posture

One of the more common surprises in any long-running application is a mismatch between the JDK used to build it and the one used to run it. Over time, CI pipelines, container images, and production standards often evolve independently.

Confirm the configured toolchain in your builds and compare it with the JVM actually present in your runtime environment. Unfortunately this task can be hard to do due to the nature of the many ways that the Java runtime can surface.  

The following will help find Docker images that provide a Java runtime and the one after will help locate the original runtime level compiled for.  Neither of these simple searches will be completely conclusive and you should investigate more deeply to be sure.

find . -name "Dockerfile" -exec grep -Hi "^[[:space:]]*FROM .*java" {} \;
find . \( -name "build.gradle" -o -name "build.gradle.kts" \) \  -exec grep -H -E "sourceCompatibility\s*=" {} +

‍

You are looking for consistency more than novelty. Estates where build and runtime JDK majors diverge, or where multiple unsupported Java baselines persist, tend to experience more friction during modernisation work. Capturing this matrix early prevents surprises later.

‍

Step 4: Identify Plugin and Dependency Friction Points

The Grails plugin ecosystem remains a major productivity advantage, but in older estates, a small number of plugins often exert disproportionate influence on upgrade feasibility.

At this stage, scan for plugins that have seen little recent maintenance, heavily pinned dependencies, and any internal forks that may have quietly become long-term obligations. You do not need a perfect dependency audit; you are looking for obvious gravitational centres.

A typical, targeted search can quickly highlight known areas of concern:

find . -type d -name ".git" -execdir git grep "suspect-plugin-name" \;

‍
Plugins without releases in the past couple of years, or those tightly bound to older Grails majors, are worth noting for follow-up analysis.

‍

Step 5: Check for Platform Warning Signals

Before any migration work begins, it is worth examining whether the platform is already emitting early warning signs. These messages are easy to ignore in isolation, but often form a useful composite signal.

Search build logs, CI output, and startup scripts for common indicators such as illegal reflective access warnings, repeated deprecation notices, or forced dependency resolutions. Simple repository searches often surface the most important cases:

git grep -i "illegal reflective access"
git grep -i "deprecated"
git grep -i "WARNING:"

‍

The objective here is pattern recognition. A small number of warnings is normal in most estates. A growing cluster across many services usually indicates increasing ecosystem pressure.

‍

Interpreting the Overall Picture

Not every legacy component represents immediate risk, and not every warning demands urgent action. The value of this exercise lies in replacing assumptions with evidence.

As a general heuristic, estates where Grails, Spring Boot, and Java remain aligned and supported tend to have substantial runway. Environments showing growing version fragmentation, repeated runtime warnings, or ageing plugin dependencies usually benefit from earlier planning. Where core components are already beyond community support or where JVM baselines are inconsistent, the margin for delay is typically narrower.

Most real-world portfolios contain a mix of these conditions.

‍

What You Should Have at the End

After completing this inventory, you should have a grounded view of:

• Which Grails versions are actually deployed
  
  
• How they align with Spring Boot
  
  
• What Java baselines are in use at build and runtime
  
  
• Which plugins may constrain upgrades
  
  
• where early warning signals are already appearing

‍

‍

‍