Java 6, 7, and 8 applications stuck on end-of-life app servers. We handle framework and app-server migrations, Spring and Jakarta upgrades, and the untangling it takes to get an old monolith onto a supported, testable stack.
Software subcontractors · Java · Perl · Compliance
We carry old systems into the present.
Burning Sapp is a two-partner engineering shop for the migrations other teams turn down: end-of-life Java, CGI-era Perl, and systems that answer to auditors. We work carefully, to a schedule, and we put everything in writing.
- Java 6 · WebLogic 10- Perl 5.8 CGI, undocumented+ Java 25 LTS · containers + documented, test-wrapped, ported
Start with an assessment
We reply in writing.
01 · What we take on
The unglamorous work, done properly.
The CGI scripts and batch jobs that quietly run the business. We document them, wrap them in characterization tests, and port them to a modern stack. The ones that ought to stay put, we stabilize instead.
Migrations that have to survive an audit. Change control, traceability from requirement to commit, test-parity evidence, and documentation your auditors will actually read.
02 · How a controlled burn works
Five steps, and every one leaves a paper trail.
-
Read
We read the code before we quote. It's the only honest way to scope this kind of work.
Evidence: risk map · fixed-scope proposal
-
Wrap
Before anything moves, we write characterization tests that pin down how the system behaves today.
Evidence: test harness · baseline parity report
-
Port
Small, reversible changes instead of a big-bang rewrite. We move one piece at a time, in an order we set with you before we start.
Evidence: incremental releases · written status
-
Prove
The new system runs alongside the old until the numbers agree.
Evidence: parallel-run results · parity evidence
-
Retire
The old system is switched off on a date everyone agreed to, and nothing else notices.
Evidence: cutover record · documentation handover
03 · Why us
Why us
The risky part of a migration isn't the new code. It's everything nobody wrote down.
- Staffing
- Partners only. The people you talk to are the people in the code.
- Scope
- Fixed and written down. You get a priced statement of work, not open-ended hourly billing.
- Communication
- Status goes out in writing every week. Decisions get recorded.
- Evidence
- Test-parity reports and a traceable change history you can hand to an auditor.
- Surprises
- None, if we can help it.
04 · The partners
The partners
Torin Sapp
Partner · Engineering
Torin builds the test harnesses and tooling that keep a migration honest: characterization tests, parity checks, and the scripts that prove a cutover worked.
Jake Burns
Partner · Engineering
Jake leads assessments and cutover planning. He's the one reading ten years of somebody else's code before we touch a line of it.
Burns + Sapp. The name was sitting right there.
05 · Contact
Tell us about the system nobody wants to touch.
admin@burningsapp.comTell us what it runs on, how old it is, and when it needs to be done.