Java

For a system that still clears its workload, incremental modernisation is usually the lower-risk path, and it can pause at any point without leaving the estate half-migrated. A rewrite is worth its risk in three cases: the domain model itself is wrong, platform licence costs dominate the economics, or nobody remains who can read the code.

The two are not mutually exclusive across an estate. Some applications modernise in place, some are rewritten small, and some retire; we form that map by reading the estate before recommending anything.

The runtime is stable and vendors still support it. The urgency comes from the ecosystem: the current generations of the major frameworks require newer runtimes, so staying on 8 progressively freezes your dependency tree.

The move from 8 to a current LTS is mostly mechanical for application code, with the module system and removed internal APIs causing the friction. We usually fold it into planned work on each service rather than running it as a standalone programme.

Yes, and many enterprises with a history of acquisition do. Both run on mature managed runtimes with strong HTTP, messaging and observability ecosystems, so services interoperate over ordinary APIs and queues without either side noticing the other's language.

The cost is duplicated tooling, duplicated pipelines and two hiring pools. Where an estate has drifted into both by accident, consolidating new work on one platform usually pays; where the split follows a real boundary, such as a .NET division alongside a Java core, it is worth keeping.

Yes, unusually so. The compiler rejects a large class of wrong code before anything runs, decades of public Java give models deep corpus coverage, and the JUnit culture means most estates already hold test suites an agent can run after each change.

The qualifier is the corpus's age: it is thick with J2EE-era idiom, and an unguided agent will reproduce XML-heavy configuration and patterns the platform retired years ago. Repository conventions and current-idiom reference code keep generated Java modern; the correctness signal does the rest.

The mechanical part, yes. Namespace moves such as javax to jakarta, dependency upgrades and repetitive API substitutions are high-volume, pattern-shaped work that agents and recipe tools such as OpenRewrite complete quickly, and a compiling, tested result is straightforward to verify.

The judgements that decide whether a migration succeeds, where the service boundaries fall, what should be retired instead of ported, which framework the target services use, are not in any corpus. We apply the tooling to the volume and keep those decisions with engineers who have read the estate.

Either as a fixed cost for an initial outcome, such as a first release or a defined migration, or as a monthly rate for the team once later phases are under way. We do not publish a figure for a build, because the scale is set by the number of features, platforms, user groups and users, and projects have run from four weeks to several months. The How We Charge page sets out both models, milestone billing and the notice period.

Typically one full-time engineer on the build, with two part-time roles alongside: one running the project and one working with you on priorities and technical decisions. Teams are shaped around the system rather than around one technology, so Java work draws in the neighbouring stack when it needs to. Delivery starts under Australian leadership, with the engineering in our Manila delivery centre.

Discovery establishes the scope, systems involved and delivery requirements. We agree the implementation plan and timing after that work, before implementation begins.