drm-drg-conversion-featured

 

Oracle Data Relationship Management has been the backbone of financial hierarchy management for close to two decades, and Data Relationship Governance gave it a workflow layer that many finance teams still run their change process on today. Both still work. Neither is where Oracle is going. This guide covers what converting off DRM and DRG actually involves, functionally and technically, based on what we see in real conversions.

First, an honest picture of where DRM stands in 2026, because the common claims on both sides are wrong. DRM is not about to be switched off: Oracle keeps Hyperion EPM 11.2, DRM included, on Premier Support on a rolling basis, currently through at least 2034 and reviewed annually. But supported is not the same as invested. Recent DRM quarterly updates have shipped a handful of defect fixes or none at all, the product remains Windows and IIS only with no cloud version, and Oracle's development energy has moved to Enterprise Data Management (EDM) in EPM Cloud. Add DRM's historical per-record licensing and a shrinking pool of administrators who know it deeply, and conversion becomes a question of when and to what, not if.

Oracle currently commits Premier Support for Hyperion 11.2 — the Continuous Innovation release that includes Data Relationship Management (DRM) 11.2 — through at least 2037, a date Oracle reviews annually and extends at its discretion (Oracle Hyperion Support). There is no fixed DRM end-of-support date. Last verified: September 2026

One more wrinkle worth naming: the restricted "DRM for Hyperion EPM" license that Oracle bundled with 11.2 to replace EPMA excludes DRG, DRM Analytics, and reads or feeds to anything outside on-premises Hyperion. If you are on that license, your governance workflow and non-Hyperion integrations were never covered in the first place.

 

Start with a complete inventory of what you own

A DRM and DRG conversion goes wrong most often because something was not on the list. Fifteen years of configuration accumulates. Before any design work, inventory all of it:

  • Versions and hierarchies: production versions, what-if and archive versions, every hierarchy, node counts, shared nodes, and orphans.
  • Properties: core properties in use, every custom property, local versus global scope, and which are defined, inherited, derived, or lookup.
  • Derived property logic: every formula and script, what it calculates, and what still depends on it.
  • Validations: real-time and batch, what each enforces, and where each is assigned.
  • Exports and books: hierarchy, generation, version, and compare exports, their targets (files, database tables, interface tables), and the books that batch them.
  • Automation: batch client jobs, action scripts, blenders, and any external schedulers that call them.
  • DRG configuration: workflow models, tasks, stages (submit, enrich, approve, commit), conditional routing, separation of duties, and notification rules.
  • Security: users, node access groups, property categories, and roles.
  • Consumers: every application and process that receives DRM output. This list is always longer than anyone remembers. Check the batch client logs.

The inventory is also your reconciliation baseline. Node counts, property values, and export outputs from this snapshot are what you will compare the new platform against.

 

Choose the destination before you design the conversion

There are two realistic destinations. Oracle EDM is the first-party path, and for an Oracle-only landscape on EPM Enterprise Cloud with modest record volumes it is a reasonable one. Its known friction point for DRM customers is logic: EDM's validations and derivations are built with a formula builder rather than a free-form engine, and complex DRM scripts often cannot be translated into it, which is exactly where mature DRM configurations carry their value. EDM's record caps in the Enterprise bundle also deserve a close read if your node counts are large.

EPMware is the finance-focused path, built by people who spent years implementing DRM. Logic converts to PL/SQL scripts rather than a constrained builder, integrations to EPM, ERP, and data warehouse targets are prebuilt adapters rather than rebuilt exports, and licensing is enterprise-wide with unlimited nodes rather than per record. The rest of this guide describes conversion to EPMware, but the functional inventory and design questions apply to any destination.

 

The functional conversion

 

Rationalize before you migrate

The single biggest mistake in DRM conversions is lift and shift. A large share of DRM custom properties exist for one reason: to route metadata to the right export, or to feed logic that DRM did not provide natively. EPMware handles both differently. Dimension mappings replicate a single change across every mapped hierarchy and application, which eliminates the routing properties outright, and a library of out-of-the-box derivations and validations replaces much of the homegrown logic. In practice, most conversions retire well over half of the DRM property inventory. Treat every property as guilty until proven necessary: keep it only if a target application or a business decision still consumes it.

Map the concepts

DRM and EPMware describe similar ideas with different machinery. The mapping that guides the design:

DRM and DRG concept EPMware equivalent What changes
Version Environment snapshots and versioning Point-in-time copies without version sprawl
Hierarchy and nodes Dimension hierarchies in the master repository Unlimited nodes, no record-based licensing
Custom property Property, after rationalization Most routing and plumbing properties retire
Derived property formula or script Business rule or logic script in PL/SQL Free-form logic, maintainable with light programming skills
Real-time and batch validation Real-time validation at the point of entry Errors blocked before the workflow, not after
Export, book, interface table Prebuilt adapter, interface table, file, or REST API deployment Deployment replaces export maintenance
Import profile Application registration and metadata import Target properties come from the target application
Action script and batch client job Governed requests, mass updates, and the scheduler Bulk change moves inside governance
DRG workflow model, tasks, stages Configurable workflow with review, enrich, and approve stages Business users own the process
Node access groups and property categories Role-based security by application, dimension, and property Separation of duties enforced by the platform

 

Redesign the governance model, do not transcribe it

DRG models encode how your organization worked when they were built. Conversion is the moment to redesign rather than transcribe. Keep the separation of duties, the enrichment responsibilities, and the approval authorities. Drop the workarounds: stages that exist because DRG could not validate in real time, single-admin commit steps that exist because integration was manual, and email-and-spreadsheet side channels that grew up around the tool. In the target, a change should enter through a request, be validated as it is typed, route to the right reviewers based on what it touches, and deploy automatically on final approval. If a DRG stage does not map to a real decision, it should not survive the conversion.

 

