What did the two-week experiment demonstrate?

Vaadin consultant Jean-Christophe Gueriaud used Claude Code to migrate Oracle's Summit demo toward Vaadin and Spring Boot. The ORDERS form contained 183 elements and 45 pieces of PL/SQL logic.

The author openly describes the boundaries: simple PL/SQL, no stateful packages or dynamic SQL, and a stronger verification process that remained unfinished when the two weeks ended. He also reports initial omissions and deliberate changes to validation and locking behavior. Read the Vaadin experiment

This is a useful exploration of AI-assisted development. The problem arises when its headline becomes a planning assumption for a different application, scope, and acceptance standard.

"Two weeks" needs a defined finish line. Does it mean a generated screen, a working demonstration, a validated business workflow, or a production release? Those milestones represent different amounts of completed work.

What determines an enterprise Oracle Forms migration timeline?

Form count is a starting point. The assessment must also establish how those forms interact and which behaviors the business requires.

A relatively small application can be difficult to modernize if its workflows depend heavily on shared state, libraries, database packages, external integrations, and specialized user interactions.

AreaWhat the migration must establish

Area	What the migration must establish
Validation and navigation	Required rules execute at the appropriate point, including when users move between fields and records.
Transactions and concurrency	Save, rollback, and conflicting updates preserve the required business outcome.
Cross-form workflows	Parameters, shared state, and library calls behave correctly across complete workflows.
Queries and master-detail relationships	Record retrieval, filtering, and related-record operations remain consistent.
Integrations	Reports, files, external services, and authentication work in the target environment.
Power-user productivity	Required shortcuts, query operations, and repetitive tasks remain efficient.
Production acceptance	Performance, security, deployment, recovery, and business testing meet agreed criteria.

 

 

These are assessment categories, not claims that every application requires the same implementation.

The timeline depends on the behaviors present, the conversion approach's coverage, the exceptions requiring engineering, and the organization's ability to validate the result.

When simplification creates work elsewhere

Changing application behavior can be a sound design decision. But it must be priced and approved as part of the project.

Consider a workflow where users currently receive validation feedback before leaving a field. Moving that feedback to save time may require changes to error handling, dependent calculations, user instructions, and acceptance tests.

Likewise, changing transaction or session handling requires reviewing the workflows that relied on the original behavior.

The initial implementation may become simpler while the overall project gains additional work.

For power users, even a technically correct redesign can affect throughput. A replacement screen should be assessed against the tasks users perform repeatedly throughout the day.

Functionality removed from conversion scope does not automatically disappear from the business requirement. It may return as remediation, redesign, integration work, or training. A credible estimate makes that work visible before the project begins.

Why an established migration engine changes the timeline

Preserving required Forms behavior does not mean every customer must fund the development of a new compatibility framework.

An established conversion engine can encode supported behavior in reusable transformation rules. Engineering effort invested in understanding and implementing a pattern can then benefit subsequent migrations.

RENAPS describes this approach in its earlier article on Oracle Forms migration with AI versus deterministic conversion: ORMIT™-OpenJava applies predefined transformations to supported constructs, with application testing remaining necessary.

The distinction is practical. Buyers should ask which behaviors the platform already handles, how that coverage is demonstrated, and what happens when the source contains an unsupported pattern.

Determinism alone does not prove correctness. Its value comes from consistent application of validated rules, explicit exception handling, and evidence that the resulting workflows meet requirements.

AI can still contribute to implementation, documentation, test development, and subsequent improvements. Its usefulness should be evaluated against the total effort needed to deliver an accepted application.

How to establish a credible timeline for your application

Before accepting a migration estimate, request five concrete deliverables:

1. An application inventory: active forms, menus, libraries, reports, database dependencies, and integrations.
2. A coverage assessment: what converts automatically, what requires adaptation, and what needs further investigation.
3. A representative proof of concept: a meaningful business workflow with challenging dependencies.
4. Explicit acceptance criteria: the required behavior, permitted changes, and evidence needed for sign-off.
5. A delivery estimate through production: conversion, remediation, integration, testing, user acceptance, and deployment.

This gives the project a measurable baseline and makes vendor proposals easier to compare.

The lesson from a two-week experiment is that AI-assisted development deserves serious evaluation. Enterprise planning requires extending that evaluation through the full scope of delivery.

The meaningful measure of migration speed is time to an accepted production application.

For organizations evaluating Oracle Forms modernization, a RENAPS ORMIT™-Analyzer assessment can provide the starting point for discussing application scope, conversion coverage, and the work needed to establish a realistic migration plan.