Skip to content

< Free e-book · Evolve, don't rewrite />

Modernise your legacy Java without rewriting it all

A decision tree for Spring Boot, Quarkus or Jakarta EE, a roadmap in four phases and an honest answer to the question when you are better off waiting. For applications that still run on WebLogic, WebSphere or JBoss, with Java 8 or javax. Free PDF, one evening of reading.

Only in Dutch. Good to know: the e-book is only available in Dutch. Most of our clients and colleagues work in Dutch, so that is the language we wrote it in.

Send me the e-book Or read chapter 4 first, no e-mail needed

< The core />

Four positions, backed up in the book

Many Belgian organisations run business-critical applications on Java that is fifteen to twenty-five years old. They still work. The world around them changed.

01

Java is not the problem, your architecture is

A new release every six months and strong LTS versions in Java 21 and 25. "Away from Java" throws away decades of investment. The real problem is coupling, not age.

02

There is no best framework

Spring Boot, Quarkus or an upgrade within Jakarta EE. The answer follows from your workloads, your team and your horizon. The book hands you the decision tree, not a ranking.

03

Rewriting is almost always the wrong call

A big-bang rewrite takes years and only pays off at the end. Move functionality out of the old system step by step instead. Every step delivers value, every step is reversible.

04

Technology is only a third of the job

Swap the framework but leave the platform, the tests and the way of working alone, and you get a modern application with legacy problems. Application, platform and team move together.

Read the full summary

Many Belgian organisations run business-critical applications on Java technology that is fifteen to twenty-five years old. Those systems still do what they were built for. But the world around them has changed: cloud, containers, DevOps and a tight labour market make demands that classic J2EE and Java EE architectures were never designed for.

Java is not the problem, the architecture around it is

Java is alive: a new release every six months since 2017 and strong LTS releases in Java 21 and Java 25. Formulating "away from Java" as a goal throws away decades of investment, knowledge and a mature ecosystem. The real goal is away from heavy application servers, slow release cycles and an architecture where everything is entangled with everything else. Legacy is not about age. It is about too much coupling and too little cohesion. Keeping up with versions is first of all a security matter.

There is no universally best framework

Spring Boot is the de facto standard for modern enterprise Java: huge ecosystem, largest talent pool, proven migration path. Quarkus was built for the container era, excels in start-up time and memory footprint and stays close to the Jakarta EE APIs your Java EE team already knows. Sometimes an upgrade within Jakarta EE is the wisest first step. The right choice follows from your workloads, your team and your time horizon.

Rewriting is almost always the wrong answer

Big-bang rewrites of business-critical systems fail more often than they succeed. They take years, freeze the roadmap and only deliver value at the very end. The proven approach to legacy Java modernisation is incremental: lift functionality out of the legacy system piece by piece while old and new run side by side. Every step delivers value. Every step is reversible.

Modernisation is more than technology

Replace only the framework and leave the platform, the test strategy and the way of working untouched, and you get a modern application with legacy problems. A pipeline is the start, platform engineering is the destination, teams get ownership from code to production and every phase ends with a gate. You migrate for the business, not for the developer.

Pieter Vercammen, Managing Partner and Tech Lead at CraftCode, author of the e-book

< The author />

Written by someone who has done it

Pieter Vercammen has been building enterprise software for twenty years: almost five at Oracle as a developer and technical lead, then as a Java and ADF consultant, and today leading the technical teams at CraftCode. He knows the heavy middleware this book is about from the inside. He sits at the table with the board that has to decide as often as with the team that has to deliver.

The question this book answers:

Do we have to move away from Java, and if not, what do we have to change instead?

This book is what came out of those conversations. Including the ones where the answer was "not yet".
ISO 9001 certificate ISO 27001 certificate Great Place to Work label CraftCode is a Belgian software company from Edegem, part of Fieldside within the Cronos group. Our roots are in back-end development in Java.

< Who it is for />

Two readers, two routes

The decision-maker

You need to know whether and when modernising is worth it, and what standing still costs.

Start here

