Oracle Forms is one of the oldest (if not the oldest) toolsets for client/server application development (AD) on the market. It's inaccurate to consider Oracle Forms as strictly legacy technology; however, like many of its early competitors, Oracle Forms is a venerable technology — that is, it's still widely deployed and commands respect — but Gartner believes it's ill-positioned for most next-generation AD challenges. Here, we address best practices for managing Oracle Forms applications and migration strategies for future investments.

• Oracle Forms remains a viable and valuable technology asset to mainstream IT strategies, but has limited scope in next-generation AD efforts.

AD organizations should:

• Approach Oracle Forms within a "containment" strategy.
• Modernize to gain advantages in centralized management and deployment.
• Integrate with service-oriented architecture (SOA) best practices (specifically Oracle's middleware and Java development tools).
• Migrate to industry-dominant technologies (for example, Java, Microsoft .NET and open-source software) to align with industry best practices in the future.

Because of its tenure in the market, there are thousands of Oracle Forms applications in production today. Compounding this issue, significant percentages of these deployments are built on older, outdated and unsupported versions of the toolset. As an even-greater challenge, many older deployments are accompanied by wholly insufficient documentation — and to keep them running day-to-day, developers try not to disturb these systems lest they collapse under their own weight.

Moreover, the combination of Oracle Designer and Oracle Forms created a powerful platform for model-driven AD when the term "enterprise client/server" remained an oxymoron (for many years, client/server applications didn't scale well beyond workgroup-size deployments). Consequently, many Oracle Forms applications are larger and more complex than typical client/server solutions, for example, deployed on products such as PowerBuilder or Visual Basic, that were deployed during the same time period.

The combination of older code, lack of documentation, and application size and complexity all contribute to very high barriers to migration for many Oracle Forms deployments. For these reasons and others, many Oracle Forms developers have avoided upgrading to newer versions of the toolset, never mind the larger challenge of migrating from Oracle Forms altogether.

Today, most AD organizations that encounter Oracle Forms are established customers. Few (if any) AD organizations are considering Oracle Forms for new investments, but there are exceptions, such as the acquisition of third-party applications that are built on Oracle Forms technology (Oracle's business applications are an example).

The challenges of moving beyond Oracle Forms investments can only be delayed, not avoided entirely. Although Oracle Forms remains a solid fourth-generation language (4GL) development toolset for two-tier client/server-architected solutions, the industry's state of the art has long since moved forward to embrace Web-centric application designs and SOAs. To be accurate, Oracle Forms can play a role in these efforts, but it's outclassed by more-modern next-generation toolsets (for example, Java and Microsoft .NET). At best, Oracle Forms should be considered for a supporting role in next-generation SOA efforts, not as the focal point of the application design.

It's also clear that Oracle's long-term AD strategy is squarely based on the Java platform. Nevertheless, Oracle has not announced an end-of-life plan for Oracle Forms; rather, we believe the company will continue to support and even minimally enhance Oracle Forms for the foreseeable planning horizon (see Figure 1). However, we don't believe that Oracle's investments will be sufficient enough to match essential features (such as Web interfaces) that can be found in other available, best-of-breed development environments. We also note that Oracle is moving its own business applications away from Oracle Forms. This effort began as Oracle built its E-Business Suite on Java, and will conclude with the eventual delivery of Fusion Applications.

Oracle will continue to support and minimally invest in Oracle Forms through 2015 (0.8 probability).

For reasons stated above, we believe that even with continued support from Oracle, the Oracle Forms market share will continue to decline in the coming years. In turn, this will yield increasingly declining support among third-party vendors, training and consulting services.

We suggest that future Oracle Forms investments be driven by one basic assumption: All AD organizations should plan to migrate away from Oracle Forms applications during the next 10 years. Moreover, all but the most-conservative AD organizations should plan to migrate during the next five years. In this effort, you should also demand a clearly articulated migration strategy from any application vendor that leverages Oracle Forms for its own solutions.

We recommend the following three tactics to maximize the time frame in which to gain the optimal investment in Oracle Forms.

In general, Oracle Forms deployments should be modernized (that is, upgraded) to the current versions whenever practical. This provides several advantages, the most important of which is establishing the foundation to leverage the integration features of current and future toolset versions with Oracle middleware and Java tools (see Section 5.0). Second, Oracle Forms can provide a compelling, centralized deployment, monitoring and management hub for Oracle-Forms-based solutions. This centralized control will offset the costs of upgrading efforts in many return on investment scenarios.

Of course, modernization can also come at considerable expense, especially for older solutions. However, we should stress that movement from an older code base isn't an issue of "if," but rather "when."

• As a prerequisite, whenever possible, AD organizations should clearly document older systems before any future development efforts. Even if they intend to migrate away from Oracle technology altogether, solid system and business process documentation are critical elements for success.
• Modernize if their intention is to extend the life cycle of an Oracle Forms application for as long as it's practical.
• Modernize if their intention is to integrate Oracle Forms functionality with Oracle's Java AD technology (see Section 5.0).
• Modernize to gain centralized deployment, management and monitoring of Oracle Forms applications. This can extend the life of these applications and also optimize the total cost of ownership.
• Modernize to bring Oracle Forms applications up-to-date with service and support. Gartner doesn't generally recommend that IT organizations leverage unsupported technologies. Exceptions are cases in which the strategy may be to aggressively migrate Oracle Forms applications to another platform (for example, Microsoft .NET) or another vendor's Java technology (for example, IBM WebSphere). In scenarios where complete migration is scheduled within 24 months, it may be sufficient to document the code base and contain an established deployment as-is.

We must stress, however, that unforeseen issues can arise at anytime and may affect the stability of older, unsupported Oracle Forms deployments (for example, OS patch and so on).

Bottom Line: IT organizations assume considerable risk with unsupported deployments of Oracle Forms solutions, and this risk grows as the technology ages.

The current version of Oracle Forms (10gR2) provides several integration points that may provide considerable value for established Oracle Forms code. Oracle Forms and Java applications are now deployed to a single unified application server (Oracle Containers for Java EE — OC4J), which provides common administration features and security contexts; moreover, it's now more practical to share common business and user interface logic between Oracle Forms and Java.

These integration strategies can significantly extend the role of Oracle Forms within SOA efforts. We expect that virtually all new features in future Oracle Forms versions will focus on integration with Oracle's Java and SOA (for example, Portal) infrastructures.

Select a migration target platform carefully: We believe the least-risky (that is, least-costly) migration path forward from Oracle Forms is Oracle's JDeveloper integrated development environment (IDE) and Application Development Framework (ADF). Although the transition from Oracle Forms to Java will be challenging for most Oracle Forms programmers, JDeveloper represents the lowest barrier to entry, insofar as Oracle's middleware and tools can be most-directly integrated with established Oracle Forms code.

It's also possible to migrate from Oracle Forms to non-Oracle Java technologies (for example, IBM, BEA Systems, open source and so on); however, we believe that, for most Oracle Forms developers, this will represent a significant learning curve that's beyond an acceptable level of risk and cost. However, developers should at least consider this strategy when outsourcing their migration efforts (see Section 4.2).

When Oracle's middleware and Java technology aren't selected, we recommend that IT organizations consider migrating to the Microsoft .NET platform instead. This will provide a lighter learning curve for programmers as well as a toolset that's more akin to the 4GL features of Oracle Forms. There are many circumstances in which developers may be compelled to select Java over .NET (for example, OS compatibility). Alternatively, open-source dynamic languages, such as PHP: Hypertext Preprocessor (PHP), are emerging as viable options, too.

Regardless of the migration target platform, IT organizations can choose from several strategies:

Developers should not expect Oracle to provide automated tools to directly migrate Oracle Forms code to Java or .NET. Instead, Oracle will focus its investments on integration and unified management.

Gartner is aware of several third-party companies that provide automated migration tools (for example, CipherSoft and NeoSoft) from Oracle Forms to Java. Among Gartner client feedback, the resulting code is, in many cases, "good enough," but generally less than optimal compared with manual re-coding efforts. However, "good enough" may be sufficient for many needs.

• Least intrusive to established code base.
• Fast automated results.

• Can be difficult to maintain the generated code after the migration process.
• Results are often "good enough," but not optimal. Moreover, results tend to vary significantly from one application to another. Some migrate easily, while others don't.
• Difficult to incorporate new design elements in the migration effort; instead, most projects focus on as-is migrations.

In many cases, outsourcing a project is a suitable alternative to automated code migration. The principle difference is that the addition of human touchpoints provides more flexibility over the final product. This process takes longer, but the final result can be more polished and fit to specific design goals — particularly when the effort incorporates new application features and design elements.

• No internal skills needed for initial migration effort.
• Ability to incorporate more-aggressive design changes above and beyond mechanical translations.
• Ability to bring resources with experience in both platforms, thereby meeting an aggressive delivery time frame and quality expectations.

• Can be difficult to maintain the code after the migration process is completed and the project is turned over.
• System must be extremely well-documented.
• Some new application scope can be introduced, but limited "hands on" owner involvement limits many aspects.

Instead of outsourcing a migration effort, many IT organizations choose to leverage internal resources for the effort.

• Developers have much more intimate knowledge of the business processes and technical nuances of the older system.
• Developers are completely familiar with the final product, thus minimizing any maintenance risks going forward.

• Splitting developers between maintaining an old system and new development efforts can stretch resources thinly.
• A lack of technical expertise with new technologies can create severe risks related to the time frame for delivery and quality of the new system.

As mentioned above, when Oracle's middleware and toolsets are selected as the target platform, migration efforts can much more aggressively take advantage of integration points between Oracle Forms and Java code. Specifically, business and user interface logic can be composited into a unified experience. Oracle Forms technology can be integrated into Portal and composite SOA efforts.

A staged (that is, phased) migration effort enables Oracle Forms applications to be migrated over time. This lengthens the period of time during which Oracle Forms remains an architectural element, but reduces the overall migration risk during that time period. It's an excellent strategy when the goal is to maximize current Oracle Forms code investments over a period of years. However, it isn't appropriate when there are more-urgent requirements to quickly and entirely de-invest in Oracle Forms technology.