The technical conversion

 

1. Extract from DRM

Extraction is the easy part, and it should happen on day one. EPMware provides a conversion utility that pulls all hierarchies and properties from DRM and prepares them for staging, typically in a few hours. Independently, capture the configuration as documentation: DRM's Migration Utility exports the application template (property definitions, validations, exports, and books) as XML, and hierarchy and property exports per version give you the reconciliation baseline. Archive all of it before anything changes.

2. Register targets and import their models

In DRM, target-specific properties were hand-built and maintained against each subscribing application. EPMware inverts this: you register the target applications (Oracle EPM Cloud or on-premises, Hyperion HFM, Planning and Essbase, OneStream, EBS, Fusion, SAP, the data warehouse) and import each application's own metadata model through its adapter. Target properties come from the target, not from a reconstruction of DRM. This step is why a large share of the DRM property inventory never needs to move.

3. Convert the logic

Triage every derived property and validation from the inventory into three buckets: retire (nothing consumes it anymore), replace (an out-of-the-box EPMware derivation or validation covers it), and rewrite (genuine business logic). The rewrites become PL/SQL logic scripts attached to configuration events, which is deliberately close to how DRM administrators already think. This is also the step where the EDM comparison matters most: logic that will not fit a formula builder converts cleanly to a script. Budget the conversion effort by script count and complexity, not by node count. Nodes move in hours. Logic is where the real work lives.

4. Rebuild integration as deployment

Every DRM export, book, and interface table feed gets replaced, not recreated. Map each consumer from the inventory to a deployment method: prebuilt adapter for the EPM and ERP applications, interface tables or formatted files for the warehouse and anything file-based, REST API for on-demand consumers. Repoint the downstream jobs that used to pick up DRM output, and move the scheduling into the platform. Expect the export inventory to shrink the way the property inventory did, because one governed deployment replaces the several exports that used to serve one application.

5. Build workflows and security

Recreate the redesigned governance model in the workflow builder: request types, enrichment and approval stages, conditional routing by dimension or application, and notifications. Map DRM users and node access groups into role-based security, wire up SSO, and enforce separation of duties in the platform rather than in procedure documents.

6. Reconcile, parallel run, cut over

Testing a metadata platform is reconciliation, not clicking around. Compare node counts and full property values against the day-one baseline, and compare adapter deployment output against the old export output for every consumer. Then run in parallel through at least one real close cycle in UAT: changes flow through both platforms, outputs are diffed, and the business users who will own the workflow are the ones driving it. Cutover itself is short: freeze DRM changes, sync the final delta, deploy from the new platform, and hold DRM read-only for a defined period before decommissioning the Windows and IIS footprint.

 

How long this takes

Extraction is a day-one activity measured in hours. End-to-end conversions typically run in weeks, not quarters, and the spread is driven by three things: how many derived properties and validations are genuine logic rather than plumbing, how many downstream consumers must be repointed, and how complex the DRG models are. A single-application DRM with a simple workflow converts fast. A fifteen-year, multi-target DRM with conditional DRG routing is still very achievable, but the logic triage deserves respect.

 

The pitfalls that cause real pain

  • Lift and shift. Recreating every DRM property in the new platform imports fifteen years of debt and doubles the work. Rationalize first.
  • Logic discovered late. A derived property nobody documented turns out to feed the ERP. The inventory and the Migration Utility XML exist to prevent this.
  • Forgotten consumers. A monthly batch job on a server nobody owns has been picking up a DRM export for years. Read the batch client logs.
  • Transcribed workflows. Rebuilding a DRG model stage for stage preserves the workarounds along with the controls.
  • Skipping the parallel close. The first real close on a new platform should not also be the first test of it.
  • Assuming EDM script parity. If your DRM value is in custom scripts, verify they fit EDM's formula builder before committing to that path.

 

Common questions about DRM and DRG conversion

Is Oracle DRM end of life?

No, and precision matters here. Hyperion EPM 11.2, DRM included, carries rolling Premier Support currently through at least 2034. But DRM is in maintenance: recent updates ship few or no fixes, there is no cloud version, and Oracle's investment is in EDM. It is a supported product without a future, which is why most customers convert on their own timeline rather than Oracle's.

Do DRM derived properties and validations carry over?

Not automatically, and they should not. Triage them: most routing and plumbing properties retire, a large share of the rest is covered by out-of-the-box derivations and validations, and genuine business logic is rewritten as PL/SQL logic scripts, which translate naturally from DRM's scripting patterns.

What replaces DRG workflows?

A configurable workflow engine with request, enrich, approve, and deploy stages, conditional routing, notifications, and separation of duties, owned by business users rather than administrators. The conversion is a redesign of the governance model, not a transcription of the DRG stages.

How long does a DRM to EPMware conversion take?

Hierarchy and property extraction takes hours. Full conversions typically run in weeks, with logic conversion, consumer repointing, and workflow redesign as the effort drivers, and a parallel close cycle as the quality gate.

What happens to DRM per-record licensing?

It goes away. EPMware licensing is enterprise-wide with unlimited nodes, which removes the practice of pruning hierarchies or splitting masters to stay inside record counts.

 

Convert with people who have done it

EPMware was built by consultants who implemented DRM for years, the conversion tooling reflects it, and finance teams from Hyperion shops to OneStream migrations have made this exact move. If you are planning a DRM and DRG conversion, schedule a demo and bring your property list and your gnarliest derived property. Those are the two things worth pressure-testing before you commit to any destination.