A European insurer asked us to estimate two paths for migrating 480 Oracle Forms screens. A hand-rewrite quoted at 38 months and 14 developers. An automated code translator quoted at 9 months but produced TypeScript that mirrored the original WHEN-VALIDATE-ITEM triggers line for line. Neither was acceptable.
This is the false choice every CIO modernizing Forms inherits. Slow and safe, or fast and architecturally identical to the system you’re trying to escape.
The false choice
Manual rewrites burn budget and leave the business running on the legacy system for years. Our migration data shows the average enterprise Forms application carries between 200 and 600 screens, 1,500 to 4,000 PL/SQL triggers, and a decade of undocumented business rules. Rewriting that by hand is a multi-year archaeology project.
Automated translators flip the trade-off. They’re fast, but they treat the .fmb file as the source of truth and emit modern syntax that preserves every legacy assumption. The result compiles. It also carries forward the same coupling, the same procedural patterns, and the same maintenance debt.
There’s a third way.
What structured migration actually does
Instead of translating code line by line, we work at a higher level of abstraction. The DEX Elements pipeline runs in three stages.
- Analyze every block, trigger, LOV, canvas, and PL/SQL procedure in the source application.
- Extract the business logic into a normalized intermediate representation we call a JSON descriptor.
- Generate a modern TypeScript application from those descriptors using a governed component framework.
The intermediate representation is not code. It’s a structured description of what the application does. That distinction is the entire point. Output is deterministic and auditable. Business logic survives without inheriting the legacy architecture. The same descriptors can target any framework we support. And when a descriptor changes, the running application updates.
Why this matters to enterprises
For the CTO, the output is standard TypeScript the company owns outright. No vendor runtime, no Oracle licensing on the new stack.
For the development team, the generated project is a normal npm workspace. Familiar tooling, familiar deployment, no specialized migration knowledge required to maintain it after we leave.
For the business, migration ships in months instead of years. The legacy system runs in parallel, and cutover happens screen by screen rather than as a single weekend of risk.
For compliance, every screen carries a structured descriptor that doubles as living documentation. SOX audit trails, role-based access, and security review live at the framework level rather than in individual developer decisions.
The AI layer this unlocks
Once an application exists as JSON descriptors, an AI assistant can operate on it safely. The model isn’t generating free-form code. It’s editing a constrained schema the framework already knows how to render. Output is predictable, reviewable, and reversible.
That enables work that would be reckless on raw code. Non-technical analysts modify screens by describing changes in natural language. The system answers questions about its own behavior. New modules get drafted from a paragraph of intent rather than a Jira epic.
Structured migration isn’t just faster than a rewrite or cleaner than a translator. It converts a one-time project into a permanent capability.