Oracle Forms modernization
Migrate off Oracle without the two-year rewrite first.
An Oracle Forms application is twenty years of business rules in
.fmb files and PL/SQL packages. A full rewrite means
freezing feature work for 18 to 24 months and hoping the vendor finishes
before your Oracle renewal lapses. There is another way to run this.
The problem every Forms migration hits first
-
The design is the code
Business rules live inside
WHEN-VALIDATE-ITEM, package bodies and record-group queries. There is no spec — the.fmbis the design — and the people who could tell you what it does are retiring. -
Scope hides until build begins
A rewrite that quotes against a form inventory discovers the actual complexity three months in. By then the budget is spent, the timeline is public, and the project owns the slip, not the vendor.
-
Oracle renewal is the clock
You cannot stay on Forms Services. You cannot ship a replacement in the renewal window. Something has to run the forms while the replacement is built.
How we work
-
Inventory the estate
Browser-based tools read every
.fmb,.mmband.pllyou have — no Forms Builder, no upload. We produce an accurate module list, PL/SQL footprint and table dependency graph before anyone commits to a plan. -
Run the forms against Postgres
Our sqling Runner reads
.fmbfiles directly and executes their triggers against Postgres — no Forms Services, no WebLogic, no Java. The application your users know keeps working while the migration proceeds. -
Replace by surface area
A new UI goes in a module at a time, cutting over the forms behind it. Users see the change on the schedule you choose; the back office keeps running on day two of the project as well as day two hundred.
-
Decommission on your timetable
When the replacement covers everything, the runner retires with it. No orphaned systems, no "temporary" Forms Services kept alive for the last few modules nobody got to.
What makes this different
Most Forms migrations are architected as rip-and-replace because the alternative — running Forms somewhere other than Forms Services — did not exist as an off-the-shelf answer. We built that alternative. The Forms runner and the PL/SQL engine underneath it are our products, not a stack we assembled from other people's. When something your Forms do runs into something the runner doesn't do, the fix lands in the runner the next day, not on a vendor's roadmap.
Who this is for
-
Shops with 20 to 500 Forms modules
Big enough that a rewrite is a multi-year commitment, small enough that an incremental cut-over is tractable.
-
Oracle Forms 6i through 12c
The runner reads the
.fmbbinary directly. Version is rarely the blocker. -
Target database: Postgres
We target Postgres as the Oracle replacement. SQLite and DuckDB are supported for dev / CI; Postgres is the one we migrate to.
Have a Forms estate you need to move?
Send us an inventory count and a sample .fmb or two and
we will tell you what a pilot would look like.
Contact Data Design Group.