Oracle Forms 12c applications are often business-critical systems with mature PL/SQL logic, reports, integrations and user workflows. Moving them to Oracle APEX should be treated as a modernization project rather than a screen-for-screen conversion.

This checklist helps teams prepare an Oracle Forms 12c to Oracle APEX migration by identifying the application assets, dependencies and decisions that matter before development begins.

1. Inventory Forms modules and active workflows

Start with the Forms modules users actually run. Record the number of FMB files, major business modules, user groups, menus, libraries and shared components. Identify which screens are heavily used and which are candidates for retirement.

2. Review triggers and program units

Document WHEN-VALIDATE-ITEM, WHEN-BUTTON-PRESSED, KEY-COMMIT and other triggers that contain business behavior. Review program units and determine which logic belongs in reusable Oracle Database packages and which behavior should be implemented as APEX validations, processes or dynamic actions.

3. Map Oracle Reports dependencies

List Reports called from Forms and classify them by purpose: interactive inquiry, dashboard, printable document, invoice, statement, regulatory output or data export. Each category may require a different APEX reporting approach.

4. Review PL/SQL and database objects

Identify packages, procedures, functions, views, sequences, jobs and database triggers used by the Forms application. Well-structured database logic can often remain valuable in the target APEX architecture.

5. Document integrations

Record interfaces to ERP systems, REST services, file transfers, email, printing, authentication providers and external databases. Integration dependencies should be designed early rather than discovered during user acceptance testing.

6. Redesign the user experience for the browser

A Forms canvas is not automatically the best APEX page. Consider master-detail pages, interactive grids, dashboards, cards, dialogs and focused workflows. Preserve the business outcome while improving navigation and usability.

7. Define authentication and authorization

Document current users, roles, responsibilities and security rules. Plan how authentication and authorization will work in APEX and how existing role logic will be mapped or simplified.

8. Select a representative pilot module

Choose a module that includes realistic complexity without being the highest-risk component. A pilot should validate the target architecture, PL/SQL strategy, reporting approach, security model and UX conventions.

9. Compare business outcomes, not only screens

Testing should verify calculations, validations, database updates, approvals, reports and integrations. A modernized APEX page can look different from Forms while still producing the same trusted business result.

10. Plan a phased rollout

Large Forms environments are often safer to modernize in phases. Define module boundaries, coexistence rules, data ownership, cutover steps and retirement criteria for legacy components.

Information to prepare before requesting an estimate

• Oracle Forms version and approximate number of FMB files
• Oracle Reports count and report types
• Oracle Database version
• Number of users and locations
• PL/SQL packages and major database dependencies
• External integrations
• Authentication method
• Target hosting environment
• Required migration timeline

For a complete service overview, visit our Oracle Forms to Oracle APEX Migration Services page. If you need APEX development after the assessment, see our Oracle APEX Development Services.