Modernize business-critical systems. Verify the changes that matter.

Many Java applications need technical renewal while operations and feature delivery continue. Major version upgrades, outdated components, and limited test coverage increase the risk of unintended changes.

I modernize these systems incrementally, from technical assessment through implementation. Relevant workflows and results are captured before changes begin and checked after each migration step. This helps identify regressions early and narrow down their causes.

Typical modernization situations

• Java version upgrades and Java EE to Jakarta EE migrations.
• Framework and application-server upgrades.
• Unsupported platforms and libraries, and security or compliance requirements.
• Replacing CMP/EJB 2 persistence with JPA, and Hibernate/JPA upgrades.
• Modernizing established Java web applications, including JSF applications.
• Maintaining compatibility of existing REST interfaces.
• Limited test coverage and uncertain regression risk.
• Targeted architectural changes, replacement of individual components, or extraction of a service.

Depending on the objective, modernization can evolve the existing system or introduce broader architectural changes, including service extraction or cloud migration. The technical approach depends on business requirements, operational constraints, and the intended target architecture.

Approach and results

1. Understand the system and its risks. Code, dependencies, critical workflows, and technical constraints are examined. The scope and sequence of migration steps are derived from this.
2. Capture reference behavior. Existing tests are used and strengthened at critical points. Relevant results and measurements provide a comparison baseline for the migration.
3. Migrate in manageable steps. Small, reviewable changes simplify investigation and coordination. Repeatable source-code changes are automated where useful; AI supports analysis, testing, and implementation.
4. Compare results and stabilize. Relevant scenarios are run again. Unexpected differences are investigated, while intentional changes are documented.

Depending on the engagement, deliverables can include a technical assessment and staged plan, baseline tests and verification criteria, the migration changes, documented comparison results, and recommendations for further work.

What can be compared?

• Persistence: business results, transaction and loading behavior, database changes, SQL, execution plans, query counts, and execution times.
• REST interfaces: status codes, payloads, relevant headers, and side effects.
• Web interfaces: rendered HTML, visual presentation, and important interactions.

Comparison criteria are defined before the migration and aligned with the application’s critical workflows. For persistence changes, the generated SQL is also examined for correct filters and joins, unexpected N+1 queries, query counts, and suspicious execution plans. Performance and database comparisons use repeatable data and a suitable test environment.

Engineering, automation, and AI

More than 20 years of experience with Java systems, databases, interfaces, and production-critical applications provide the technical foundation.

I use AI regularly in day-to-day engineering—to explore existing codebases, prepare test scenarios and scaffolding, support implementation and refactoring, and assist with documentation and reviews. In client projects, it is used exclusively within approved tools and policies.

I use OpenRewrite for repeatable, rules-based source-code changes. The resulting changes remain reviewable and are assessed using the same engineering standards as manually written code.

Modernization also includes replacing unmaintained libraries, addressing known vulnerabilities through suitable upgrades, and continuously checking code quality with static analysis.

Structured approach

System assessment, risk analysis, test baselines, migration, and comparison of results follow a repeatable structure adapted to the technology, codebase, and project scope. It draws on my experience with Java systems, persistence migrations, and evolving existing applications.

This approach is gradually being extended with reusable checklists, automation, prompts, and small utilities.

Ways of working together

Defined modernization engagement: Depending on scope, I take responsibility for the complete modernization of an application or a clearly bounded part of it. This includes planning, technical implementation, coordination, and agreed handover.

Working within an existing team: Hands-on support for Java/Kotlin backend engineering and modernization, including long-term engagements within established delivery processes.

Assessment or independent verification: A technical assessment with risks and a staged plan can provide a starting point. A migration already in progress or completed can also be reviewed separately.

You work directly with me, in German or English. Remote-first across Germany and Europe with CET overlap; on-site kick-offs and workshops when useful.

Frequently asked questions

Can we work without external AI services?

Yes. Your approved tools and data-handling policies determine the setup. Options include internally hosted models, approved external services, or delivery without AI. Client code is not sent to external services without agreement.

What if there are hardly any tests?

The first step is to protect the most important workflows with a small number of trusted characterization and integration tests. AI can assist in identifying further scenarios and creating test scaffolding; the tests still need to be reviewed for functional validity.

Does the application need a rewrite?

No. Manageable changes within the existing system are usually the better approach. Larger restructuring or service extraction should solve a specific technical or business problem.

Your modernization project

Which application needs modernization, which upgrades are approaching, and which workflows must remain stable? A short description is enough to start the conversation.