Java EE and Jakarta EE
This page covers one narrow thing: enterprise Java that depends on an application server, meaning JBoss, WildFly, WebLogic, WebSphere or GlassFish. If you run an estate like that, it still works, and it has become risky to change, you are in the right place. For Java in general you want our Java page instead.
01Capabilities
Four jobs on an estate the application server is holding up
Deliberately narrow scope. Anything general about Java, Spring Boot, a new system or how to structure one belongs on our Java development page. This page is about estates where the application server is part of the architecture, and where that single fact is the reason change has become expensive.
- Currency
Keeping an estate supportable while it keeps running
Applications on a server several major versions behind, usually with a Java version to match. Patch currency, database connection settings, the quirks of how classes get loaded, and a release process only one person fully understands. That is legacy modernization in the most literal sense of the phrase.
- Rename
The javax to jakarta package rename
Renaming the references is the mechanical part and it is not the work. The work is the server upgrade underneath it, the outside libraries that never published a renamed version, and proving that transaction and security behaviour did not quietly change on the way through.
- Extraction
Carving one piece off the server at a time
Moving a single endpoint or a scheduled job onto a plain Java runtime behind a stable interface, so the estate shrinks a piece at a time. This is how a migration becomes a series of reversible decisions instead of one large irreversible one nobody wants to sign.
- Interfaces
The message queues and contracts other systems depend on
Queues, scheduled batch runs and the older-style service contracts other systems still call. In fintech and logistics ERP estates these usually have callers nobody has a list of. We do this work under an ISO 27001:2022 certified information-security management system.
02Fit
Keep it, raise the floor, or start pulling pieces out
Straight answer first: Jakarta EE is still specified and still maintained, and the centre of gravity for new enterprise Java moved to Spring Boot and lighter runtimes years ago. That makes this a legacy-leaning position, and the useful questions are about what to keep, what to move, and what to stop paying for. Each row below is the call we would make for that estate.
| Your situation | What we recommend |
|---|---|
| An estate that depends on the server, runs the business, and has to keep running | Work in placeRaise the floor, get the behaviour under test, and extract only where there is a stated business reason for it. |
| Your question is general Java: a new system, Spring Boot, how to structure it | Different pageOur Java development page covers it, and the application server is not part of your decision at all. |
| You are starting a brand new enterprise system today | Start on Spring BootSpring Boot has the deeper ecosystem, the larger hiring pool and better operational tooling, and it is what we would build a new system on. |
| The only real blocker is an unsupported server and the package rename | Keep it containedA rename and a server upgrade is a contained project. Bundling a redesign into it is how it becomes a two-year programme with no release in the middle. |
| The way the business is modelled is wrong, not merely old | Rewrite, for thatA rewrite is justified, and for that reason rather than because a package name is out of date. That is the worst justification we hear. |
| The estate is patched, stable, and simply out of fashion | Keep the estateSpend the money on the systems where change is genuinely blocked. Fashion is not a maintenance cost and should not be budgeted like one. |
Scope
What we own here is the plan and its consequences. How transactions and access control behave after the move. What happens to every system that calls into the estate. The order the upgrades run in, and the way back from each step. We run that work under an ISO 27001:2022 certified information-security management system, alongside ISO 9001:2015. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The plan we hand you is sized to what the estate actually needs.
A great deal of enterprise Java runs businesses quietly and correctly. We decide what to rewrite by whether each module can still be changed safely. We upgrade the rest in place, one step at a time, with a working deployment after each.
Oleksandr TrofimovChief Technology Officer, unicrew03Delivery
Finding the behaviour that lives outside the source code
The sequence matters more here than on almost any other kind of Java work, because an application server supplies behaviour that appears nowhere in your repository.
- Write down what the server providesConnection pools, queue destinations, security settings, transaction configuration, how classes are loaded, and any file specific to that vendor. This is the part that does not travel with the repository, and it is the part that breaks migrations at the least convenient moment.
- Get the behaviour under test from the outsideTests driven through the deployed interfaces, because code managed by the server resists being tested in isolation by design. On estates with thin coverage this is the single largest piece of work, and skipping it is why these projects have the reputation they have.
- Raise the floor in strict orderJava version, then the server, then the package rename, one step at a time with a working deployment after each. Doing them together removes your ability to say which change caused a regression, and on an estate this age there will be regressions.
- Cut seams, then decide about extractionBoundaries inside the estate first, extraction later and only where there is a business reason. Once the seams exist, moving a piece off the server becomes an incremental choice rather than a programme you have to fund up front.
04Stack
What an application server sits between
The decisions that usually arrive with an estate like this, each with its own page if that is the one you are actually taking.
05Questions
Asked when the support renewal lands
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on an estate like this it is often the only sensible shape, because the knowledge of why a setting says what it says lives with your people. Our engineers own the plan as well as the changes, because here the plan is what keeps an upgrade from becoming an outage. The upgrade order and the way back get reviewed by an architect outside the delivery team. Team extension is managed teams; an outcome is legacy modernization.
When your organisation already runs one of these estates and anything else would add a second way of doing everything. Otherwise we start new systems on Spring Boot. The Jakarta EE specification is alive and its runtimes are maintained, but the ecosystem, documentation, operational tooling and hiring pool are all deeper around Spring Boot.
Scope. This one is about estates where an application server is part of the architecture: server-managed transactions, vendor configuration files, the javax to jakarta rename. Our Java development page covers the language and platform, new builds on Spring Boot, and general structure. The test is simple: if removing the server would break your application in ways nobody can list, this page is yours.
The rename itself is largely mechanical and tooling handles most of it. The cost sits in three other places: the server upgrade you have to do at the same time, outside libraries that never published a renamed version and therefore need replacing, and proving that transaction, security and data handling behaviour is unchanged. We treat the library inventory as the first deliverable, because it decides whether this is contained.
Often, yes, and it is a real option rather than a polite one. If the estate is patched, the server is still receiving security updates, nobody is blocked from shipping, and the interfaces are documented, then the money is better spent where change is actually blocked. What makes it indefensible is an unsupported server, because at that point every unpatched flaw is permanent by definition.
A scoping call with an engineer. Before it we ask for read access to the repository plus the server configuration and deployment files, because on this kind of estate those carry information the code does not. What comes back is written: the order we would work in, what we would extract, what we would keep, and where the risk actually sits. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, and we only offer it after the first read, because a fixed number on a system nobody has opened is a guess. Team extension is billed monthly per engineer, and the rate depends on the seniority mix, so it is quoted rather than listed.
Running an application server estate nobody volunteers to change?
Tell us the server, the Java version, and what the estate talks to. You will get an engineer's read on the order of work and the risk, including which parts of the estate stay exactly as they are.