TRIRIGA is a serious bit of software. It runs the estates of global banks, government departments, and FTSE 100 companies for a reason. The data model is rich, the workflow engine is proper, and the platform has decades of refinement behind it. That is also the problem. Most UK estates teams are paying for capability designed for portfolios an order of magnitude bigger than theirs, and the gap between what they use and what they license has only widened since the IBM Maximo Application Suite (MAS) repackaging.
Why UK teams are looking
Three things tend to put TRIRIGA on the list. The first is the renewal letter. Authorised user licences sit in the £15,000-per-seat range, before any of the costs that make a deployment actually work: integration, infrastructure, support, and the IBM Business Partner who keeps the lights on. A 30-developer team is north of £450,000 a year in licences alone, and that is a polite ballpark.
The second is modernisation pressure. Estates leaders are being asked for tenant self-service, mobile-first engineer apps, AI-assisted classification, and dashboards that do not require a two-week ticket to change. TRIRIGA can do most of these things, eventually, but the engineering effort is not trivial and the output looks dated next to anything built in the last five years.
The third is the IBM portfolio shuffle. MAS is the future of Maximo. TRIRIGA's positioning has shifted. Roadmaps are opaquer than they used to be. Senior estates leaders are noticing that they cannot reliably tell their CFO where the product will be in five years, and that is a problem in procurement.
What you would actually lose
It is worth being honest about this. TRIRIGA's strengths are real. The lease accounting capability is genuinely sophisticated; if your portfolio is heavy on commercial leases and you need IFRS 16 audit trails, that is not a feature most CAFM challengers can match out of the box. The capital projects module is mature. So is the strategic facility planning workspace. If you use those modules properly, replacing them is a project, not an afternoon.
Most estates teams do not use those modules properly. They bought TRIRIGA because they had to manage a few thousand assets, a service desk, and a PPM schedule, and ended up with a Rolls Royce that mostly does the school run. If that sounds familiar, the strengths above are not yours to lose.
The categories of alternative
There are four practical buckets to evaluate, and the right one depends almost entirely on what you actually use TRIRIGA for.
The first is established mid-market CAFM. Planon, FSI Concept Evolution, MRI Evolution, Service Works QFM. These are mature, feature-complete, well documented, and priced below TRIRIGA but not by a category-defining margin. The migration path is familiar to anyone in FM. The risk is that you swap one ageing interface for another and end up making the same call again in six years.
The second is generalist platforms with FM extensions, most obviously ServiceNow. The pitch is appealing if you already have ServiceNow elsewhere in the organisation, but the FM module is a thin layer on top of ITSM, not a CAFM. Asset hierarchies, PPM scheduling, and permit-to-work are bolt-ons or custom builds. By the time you have configured ServiceNow into a competent CAFM you have spent more than you would on a specialist, and the per-seat licensing reasserts itself the moment your staff count grows.
The third is configurable challenger platforms, which is where Jarsis Platform sits. The trade is that you give up some of the shrink-wrapped depth of a Planon for a platform that is genuinely configurable by your own team, with AI classification and GOV.UK alignment built in rather than bolted on. The pricing wedge is meaningful: a complete deployment at a fraction of the equivalent TRIRIGA stack, with unlimited self-service users so you are not taxed on every tenant or citizen who raises a request.
The fourth is staying on TRIRIGA but ripping the value out of what you already pay for. This is a serious option for some organisations. If your problem is that the platform is fine and the developer experience is the bottleneck, a tools layer over the existing TRIRIGA can give you a modern API, AI-assisted debugging, and a metadata graph the platform never shipped with. That is what we built Jarsis Developer Tools for IBM TRIRIGA to do, and it is a different conversation to a full replacement.
What to evaluate
Most TRIRIGA replacement RFPs are written by someone who has only ever seen TRIRIGA. The result is a feature checklist that rewards platforms with the same shape, which means you end up back where you started.
Better to score against the operational outcomes you actually care about. How long does it take a competent admin to add a new asset class without a vendor SOW? How does the platform handle a permit-to-work that needs three concurrent isolations and a separation of duties? What does the audit trail look like when a regulator asks who approved a fire-door inspection three years ago? Can a tenant raise a repair on their phone without an account, and does the engineer get the location, photos, and priority before they leave the depot?
Score each candidate honestly. The top of the market is a surprisingly close-run thing once you stop scoring features and start scoring outcomes.
A migration that does not blow up
The instinct is a big-bang cutover. The reality is a read-only mirror, then a phased move by domain. Stand the new platform up alongside TRIRIGA. Replicate the asset register first, read-only, so the new platform has the data but is not yet making operational decisions. Move the service desk next: tenants raise tickets in the new platform, and a small bridge pushes any TRIRIGA-only updates back. Then PPM, then permits, then compliance. The TRIRIGA instance shrinks until it is doing only the modules you genuinely cannot migrate, and a final cutover decommissions it.
Most teams take six to nine months for the active part of this. The sticking points are predictable: dirty asset data that has accumulated for a decade, integrations to building management systems that nobody has touched in years, and the inevitable workflow that one person knows how to fix and that person left in 2019. None of these are unique to a TRIRIGA migration. All of them benefit from being addressed in daylight rather than during a cutover weekend.
Where Jarsis fits
Jarsis Platform is built for the team that picked TRIRIGA because nothing else looked serious enough at the time and now regrets the price. The platform handles configurable workflows, an asset register that scales, AI classification with full transparency records, GOV.UK One Login and Notify, and multi-tenant operation for FM providers running multiple contracts. It is the modern UK CAFM we wished existed when we were on the other side of the table.
For the scenario where TRIRIGA stays but the developer experience needs dragging into 2026, Jarsis Developer Tools for IBM TRIRIGA gives your team a REST API, an MCP metadata graph, live diagnostics, and AI-assisted investigation, all running inside your existing TRIRIGA instance. No middleware, no database modifications.
Either way, the conversation we usually have is shorter than people expect. We will not pretend to replace the lease accounting depth if that is what you actually use. We will tell you honestly whether a platform swap or a developer tooling layer fits your situation better.
Talk to someone who has done this before
Book a 30-minute conversation. We will look at what you use TRIRIGA for, what your renewal looks like, and whether replacement, augmentation, or staying put is the right call. No slides.