An e-book from a software company that explains when not to start a migration? That chapter belongs in it precisely because of that. Honesty over comfort: not every J2EE application has to go. And a migration at the wrong moment does more damage than standing still.
Four situations in which you are better off pausing.
The system is stable and barely changes
An application that does its job, gets a handful of small changes a year and will be functionally replaced or phased out before long does not deserve a migration. It deserves a controlled end of life.
The sensible investment is risk management: security patching in order, knowledge documented, an exit plan. In migration terms: retain or retire, deliberately keeping or deliberately phasing out.
Retain never means "do nothing"
Staying up to date is not a detail, not even for a system you deliberately keep. Within the supported range of runtime, server and libraries you close a relevant CVE in days. Years behind the last version that still gets patches, the next serious vulnerability costs you months of work before you can even patch.
Worth pausing on:
"It never changes anyway" is sometimes self-deception: a consequence of change having become too expensive, not of there being no need. Ask the business what it would want if changes were cheap. The answer tells you which category the system is really in.
The motivation is technological, not commercial
"The team would like to work with Kubernetes." "Everybody is talking about microservices." Those are signals to pause. Architecture decisions driven by what looks good on a CV are a real phenomenon. And an expensive hobby.
The test is simple: can you explain in one sentence which business problem the migration solves? And does the business recognise that problem? If not, the homework is not done.
This is chapter 4 of 14
The e-book also contains the decision framework for Spring Boot, Quarkus and modern Jakarta EE runtimes, the technical playbook, a chapter on AI in your migration and a roadmap in four phases. Free, three fields, the PDF opens right away.
Send me the e-bookThe organisation is not ready
A modern architecture assumes you can also operate it: automated pipelines, monitoring, teams that run their own services. Deploy microservices with the processes of a classic legacy system, one central release calendar and manual change procedures, and you get the downsides of both worlds.
The environment first, the framework after
So sometimes the right first step is not a framework migration but modernising what sits around the existing system: the platform and the pipeline, the way development teams are organised and the support they get from that platform. That delivers value immediately. And it lays the foundation a later migration needs to succeed.
Wanting everything at once
A framework migration plus a cloud migration plus microservices plus an organisational change, in one project? That is the recipe for years without intermediate value.
The rule of thumb: change no more than one big dimension per step. First the deployment model, only then split up the architecture. That is almost always safer than both at once. And after the first step the second often turns out to be smaller than expected.
Waiting is a decision too
This chapter is not a plea for postponement. The risks of legacy, the talent clock, the security pressure and the growing gap with what the organisation needs, do not disappear by waiting. They grow.
But the conclusion "we migrate" deserves the same critical test as the conclusion "we wait". The instrument for that is a structured assessment: it tells you per application whether keeping, upgrading, migrating or phasing out is the wisest route.
< Key insights />
- Stable systems with a finite horizon deserve risk management and an exit plan, not a migration.
- Without a nameable business problem a migration is a hobby. Without an organisational base, pipeline, monitoring and ownership, it is a gamble.
- Waiting is a decision with costs too: take it as deliberately as the decision to migrate.
< Questions for management />
- For which systems in our landscape is "controlled phase-out" more honest than "modernise"?
- If we do not migrate today: what is our plan for patching, knowledge retention and exit?
< From the e-book />
Evolve, don't rewrite
Modernising legacy Java with Spring Boot and Quarkus, without disrupting your business. Fourteen chapters for IT decision-makers and architects, written by Pieter Vercammen, Managing Partner and Tech Lead at CraftCode. With a decision framework for the framework choice, the strangler fig pattern, a technical playbook, the role of AI and a roadmap in four phases. Appendix A is an assessment checklist you can run against your own landscape.
This chapter appeared in full and unchanged, apart from the subheadings.< FAQ />