Migrating a Java EE platform without interrupting production

By Cédric Barme · Founder of NSY

The Java EE platforms of French financial institutions often carry fifteen years of history: frozen application servers, pinned dependencies, and a debt that makes every change more expensive than the last. NSY has been delivering these migrations since 2018 — no big bang, no service interruption, with the same person from scoping to production.

The real problem: self-sustaining debt

An ageing Java EE platform costs you in three ways. Security first: frozen versions (JDK 8, out-of-support application servers) accumulate unpatched CVEs — something ACPR audits and DORA requirements no longer tolerate. Hiring second: the older the stack, the harder it is to staff teams to maintain it. Velocity last: every business change demands increasingly painful technical contortions.

The "great rewrite" reflex — replacing everything — fails in most cases: the platform embeds years of undocumented business rules that a rewrite rediscovers the hard way. The path NSY practises is incremental.

The NSY approach, step by step

• Audit of the existing estate — mapping modules, dependencies (libraries, drivers, JMS brokers), inbound/outbound flows and friction points. Deliverable: a risk map and a costed trajectory.
• Incremental upgrades — JDK first (8 → 11 → 17/21), then the Jakarta namespace (javax → jakarta), then the application server (JBoss EAP, WildFly — see the WildFly / JBoss expertise). Every step yields a testable, reversible system.
• Progressive containerisation — where the context justifies it: moving to OpenShift or Kubernetes while preserving sessions, distributed transactions and messaging (OpenShift expertise).
• Industrialisation — CI/CD, automated non-regression testing, observability. This is what stops the debt from rebuilding.

How production stays untouched

The absolute rule: progressive cutovers, never a leap of faith. Parallel environments, flow replication (messaging, data), load tests representative of real traffic, and rollback plans that are tested — not merely written. In banking environments this discipline is not a luxury: it is the condition for getting risk teams to sign off.

Timelines and ballparks

An audit with proof of feasibility fits in a few weeks. Migrating a full application core takes months, in stages that each deliver value. NSY always starts with the short scoping phase: you leave with a realistic trajectory and ballpark before any long commitment. The FAQ covers the typical cases.

Why NSY

Cédric Barme has been a software engineer since 2012, with years in investment banking (real-time trading and risk platforms) before founding NSY in 2018. The Java EE migrations delivered since then have all run in regulated environments — ACPR, AMF, GDPR, DORA — where you do not "fix things as you go". No-pyramid model: the person who scopes the migration is the one who delivers it, with at most three clients in parallel.