Service 01
Java Modernization
Applications written for Java 6, 7, or 8 that still run the business and can no longer be patched, staffed, or defended in a security review. We move them onto a supported runtime without changing what they do.
- Java 6 · WebLogic 10 · Ant- Spring 3, no test suite+ Java 25 LTS · Tomcat or containers + Spring Boot 3, characterization tests
01 · Where we come in
You probably recognize at least one of these.
- An application on Java 6, 7, or 8 that security keeps flagging, and nobody wants to be the person who touches it first.
- A WebLogic or WebSphere licence that costs more every year than the application it hosts earns.
- A Spring 3 or 4 codebase where upgrading one dependency breaks three things somewhere else.
- Struts, EJB2, or a framework somebody wrote in house, documented by a developer who left in 2014.
- A javax to jakarta namespace migration that somebody started and then quietly stopped.
- An Ant build that only compiles on one machine, and that machine is under somebody's desk.
- A vendor quote for a full rewrite that costs more than the department's annual budget.
02 · The work
What we actually do.
Most engagements touch several of these at once, because they are tangled together. We sequence them so the application is deployable at the end of every step, not just at the end of the project.
Java version upgrades
Java 6, 7, and 8 to a current LTS. Removed APIs, reflection changes, and the module system dealt with properly rather than suppressed with flags.
App server migration
WebLogic, WebSphere, and older JBoss onto Tomcat, an embedded server, or containers. Vendor-specific descriptors and JNDI lookups translated, not left behind.
Spring and Jakarta
Spring and Spring Boot upgrades, the javax to jakarta namespace move, and replacing Struts or EJB2 where doing so costs less than keeping them.
Builds and dependencies
Ant to Maven or Gradle, builds that run the same on any machine, a dependency tree you can audit, and a CVE list that gets shorter instead of longer.
Characterization tests
Tests written against the current behavior before we change it, including the behavior that is technically a bug but that something downstream depends on.
Monolith detangling
Separating the pieces that genuinely need to move on their own schedule. This is not a microservices project unless you ask for one and can staff it.
03 · Engagement
How a Java engagement runs.
It follows the same five steps as everything else we do, described on the home page. Here is what each one means for a Java codebase.
-
Read
Two to four weeks inside the repository and the running system, on a weekly written cadence. We map dependencies, find the parts with no test coverage, and identify what will actually break on a newer runtime.
You get: risk map · upgrade path · fixed-price proposal
-
Wrap
We build a test harness around current behavior. On most legacy Java work this is the longest step, and skipping it is why most of these projects fail.
You get: test suite · baseline behavior report
-
Port
Runtime, then build, then frameworks, then the application code, in whatever order the risk map says is safest. Each stage ends with something you could deploy.
You get: incremental releases · weekly written status
-
Prove
Old and new run side by side against the same inputs until the outputs match. Where they differ, we explain why before anyone signs anything.
You get: parallel-run results · parity report
-
Retire
Cutover on an agreed date, scheduled for when the system can actually afford to be down — a night, a weekend, or a holiday window. We plan for those hours rather than treating them as an exception. A rollback stays available for an agreed window afterward, and then the old servers get switched off and the licence stops renewing.
You get: cutover record · runbook · handover docs
04 · Terms
What each side brings.
- We bring
- Two senior engineers, the test harness, the migration work, and every document listed above.
- You bring
- Source access, a running environment we can copy, and someone who knows what the application is supposed to do.
- Timeline
- Assessments run two to four weeks. Migrations usually run three to nine months depending on size and how much test coverage exists at the start. Every engagement reports in writing once a week, on the same day, for the life of the work.
- Pricing
- The assessment is priced on its own. The migration is quoted as fixed scope once we have read the code, so the number is based on what is there rather than what we hope is there.
- Subcontract
- We work happily under a prime contractor or agency, under your name, on your paper.
05 · Questions
What people ask before hiring us.
Do we have to move to the cloud?
No. Our job is getting you onto something supported. If that is the same datacenter running a current LTS on Tomcat, that is a fine outcome and a cheaper one. We will tell you if we think the cloud saves you money, and we will tell you when it does not.
The people who wrote it are gone. Is that a problem?
That is the normal case, and it is most of why you would hire us. The code is the specification. Reading it and writing down what it does is the first half of the work.
Will you rewrite it?
Almost never. A rewrite throws away every undocumented business rule the original absorbed over fifteen years, and those rules are the valuable part. We migrate. If a component genuinely needs replacing we will make that case separately, with a cost attached.
Can this happen without a code freeze?
Usually yes. We work on branches that track your ongoing development and rebase as you go. It costs some extra effort, and we would rather spend it than ask your product roadmap to stop for a quarter.
What if the assessment says the project is a bad idea?
Then the assessment says that, and you have spent a small amount of money to avoid spending a large amount. We have no interest in selling you a migration that should not happen.
Contact
Tell us what it runs on.
admin@burningsapp.comJava version, app server, framework, and your deadline is enough to start.