Migrating Operational Risk to a New Platform Without Migrating the Mess

At some point every operational-risk team outgrows its platform. The legacy GRC tool that was state-of-the-art a decade ago is now slow, rigid, expensive to license, and impossible to get a clean report out of. So the decision gets made: we’re moving to something modern — ServiceNow IRM, or another current platform. The RFP goes out, a vendor is chosen, an implementation partner is hired, and everyone braces for a technology project.

And that’s the first mistake. Because the technology is almost never what sinks these migrations.

In the platform migrations we’ve run — including moving a full operational-risk program off BWise and onto ServiceNow IRM — the hard part was never the software. Modern platforms are capable and the implementation partners know how to configure them. What goes wrong is everything around the tool: the risk taxonomy you’re carrying over, the state of the data underneath it, and whether anyone actually uses the new system once it’s live. Get those wrong and you’ve spent a year and a large budget to rebuild your old problems in a nicer interface.

The trap: lift-and-shift the mess

Here’s how it usually goes. The migration timeline is tight, the partner is billing by the phase, and the path of least resistance is to map the old system’s structure straight onto the new one. Same risk taxonomy. Same control library. Same RCSA templates. Same everything — just moved.

The problem is that the old structure is almost always part of why you were unhappy with the old platform. Ten years of a live GRC system produces sediment: a risk taxonomy that grew by accretion until it has four categories that mean the same thing, a control library with hundreds of near-duplicates because every business line wrote its own version of the same control, RCSA templates so long that assessors click through them without reading, and KRIs nobody has looked at since the person who defined them left.

Lift-and-shift takes all of that sediment and pours it into the new tool. Six months after go-live, the risk team is exactly as frustrated as before — except now they’ve also lost the muscle memory of the old system and the goodwill they spent getting people to adopt the new one. The migration was the one moment you had permission and budget to fix the underlying structure, and it got spent on a copy-paste.

The real work is upstream of the tool

The migrations that come out clean treat the platform swap as the forcing function for a redesign, not the redesign itself. The work that actually determines whether you’re happy in two years happens before a single record moves:

• Agree the target risk taxonomy. Decide what your risk categories, business hierarchy, and control framework should be — not what they happen to be in the old system. This is the foundation everything else hangs off, and it’s far cheaper to fix on a whiteboard than in a configured platform.
• Cleanse and de-duplicate the control library. Collapse the near-duplicates, retire the dead controls, and standardize how a control is written so the library is usable. A migration is the only time you’ll get sign-off to do this at scale.
• Redesign RCSA and KRI structures for how you actually run the program. Not the template you inherited — the one that fits the way your first and second lines actually work today. (If your assessment process itself is manual and painful, that’s worth fixing in the same motion — see automating your RCSA campaigns.)
• Decide what history to bring, and clean what you bring. You rarely need every loss event and closed issue from the last decade migrated live. Decide what carries over, archive the rest, and cleanse what moves — because dirty data in a new platform is still dirty data. None of this is a software task. It’s operational-risk judgment — knowing what a taxonomy should look like, which controls actually matter, how to define residual risk so it means something. It’s also the part implementation partners are worst at, because they’re configuration specialists, not risk practitioners. This is the gap that sinks projects, and it’s the gap worth staffing deliberately.

The five failure modes we see

Across migrations, the same handful of things go wrong. Watch for them:

1. Over-customization. The new platform does something a sensible, standard way, and someone insists on bending it to match exactly how the old tool worked. Every customization is a cost you pay again at every upgrade. Adopt the platform’s model unless you have a real reason not to.
2. Lost history and broken traceability. Loss events that no longer tie back to the control and risk they touched, issues detached from their source assessment. Once the linkages break in migration, they’re painful to rebuild — map them deliberately, don’t let the ETL flatten them.
3. No parallel run. Cutting over cold and hoping is how you discover, in production, that a KRI calculates differently in the new tool. Run both systems side by side for at least one reporting cycle and reconcile the numbers before you trust the new one.
4. The adoption gap. The platform goes live and the first and second lines quietly keep working in their old spreadsheets because nobody trained them or gave them a reason to switch. A technically perfect migration nobody uses is a failed migration.
5. No single owner. When the partner rolls off, the project has to become someone’s program. If no one internal owns the platform, the configuration, and the adoption after go-live, it drifts back into the same state you were trying to escape.

A phased approach that de-risks it

The shape that works: assess the current state honestly (what’s in the taxonomy, how dirty is the data, what’s actually used) → design the target model before touching the tool → cleanse the data and control library against that model → configure the new platform to the agreed design, resisting customization → migrate in waves rather than one big-bang cutover → parallel run and reconcile for a full reporting cycle → hand off to an owner with the training and documentation to keep it healthy.

Phasing it this way means the expensive, irreversible decisions (taxonomy, data model) get made early and cheaply, and the risky moment (cutover) gets de-risked by the parallel run. It’s slower on paper than lift-and-shift. It’s dramatically faster than doing lift-and-shift and then spending the next two years fixing what you carried over.

What good looks like

A migration done this way doesn’t just change your platform — it leaves you with a cleaner taxonomy, a control library you trust, assessments people actually complete, and data clean enough that the reporting layer on top of it means something. That last part is the payoff: once the foundation is right, your risk data can finally tell you where the trouble is instead of just accumulating.

The new platform is the easy part. The value is in refusing to migrate the mess.

---

Fiorverso helps banks and insurers move operational risk onto modern platforms — including ServiceNow IRM — without carrying a decade of taxonomy sprawl and dirty data along with them. If you’re planning a migration, or living with the aftermath of one that lifted-and-shifted, an Operational Risk Automation Audit is a fast way to see what a clean foundation would change.