SaaS Complexity in Enterprise IT: When Software Becomes the Problem

The promise was simplicity: move to the cloud, hand off the infrastructure, focus on the work that matters. A decade later, organisations are drowning — not in servers, but in platforms. Nowhere is this more visible than in ITSM, where the tools meant to manage IT complexity have become a source of it.

_{Argument one}

You don't own the logic. You rent it.

Every organisation has its own way of working. Its own escalation paths, its own approval chains, its own definition of what "done" means. When you build software — truly build it — those processes get encoded into the system. It becomes yours.

SaaS inverts this. The vendor owns the source code, the data model, and the fundamental logic of how the platform works. When your process doesn't match what the platform expects, you have three options: configure around it, accept the workaround, or change your process to align with the platform. Most organisations end up doing all three, in rotation, across years. This is one of the core drivers of SaaS complexity and vendor lock-in in SaaS platforms.

This dynamic starts earlier than most organisations realise — often at the point of subscription itself. The economics of SaaS subscription models create the conditions for lock-in before a single workflow is ever configured.

ITSM lens
This plays out most painfully in ITSM. Platforms like ServiceNow and BMC Helix are architected around ITIL best practices — a framework that is valuable in principle but rarely maps cleanly onto how any specific IT team actually operates. Your P2 incident criteria differ from the vendor's default. Your change approval board has exceptions that the workflow engine can't express. Your SLA definitions have edge cases that the platform ignores. So you approximate. You configure around the gaps. And with every six-month platform release, your approximations need to be re-approximated.

_{When a SaaS vendor releases a major update, your carefully configured ITSM workflows
don't automatically come with it. You're not upgrading software — you're re-negotiating
with a platform that has moved on without asking you.}

This isn't a bug in the product. It's the architecture. When you don't own the code, you can't own the logic. You are always a tenant, and tenants don't get to knock down walls.

_{Argument two}

You're paying for 100% of a product that solves 20% of your problem.

Enterprise SaaS platforms are built to win procurement battles, not to solve operational problems. The demo impresses the committee. The checklist beats the competitor. And so the vendor builds — relentlessly — adding modules, capabilities, and integrations, not because customers need them, but because enterprise deals require them to exist.

The consequence is software that is vast, complicated, and mostly unused. Large organisations actively use a small fraction of the features they licence. The rest sits in the product, visible in the UI, consuming cognitive space, generating permissions questions, and appearing in training materials that nobody reads. This is how SaaS feature bloat increases SaaS operational overhead in enterprise environments.

ITSM lens
In ITSM platforms, this problem is structural. A typical ServiceNow or Jira Service Management deployment ships with modules for IT Asset Management, HR Service Delivery, Customer Service, Facilities Management, Legal, and more — capabilities that IT teams never asked for and rarely use. The IT Director bought an incident management tool. They got an enterprise operating system; they now need a full-time admin team to manage. Meanwhile, the core use cases — incident resolution, change management, service requests — remain imperfect fits because the platform is too busy being everything to everyone to be excellent at anything for anyone.

_{Unused features aren't neutral. They add weight to every interface, create confusion in every
onboarding session, and multiply the surface area that administrators have to manage.
In ITSM, bloat directly degrades the agent and end-user experience —
the opposite of what the platform was purchased to achieve.}

_{Argument three}

When it breaks, the answer is always the same: buy a new one.

Here is where the SaaS model reveals its most cynical feature. After years of configuration debt, misaligned processes, workarounds built on workarounds, and a user base that has lost faith in the platform, organisations reach a breaking point. The system is unmanageable. Something must change.

The answer, almost without exception, is a new platform. A competitor with a better UI. A newer entrant with a fresher architecture. A vendor promising that this time, the implementation will be clean. This cycle is a textbook example of the SaaS replacement cycle driven by growing SaaS configuration debt.

ITSM lens
The ITSM market runs almost entirely on this cycle. Organisations migrate from Remedy to ServiceNow. From ServiceNow to Freshservice. From Freshservice to something newer — often because the licence fee has become indefensible, the admin overhead unbearable, or a new CIO has walked in with a different preference. Each migration is sold as a fresh start. Each one replicates the same fundamental problem in a new environment: the organisation still has the same IT processes, the same edge cases, and the same gap between how the software works and how the work actually works. The interface changes. The problem doesn't.

_{No one ever asks whether the problem is the platform — or whether the model of
managing IT operations through rigid, vendor-controlled platforms is the problem itself.}

This is the ITSM replacement cycle — and it is extremely profitable for vendors, implementation partners, and consultants. The organisation pays to migrate. Pays to train. Pays to rebuild every custom workflow from scratch. And in five years, the conversation starts again.

The honest reckoning. SaaS solved a real problem. Infrastructure management was expensive, slow, and often beyond the reach of mid-sized IT teams. Moving that burden to specialists made sense. But somewhere along the way, "software as a service" became "processes as a service" — and that is a trade organisations never consciously agreed to make.

In ITSM, the cost of this trade is paid every day: by service desk agents navigating interfaces built for the vendor's vision of IT, not theirs; by IT managers maintaining configuration debt they inherited and can't escape; by CIOs approving yet another migration that promises to solve what the last one didn't.

The next honest question isn't which ITSM platform to buy. It's whether the answer to rigid, bloated platforms is a leaner layer that sits on top of your existing data — one that gives you back control of the logic without forcing you to rip out what you already have.