In Oracle Planning and Budgeting Cloud Service (PBCS) and Oracle Enterprise Planning and Budgeting Cloud Service (EPBCS), Classic and Next Generation (Next Gen) refer to the two application framework options available when a new Planning application is created. The framework determines the underlying architecture of the application, the interface model used for planning forms and dashboards, and the set of Oracle EPM features available to the application. The critical constraint: the framework is selected at application creation and cannot be changed without creating a new application and migrating the configuration. An application created as Classic cannot be converted to Next Gen in place — the decision is permanent at the time of application provisioning.
Architectural Differences
| Dimension | Classic Application | Next Gen Application |
|---|---|---|
| Interface framework | Classic Planning UI — grid-based forms | Next Gen simplified UI — flexible layouts, cards, infolets |
| Data entry model | Forms with defined row/column/page structure | Forms plus flexible dashboards with embedded entry |
| Predictive Planning | Not available | Available (ML-based forecast suggestions) |
| Infolets | Not available | Available — visual summary tiles for KPI display |
| Approval workflow | Planning Unit Hierarchy (full) | Planning Unit Hierarchy (streamlined) |
| EPM modules (EPBCS) | Available | Available — enhanced module integration |
| Migration from Hyperion Planning | Supported migration path | New build — migration not supported from Classic directly to Next Gen |
Feature Implications for EPM Architects
The most consequential feature difference between Classic and Next Gen in production EPM environments is the availability of Predictive Planning — Oracle’s machine learning capability that analyses historical actuals and suggests statistically derived forecast values for planning users. Predictive Planning is available only in Next Gen applications. For organisations implementing rolling forecasts where the planning team wants to leverage ML-assisted forecasting, the Next Gen framework is required. Classic applications cannot access this feature regardless of the Oracle EPM Cloud subscription level.
Infolets — the visual summary tiles that display KPIs and metric summaries on the EPM Cloud home page — are also Next Gen-only. Finance organisations that want their planning environment to provide an executive dashboard experience through the EPM Cloud home page, rather than requiring users to navigate to reports, need Next Gen. Classic applications display a standard home page without the infolet capability.
Migration Implications
The majority of Hyperion Planning to Oracle EPM Cloud migration paths land in Classic applications — because Oracle’s Migration Utility supports migration of Hyperion Planning artefacts (dimensions, forms, business rules, security) to Classic PBCS applications, and because Classic is the closer functional equivalent to Hyperion Planning’s interface model. Migrating from Classic PBCS to Next Gen requires a separate rebuild rather than a migration — which means that organisations that migrate from Hyperion Planning to Classic PBCS and then want Next Gen features must undertake a second migration project rather than a simple conversion.
What Goes Wrong in Practice
The most common Classic vs Next Gen decision failure is selecting Classic for a new application because the migration team is more familiar with Classic, without evaluating whether the organisation’s planning roadmap includes features available only in Next Gen. An application built in Classic that needs Predictive Planning two years later requires a full rebuild — at the cost of the configuration and user adoption investment that was made in the Classic application. The framework selection should be based on the three-year feature roadmap, not the implementation team’s current comfort level.
How Loop Wise Solutions Approaches This
We evaluate Classic vs Next Gen as a structured design decision — mapping the client’s current and planned feature requirements against the feature availability in each framework, and documenting the selection rationale as a formal architecture decision record. For new applications, Next Gen is our default recommendation unless a specific requirement (migration from Hyperion Planning, Classic-only feature dependency) makes Classic the appropriate choice.
Answers before you ask.
They are two application frameworks within PBCS and EPBCS that differ in interface model, planning form design capabilities, and available EPM features. Next Gen reflects the newer platform direction with its own feature set and design approach, while Classic follows the established model. The framework chosen shapes how the application looks, behaves, and what it can do.
Because it is made at application creation and is irreversible without rebuilding the application. The framework determines the available feature set for the application's whole operational life, so choosing wrongly means either living with the limitation or rebuilding later. This makes it a foundational design decision, not a setting that can be toggled afterwards.
By assessing which framework's features and design model fit the planning requirements and the platform's direction, and by confirming which capabilities each supports before committing. Because the decision is locked in at creation, it warrants careful evaluation up front rather than defaulting, with attention to how each framework aligns with long-term needs.
Not without rebuilding — the framework is set at creation and changing it means re-creating the application. This irreversibility is precisely why the choice matters so much. Teams should therefore treat it as a durable architectural commitment and validate the framework against requirements before the application is built.