A colleague in the GRC space forwarded me an internal communication from their ServiceNow account team that indicates ServiceNow will be officially sunsetting the legacy Risk Management plugin (often referred to as the "Classic" or "Legacy" Risk application, part of the Now Platform GRC suite) by the end of next year. This aligns with their broader push towards the Integrated Risk Management (IRM) application, which has been the strategic direction for several years.
The communication outlined a phased deprecation timeline, with key dates as follows:
* **End of New Sales (Q1):** The legacy plugin will no longer be available for new purchases.
* **End of Major Enhancements (Q2):** Only critical security patches will be applied.
* **End of Life / End of Support (Q4):** The plugin will be moved to a sustainment mode, with no further updates or standard support.
This move has significant implications for organizations still operating on the legacy framework. The data model and API endpoints differ substantially between the two applications. A migration will not be a simple upgrade but a project requiring careful data mapping, workflow reconfiguration, and user retraining.
From an analytics and user behavior perspective, the migration presents both a challenge and an opportunity. The IRM application offers more granular tracking objects and a different event log structure. To plan effectively, teams should immediately begin a comparative analysis of their current risk objects and workflows against the IRM data model. For example, the legacy `risk_risk` table and its related assessment tables do not have direct 1:1 equivalents in IRM.
A preliminary comparison of key analytical dimensions might look like this:
| **Analytical Aspect** | **Legacy Risk Plugin** | **Integrated Risk Management (IRM)** |
| :--- | :--- | :--- |
| **Primary Risk Table** | `risk_risk` | `sn_ir_risk` |
| **Assessment Workflow** | Tied to `risk_assessment` | Centered on `sn_ir_response` & `sn_ir_issue` |
| **Inherent/Residual Risk Fields** | Single record fields | Calculated via related `sn_ir_response` records |
| **Key Relationship** | `risk_risk` -> `task` (for assessments) | `sn_ir_risk` -> `sn_ir_response` -> `task` |
My primary concern is for historical reporting and cohort analysis. Risk lifecycle timelines, mitigation effectiveness rates, and control failure analyses built on the old data model will need to be rebuilt. I recommend initiating the following steps immediately:
1. **Inventory all custom reports, dashboards, and scheduled BI queries** that source from the legacy Risk tables.
2. **Document all custom fields, business rules, and UI policies** in the legacy plugin that define your current user behavior.
3. **Perform a gap analysis** between your documented state and the out-of-the-box IRM objects, focusing on fields used for filtering, grouping, and measuring in your analytics.
I am interested to hear from others who may have begun this migration. Specifically, what has been your experience with migrating historical risk data while preserving data integrity for longitudinal studies? Have you found the IRM application's analytics capabilities (like Performance Analytics) sufficient for recreating your key risk metrics, or have you had to extend the model significantly?
— Amanda
Data > opinions
You're absolutely right about the migration being a project, not an upgrade. The data model shift is the core challenge. In the legacy plugin, risks are often treated as standalone records with a more static assessment structure. IRM's model is inherently relational, tying risks directly to business processes, assets, and objectives. This forces a fundamental reconceptualization of how risk data is structured.
A secondary, often underestimated, implication is the reporting and integration impact. Any existing dashboards, custom reports, or API integrations built for the legacy plugin's table schema will break. Teams need to audit all downstream data consumers, which can extend far beyond the GRC team into audit, compliance, and executive reporting.
This timeline, while predictable, feels aggressive for complex deployments. I'd advise starting the data mapping exercise immediately, focusing first on identifying which legacy data points are truly archival versus which need active translation into the IRM relationships.
measure what matters
Absolutely. The point about downstream data consumers is crucial and often gets a backseat in initial planning. It's not just about dashboards breaking; it's about the logic within those integrations failing.
For example, we had a legacy risk score feeding into a marketing lead scoring model to flag high-risk industry prospects. That custom script pulled from a specific table column. The entire logic had to be rewritten because the "score" in IRM isn't a static field in the same way, it's often a calculated property based on those relationships you mentioned. The audit uncovered five such shadow integrations we didn't even know about.
I'd add that the data mapping exercise should include a parallel process to catalog every single outbound data flow, not just the reports you know about. Ask every team that might have built a connector, even if it was a one-off project years ago.
—Jen
Spot on about the downstream API and reporting impact. That's the silent killer in these migrations. We learned this the hard way moving from a custom CRM module - every webhook and third-party integration that assumed a specific JSON payload structure just stopped firing.
Your advice to start data mapping now is crucial, but I'd suggest starting that mapping *from the integrations inward*, not just from the legacy data outward. Catalog every API endpoint, scheduled job, or webhook listener that touches those risk tables first. You'll find the real scope of the "reconceptualization" you mentioned when you see how other teams are consuming the data.
The aggressive timeline almost forces an interim API layer strategy. We built a lightweight proxy that translated legacy-style GET requests to the new IRM relationships for a grace period, buying our downstream teams time to refactor. It added complexity, but prevented a total business process stoppage.
null
Thanks for posting the official timeline, that's super helpful to see it laid out. The "project, not an upgrade" point is the most critical takeaway here. I've seen teams get blindsided by thinking it's a platform patch when it's really a full data migration with integration fallout.
That phased approach, especially ending major enhancements in Q2, means any custom business rules or scripts you've added to the legacy plugin need to be ported over to IRM *way* before year end. You can't wait until support ends to start building those out in the new model.
The API difference is the biggest gotcha. It's not just new endpoints, it's a whole different philosophy. Your legacy REST calls that fetch a "risk" record are going to return a completely different JSON structure. Anyone with external integrations, even simple ones like a Power BI dashboard, needs to be on that from day one.
Integration Ian