Modernize the System Your Business Still Runs On

Most companies do not need a rewrite. They need the system they already depend on to become understandable, testable and movable. NomadX is an AI-native software studio inside an AI agents consultancy in Dubai. Our senior engineers direct AI coding agents like Claude Code and Codex to map undocumented code, lock in its behavior with tests, and migrate it piece by piece. You get a 7-day first slice in production and steady weekly progress after that.

What is legacy application modernization?

Legacy application modernization means moving a working but aging system onto a stack your team can hire for, secure and deploy, without breaking what the business relies on. It can mean a framework upgrade, a language migration, a database move, splitting a monolith, or all four, done in stages rather than one risky cutover.

The legacy systems we see most often in the Gulf:

• .NET Framework 4.x apps with ASP.NET MVC, Web Forms, WCF and Windows services, often running on aging Windows servers.
• Classic ASP and VB6 applications that still handle core back-office work.
• Java EE and older Spring monoliths on WebLogic, WebSphere or JBoss.
• PHP 5 and 7 codebases, frequently custom frameworks with no tests.
• Oracle Forms front ends sitting on large Oracle databases full of PL/SQL business rules.

Not every one of these should become microservices on Kubernetes. Sometimes the right answer is a clean modular application on modern .NET with the database left where it is. We decide that on the evidence, in the first week.

How do AI agents help with undocumented legacy code?

The slowest part of any migration is understanding the old code. AI coding agents are very good at reading large codebases quickly, which makes AI-assisted code migration faster mainly because the discovery phase shrinks from months to days, not because the agents write magic code.

In practice, agents:

• Build a system map. Modules, entry points, database tables, stored procedures, scheduled jobs and external calls, turned into diagrams and a dependency graph.
• Write plain-language documentation for each module: what it does, which business rules it encodes, where the surprises are.
• Draft characterization tests from real inputs and outputs, so behavior is pinned before anyone touches it.
• Propose translated code for the target stack, which engineers review, restructure and own.

Engineers verify every claim the agents make against the running system. An agent that confidently misreads a 2009 stored procedure is exactly the risk we design around, which is why tests come first. The same spec-driven development discipline we use on new builds applies here: the spec is the system map plus the tests.

Why write characterization tests before any change?

Because the old system is the specification. Characterization tests capture what the code actually does today, including rounding quirks, date handling and edge cases nobody wrote down, so you can prove the new version behaves the same. They run in CI against both old and new code on every commit.

We record real requests and responses, batch job inputs and outputs, and report results, scrub sensitive data, and turn them into automated tests. Where the old behavior is a bug, we flag it and you decide whether the new system fixes it or keeps it for now. That decision is written down, not discovered in production.

How does the strangler-fig pattern avoid a big-bang rewrite?

The strangler-fig pattern puts a routing layer in front of the legacy system and moves functionality behind it one slice at a time. Users keep using one application while, route by route, the new code takes over. When nothing is left on the old side, you switch it off.

• Day 1-3: system map, docs and characterization tests.
• Day 4-7: one well-bounded module migrated, deployed behind the router and live. This is the 7-day first slice.
• Weeks 2-N: another module, endpoint group or batch job each week, every release reversible by flipping a route back.

For ASP.NET, Microsoft’s own incremental migration guidance uses a YARP proxy for exactly this. For Java and PHP we typically use NGINX or an API gateway. Our write-up on shipping in 7 days with AI coding agents explains the same weekly cadence on new products.

The honest part: a large migration is not a 7-day project. A mid-sized line-of-business app usually takes several weeks of increments; a core banking or ERP-scale system takes months. The difference from a classic rewrite is that you see production value in week one and every week after, instead of waiting a year for one cutover.

.NET Framework to .NET, Java EE to Spring Boot, and other common paths

A .NET Framework to .NET migration is the most common request we get in the UAE. Libraries and Web API projects often port with modest changes; Web Forms, WCF server and heavy System.Web usage need redesign, usually to ASP.NET Core with Razor Pages, Blazor or a separate frontend. Microsoft now steers upgrades through GitHub Copilot app modernization, which replaced the deprecated .NET Upgrade Assistant, and we use it alongside our own agents. See our .NET stack page for the target architecture.

• Java EE or old Spring to Spring Boot. OpenRewrite recipes handle the mechanical javax-to-jakarta and framework upgrades; agents and engineers handle the business logic. Details on our Java and Kotlin page.
• PHP 5/7 to a modern stack. Either modern PHP or a move to TypeScript, Python or Go, depending on your team. Our Go vs Rust vs Node.js comparison helps with the target choice.
• VB6 and classic ASP. These rarely port line by line. We extract the business rules into tests and rebuild them as a web app with an API behind it.
• Oracle Forms. We keep the database first, expose its logic through a new backend API, and replace the forms screen by screen.

Monolith to microservices: when it is worth it

Splitting a monolith to microservices makes sense when parts of the system need to scale, deploy or fail independently, or when separate teams own them. It does not make sense just because the monolith is old. Many legacy apps end up as a modular monolith on a modern stack, with one or two services carved out for the hot paths.

How do you migrate the data?

Data migration moves with each slice. We map the old schema, write transformation and reconciliation scripts, and verify row counts and checksums on every run. When old and new systems must share data during the transition, we use change data capture with Debezium and Kafka, or controlled dual writes, so neither side drifts. Every step has a tested rollback.

Legacy application modernization in Dubai: government and banking context

Legacy application modernization in Dubai often happens inside banks, insurers and government entities with strict change control. We plan for that: data stays in-country on Azure UAE North, AWS me-central-1 or on-premise, PDPL and sector rules shape where test data can live, and release windows follow your change advisory board. Weekly increments fit these processes better than a single high-stakes cutover, because each change is small enough to review properly.

Once services are modernized, they usually need a new home; our sister practice handles Kubernetes migration. To see how this fits with the rest of what we build, including the agentic SDLC we run on every project, visit the software development hub.