Free Grails Upgrade Assessment — know your path off an end-of-life version

What you get

• A written summary of your upgrade path: which version to target and in what stages, based on your current version and setup
• A review of your plugin and dependency list. Which plugins are still maintained, which have jakarta-compatible replacements, and which are dead and will need rewriting. In our experience this is where most Grails 2/3 upgrades fail
• The risks we would want to investigate first. Depending on the application this might be GORM behaviour changes, the javax to jakarta migration, an old Spring Security Core version, or GSP and taglib changes
• A 30-minute call to go through it with your team. The summary is yours to use, with us or with anyone else

How it works

1. Tell us where you are. Send your current Grails version, your plugin and dependency list (build.gradle or BuildConfig.groovy), rough codebase size, and anything unusual you already know about, such as custom plugins or external integrations.
2. We review it. The review is done by a senior engineer. If you’re able to give us read-only access to the code under NDA, the assessment will be considerably more useful: a dependency list tells us which plugins are dead, but only the code shows how much work it will be to replace them.
3. You get the summary and a call. Written findings, usually within a week, then 30 minutes to talk them through. If we’ve only seen build files, any effort figures will be ranges and labelled as such. Even with full code access an estimate is still an estimate; legacy migrations sometimes turn up complications nobody could have seen. We prefer to say that here rather than have you find it out later.

“Can’t we just follow the official upgrade guide?”

Quite possibly, and if we think you can, we’ll say so. The official documentation covers 3.3 through to 7 step by step, and for a small application without many plugins that may be all you need. Where it gets harder is when plugins have been abandoned with no jakarta-compatible replacement, or the codebase is on 2.x and predates the documented upgrade path entirely. Some of that we can see from your dependency list. Custom GORM behaviour and accumulated workarounds we can only see in the code, which is why we ask what you’re able to share. Either way you’ll start the project knowing which parts are likely to cause trouble.

“We’re on extended-support patches — do we still need this?”

Extended support (available for Grails 6.2.x and 7.x only) keeps known CVEs patched, and for some businesses that’s the right call for a year or two. But you’re still on frozen APIs, an ageing Java baseline, and a shrinking pool of developers willing to work on the old versions. The assessment tells you what the eventual move looks like, so you can decide when to make it with actual numbers in front of you.

Who does the work

Senior engineers only — the same people who’ve shipped Grails systems since 2011. No account managers, no juniors learning on your codebase. You’ll deal directly with the engineer doing the analysis.

Testimonial: We worked with Dave Brown and his team on a four month project to upgrade our 20 year old grails application to the latest version.
Dave demonstrated considerable expertise and knowledge throughout the project and met all project milestones on time. We have been very impressed with the quality of his work and the upgraded application is live and being used by a range of clients. We would be pleased to recommend his services.
When we have approached him with queries, he has always very responsive and this is the start of a long term working relationship.

Daryl Hickman – Director (Mapolitical)

FAQ

• Is it really free? What’s the catch? No catch. It’s how we start conversations: some assessments turn into upgrade projects with us, most just leave a team better informed. We limit it to one per organisation.
• Which versions do you cover? Any version since Grails 1.x, including 2.x applications that predate the current documented upgrade path.
• Do you do the upgrade itself? Yes — that’s most of our Grails work. The assessment exists so both of us understand the scope before anyone commits to anything.
• What if you find the app shouldn’t be upgraded? We’ll say so. Sometimes the right answer is a rewrite in Spring Boot, or extended-support patches for another year while you plan. We’ll give you the recommendation we’d give our own business.
• Do you need access to our code? It helps enormously, and for an accurate effort estimate it’s the only way. A dependency list shows us which plugins are dead; the code shows how much work replacing them will actually be, and how much custom GORM and metaprogramming there is. We can start from whatever you’re comfortable sharing. Version and dependency list alone gets you a useful risk review with rough ranges. Read-only code access under NDA (we’re UK-registered, company no. 7681233) gets you something much more reliable. Either way an estimate is an estimate, and legacy migrations do occasionally surprise everyone, including us.