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.
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:
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.
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 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.
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 |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.