Part I for the why, chapter 8 for the decision framework, chapter 14 for the roadmap. Together about one evening.
Every chapter closes with questions for management, ready to take to your next board meeting.

The architect

You know where the coupling sits. You need an approach that works while the shop stays open.

Start here

Chapters 6 to 8 compare the frameworks without picking a winner. Chapters 9 and 10 are the playbook. Chapter 11 draws the line for AI.
Every chapter closes with points of attention for the architect.
The full table of contents Fourteen chapters, three appendices
Part I. Why modernise?
  • 1 Java has evolved, not disappeared
  • 2 Understanding the legacy: from J2EE to Jakarta EE
  • 3 The business case for modernisation
  • 4 When (not yet) to migrate Free to read
Part II. The modern Java landscape
  • 5 Modern Java in 2026
  • 6 Spring Boot: the pragmatic standard
  • 7 Quarkus: Java for the container era
  • 8 Choosing: a decision framework
Part III. Migration in practice
  • 9 Migration strategies: evolve, don't rewrite
  • 10 The technical playbook
  • 11 AI in your migration: accelerator, not pilot
  • 12 People, process and platform
  • 13 Pitfalls: where migrations really fail
  • 14 From plan to practice: a phased roadmap

Plus the conclusion and three appendices: the assessment checklist, a glossary and a reading list.

< FAQ />

Questions about modernising legacy Java

Should we move away from Java? Almost never. Java ships a new release every six months and Java 21 and 25 are strong LTS versions. What usually has to go is the architecture around it: heavy application servers, slow release cycles and code where everything is entangled with everything else. Legacy is a matter of coupling, not of language.
Spring Boot or Quarkus: which one should we choose? There is no universal winner. Spring Boot has the largest ecosystem and the largest talent pool. Quarkus starts faster, uses less memory and stays close to the Jakarta EE APIs a Java EE team already knows. Sometimes an upgrade within Jakarta EE beats both. The choice follows from your workloads, your team and your time horizon, not from what is trending.
Is it better to rewrite a legacy Java application or migrate it step by step? Step by step, in almost every case. Big-bang rewrites of business-critical systems fail more often than they succeed, freeze the roadmap for years and only deliver value at the very end. Incremental migration behind a routing layer, the strangler fig pattern, delivers value at every step and keeps every step reversible.
When should you not migrate a legacy system? In four situations: the system is stable and barely changes, the motivation is technological rather than commercial, the organisation lacks the pipeline and ownership to run a modern architecture, or you want to change everything at once. A stable system with a finite horizon deserves risk management and an exit plan, not a migration.
How do you migrate from javax to jakarta? Mostly automatically. The namespace change from javax to jakarta is mechanical, so OpenRewrite, the Eclipse Transformer and Konveyor handle the bulk of it. What is left is the part that needs judgement: shared databases, integration points and behaviour nobody documented. Budget your time for that second half, not for the find and replace.
Can AI carry out a Java migration? As an accelerator, not as a pilot. AI is reliable where the output is verifiable and the impact is limited: bulk transformations, boilerplate, test generation and reading unfamiliar code. Service boundaries, the data model and transaction semantics stay human decisions. The sharper your gates, the more autonomously AI can work.
Is the e-book in English? Not yet. The current edition is in Dutch and an English one is planned. Leave your details and we will notify you when it is ready.
Is the e-book really free? Yes. You pay with three fields. The summary on this page and the chapter on when not to migrate are readable without any form at all.
Will someone from CraftCode contact me? Maybe, and we would rather say so. Modernising Java is our work, so for some readers a conversation is the logical next step. If we get in touch, it is about your situation, not a standard pitch. One "no thanks" is enough, and you can unsubscribe from the e-mails with one click.

Ready to choose between evolving and rewriting?

The e-book gives you the decision tree, the roadmap and the checklist to hold your own landscape against. Free, three fields, the PDF opens right away.

Send me the e-book

Rather know where your landscape stands right away?

See how we map your landscape

Get the e-book (Dutch)

PDF, 14 chapters, free