On-Premise ITSM Software: Complete Guide 2026

On-premise ITSM software is an IT service management platform installed on servers your organization controls, either in your own data center or in a private cloud you administer. Tickets, asset records, attachments, logs and audit trails stay inside your network perimeter. You decide when to patch, who has database access, and whether anything leaves the building.

For most of the last decade the industry assumed this model was finished. Vendors retired their installable editions, moved everyone to per-agent subscriptions, and treated self-hosting as legacy. That assumption turned out to be wrong. Regulated industries, public sector bodies, defense suppliers and manufacturers with air-gapped OT networks never stopped needing it, and the arrival of AI features that send ticket content to third-party model providers has given a new group of IT teams a reason to look again.

This guide covers what actually remains on the market in 2026, what self-hosting costs when you count honestly, how to run a vendor evaluation that will not embarrass you in eighteen months, and what to do if you are still running something that stopped receiving security patches years ago.

‍

What counts as on-premise in 2026

The label has become slippery, so it is worth being precise before you shortlist anything. Four deployment models get called "on-premise" in sales conversations, and only two of them give you the control most buyers assume they are getting.

True on-premise. The full application, database and file storage run on hardware or virtual machines you own and administer. No component calls out to the vendor for the product to function. Licensing is usually annual or perpetual rather than per-agent-per-month.

Self-hosted in your own cloud tenancy. You deploy the vendor's container images or installer into your AWS, Azure, GCP or OVH account. You own the data and the encryption keys, the vendor has no standing access, but you are still subject to your cloud provider's jurisdiction. For most compliance frameworks this is acceptable. For genuine data sovereignty requirements, it may not be.

Private cloud or single-tenant hosting. The vendor runs a dedicated instance for you, sometimes in a region you pick. Your data is isolated from other customers, but the vendor still administers the system and has access. This is single tenancy, not on-premise, whatever the sales deck says.

Hybrid with a cloud dependency. An agent or collector runs on your network while the interface, database or AI processing runs in the vendor's cloud. Spiceworks worked this way before its desktop product was retired. If your reason for self-hosting is regulatory, this model usually fails the requirement, because the sensitive content still leaves your network.

Ask one question of every vendor during evaluation: if our internet connection is severed for two weeks, does the service desk keep working? The answer separates the first two categories from the last two.

Why organizations still choose self-hosted ITSM?

Regulatory and contractual obligations

NIS2 is the clearest driver in Europe. The directive's transposition deadline of 17 October 2024 passed with most member states running late, but by mid-2026 the large majority have national laws in force, and enforcement has moved from the European Commission to national regulators. First fines have been issued in several countries, and national CSIRTs have started systematic audits of essential entities. For an in-scope organization, the questions auditors ask about supply chain risk and incident logging are much easier to answer when the incident record itself sits on infrastructure you control.

DORA has a similar effect in financial services, where third-party ICT concentration risk is now an explicit board-level concern. Defense and aerospace suppliers face contractual clauses that prohibit storing project data outside specified jurisdictions or outside accredited facilities. Public sector procurement in several EU countries has started specifying on-premise or sovereign hosting as a hard requirement rather than a preference.

Data sovereignty beyond compliance

A growing number of buyers are not chasing a specific regulation. They have concluded that operational data about their infrastructure, including asset inventories, network topology, credentials referenced in ticket text and incident timelines, is sensitive enough that it should not sit in a vendor's multi-tenant database in another legal jurisdiction. A service desk is a detailed map of how an organization works and where it is weak. That reasoning has gained ground since the EU Data Act made cloud switching rights a live topic and prompted many IT teams to look properly at where their operational data actually lives.

Air-gapped and OT environments

Manufacturing plants, energy utilities, hospitals with medical device networks and military facilities operate segments with no internet route by design. Support requests from those segments have to be handled by something that runs inside them. There is no cloud workaround for a network that has no path out.

AI without third-party inference

This is the newest reason and the fastest growing. Cloud ITSM vendors have added summarization, reply drafting and ticket classification, and in most cases those features send ticket content to an external model provider. Security teams that have spent years restricting what employees may paste into public chatbots have noticed the inconsistency. Running inference locally, on hardware inside the perimeter, resolves it without giving up the productivity gain.

Predictable multi-year cost

Per-agent subscriptions look inexpensive during a pilot and stop looking that way at 60 or 200 agents, particularly once SLA management, asset management and SSO turn out to be tier upgrades. Annual on-premise licensing is easier to defend in a five-year budget, and it does not reprice every renewal cycle.

What happened to the on-premise market?

Understanding the current state of the market requires knowing why the options thinned out, because the gaps left behind are where most 2026 buyers now find themselves.

OTRS. For nearly two decades, ((OTRS)) Community Edition was the default free self-hosted service desk, especially in German-speaking Europe. OTRS AG withdrew from the open source project at the end of 2020, and Community Edition 6 stopped receiving security updates from 1 January 2021. The commercial OTRS product continues, sold as a subscription with quote-based pricing, but the free installable path ended. Two community forks took over the codebase, Znuny and OTOBO, and both are actively maintained. Anyone still running an unforked Community Edition install has been without security patches for more than five years.

Spiceworks. The free on-premise Help Desk that ran in thousands of small IT departments was deprecated at the end of 2021, with users moved to an ad-supported cloud product that cannot be self-hosted. The installer is no longer distributed, so a failed server means no reinstall.

Atlassian. Jira Service Desk Server reached end of support in February 2024. Data Center remains available for self-hosting, but at a licensing floor and operational complexity that pushed many mid-market teams to look elsewhere.

The SaaS-only majority. Freshservice, Zendesk and most of the ITSM tools that have grown fastest in the last decade have never offered a self-hosted edition and are unlikely to start. ServiceNow positions cloud as the default deployment for new customers.

The result is a market with a healthy open source segment, a small number of commercial vendors who kept an installable product, and a large abandoned middle: teams who need something supported, funded and self-hosted, without ServiceNow economics.

On-premise ITSM platforms available in 2026

The table below covers what a mid-market or public sector team is realistically likely to shortlist. Verify current licensing directly with each vendor before you build a business case, because terms in this segment change more often than the product pages suggest.

‍

A note on how to read this. Open source removes license cost, not total cost. The two expenses that dominate a five-year on-premise budget are usually internal administration time and the cost of customization that nobody supports afterwards. A GPL platform with no vendor behind it shifts both onto your team. That is the right trade for some organizations and a serious mistake for others, and the deciding factor is almost always whether you have a named person who will own the system for the next five years.

The real cost of self-hosting

Cloud vendors publish a per-agent price, which makes cloud look easy to budget and on-premise look opaque. Comparing them properly means putting both into the same five-year frame.

Here is an illustrative model for a 40 agent IT department. Treat the numbers as a structure to fill in with your own quotes, not as market rates.

Cloud, per agent per month. 40 agents at a mid-tier plan, plus the tier upgrade that SLA management and asset management usually require, plus SSO if it sits behind an enterprise plan. Multiply by 12, then by 5, then add an assumption for annual price increases at renewal. Add data export and integration work if you ever plan to leave.

On-premise, annual license. Vendor license for 40 agents. One-off implementation and configuration. A virtual machine or two, which in most organizations means marginal cost on existing capacity rather than new hardware. Backup and monitoring, usually absorbed by existing tooling. Roughly two to four hours of administration per month once the system is stable, plus upgrade windows two to four times a year. Optional GPU capacity if you want local AI inference.

The categories buyers most often forget:

• Migration effort in both directions. Getting data in is a project. Getting it out again later is a bigger one, and cloud vendors rarely make it pleasant.
• Tier creep. Features that look standard in a demo, particularly SLA, asset management, API access and identity provider integration, are frequently gated behind higher tiers. Price the tier you will actually need, not the one in the comparison table.
• Agent count drift. Per-agent pricing punishes growth and punishes seasonal support staffing. On-premise licensing usually does not.
• Internal ownership. Self-hosting without a named owner is how organizations end up running an unpatched service desk for five years. Budget the person, not just the license.

The honest summary: below roughly 15 agents, cloud is almost always cheaper and simpler, and you should choose it unless a regulation forces your hand. Between 15 and 50 agents the two models converge and the decision comes down to compliance and control. Above 50 agents, on-premise usually wins on five-year cost, provided you have the operational capacity to run it.

AI in a self-hosted service desk

If you want AI assistance without sending ticket content to a third party, there are three things to check and most vendor marketing will not volunteer them.

Where inference happens. Some vendors describe an AI feature as private because the data is encrypted in transit and not retained for training. That is not the same as local. Ask explicitly whether model inference runs on your hardware, and get it in writing.

Which model, and can you change it. A platform that ships a fixed model tied to one provider gives you no path if that provider's terms, jurisdiction or pricing change. Support for locally hosted open weight models is the more durable arrangement.

What the hardware requirement actually is. Useful ticket summarization and reply drafting can run on a single modern GPU for a mid-sized service desk. Vendors sometimes imply enterprise cluster requirements to steer you toward their cloud. Ask for concrete specifications at your ticket volume.

The features worth having are unglamorous and they compound: summarizing a long ticket thread before escalation so the next person does not read forty messages, drafting a first reply from knowledge base content, suggesting a category and priority at intake, and surfacing similar resolved tickets. None of that requires a frontier model. All of it saves measurable agent time.

One more consideration for EU organizations. The AI Act's obligations for high-risk systems phase in during 2026, and provisions on general purpose models are already in force. Most service desk AI will not be classified as high risk, but the documentation and transparency expectations are easier to satisfy when you can point to a model running on your own infrastructure with a known provenance. Mint Service Desk's AI module is built on that principle, with inference inside the customer's own environment.

Infrastructure and air-gapped deployments

Self-hosting a modern service desk is not the undertaking it was ten years ago. For a mid-sized deployment, expect something in this range and confirm against vendor documentation:

• One application server, containerized or on a VM, typically 4 to 8 vCPU and 8 to 16 GB RAM
• A separate database instance, sized mainly by attachment volume rather than ticket count
• Object or file storage for attachments, which is usually the fastest growing component
• A reverse proxy with TLS termination, plus your standard backup and monitoring agents
• Optional GPU capacity if you are running local inference

For air-gapped environments, the requirements that matter are different from the hardware list. You need an offline installation path that does not pull packages from the internet, license activation that works without calling home, an offline update mechanism such as signed bundles delivered by physical media, and documentation for applying those updates without vendor remote access. Ask about all four during evaluation. Plenty of products that install offline still expect to phone home for licensing, and you will discover that during deployment rather than during procurement.

Integration expectations for a self-hosted deployment in 2026: LDAP and Active Directory, SAML or OIDC for SSO, SMTP and IMAP for email, a REST API with real documentation, and connectors to whatever discovery tool you already run. Discovery integration is the one most often underestimated. A CMDB maintained by hand goes stale within months, which is why pulling live inventory from a tool like baramundi or Lansweeper matters more than the CMDB feature list itself.

Evaluation checklist

Questions worth asking every vendor on your shortlist, in writing:

Deployment and independence

• Does the product function fully with no outbound internet access?
• Is there an offline installation and update path?
• Does license activation require a call to your servers?
• Can we run it in an air-gapped segment, and do you have references who do?

Data and exit

• Where is data stored, and in what schema?
• Can we export everything, including attachments and audit history, in a documented format?
• Who at your company can access a customer instance, and under what process?

Licensing

• Is pricing per agent, per concurrent user, or per instance?
• Which features sit behind higher tiers? Specifically SLA, asset management, API, SSO, reporting.
• What has your renewal pricing done over the last three years?

Support and lifecycle

• What is the supported version window, and how long do we get security patches?
• What is the upgrade path between major versions, and does it require professional services?
• What happens to our on-premise license if you are acquired or discontinue the product?

That last question is not paranoid. Every abandoned product in the section above was once someone's safe choice.

Product fit

• Is asset management native or a separate module?
• Can non-IT departments run their own workflows without a separate license, which is what ESM actually means in practice?
• Does the customer portal support external customers, not only internal employees?
• Can we build the request forms and approval flows we need without custom development?

Migrating off an unsupported system

If you are running unsupported OTRS Community Edition, deprecated Spiceworks Desktop, or an abandoned internal ticketing tool, you have two decisions to make and they are separate. First, how urgently to move. Second, where to.

On urgency, be direct with your management about the security position. Software that has received no patches since 2021 is not stable, it is undisturbed. Every vulnerability found in that codebase since then is present in your install, and a service desk database is an unusually rich target, because it typically contains asset inventories, network detail and credentials pasted into ticket text by well-meaning users.

On destination, the choice between a fork and a replacement usually comes down to how much you have customized. Moving OTRS Community Edition to Znuny or OTOBO is close to an in-place upgrade and preserves your customizations, which makes it the pragmatic path if you have significant investment in the existing configuration and someone on staff who knows Perl. If your install is mostly stock, or your customizations exist because the product could not do something natively, a fork carries the original limitations forward and a replacement is worth evaluating.

A workable migration sequence:

1. Take a full backup and stand up a copy in an isolated environment. Do not experiment on production.
2. Inventory what you actually use. Most long-running installs have queues, forms and automations nobody has touched in years. Migrating dead configuration is wasted effort.
3. Decide your history policy. Full ticket history, a defined retention window, or a read-only archive of the old system alongside the new one. The third option is often cheapest and satisfies auditors.
4. Map the data. Users, queues, ticket states, custom fields, SLA definitions, attachments. State mapping is where migrations usually break, because legacy installs accumulate states with overlapping meanings.
5. Run both systems in parallel for two to four weeks, with new tickets in the new system and existing ones closed out in the old.
6. Retire the old system properly, including the database, backups and any exposed interface.

Budget four to twelve weeks depending on volume and customization. The technical export is rarely the hard part. Agreeing what the new process should look like is.

When you should choose cloud instead?

An honest guide has to include this section, and vendor guides usually do not.

Choose cloud if you have fewer than about 15 agents and no regulatory constraint. Choose cloud if you have nobody who will own patching and backups, because an unmaintained self-hosted system is worse than any SaaS product. Choose cloud service desk if you need to be live in days rather than weeks. Choose cloud if your organization is genuinely cloud-first and self-hosting would make your service desk the one exception your infrastructure team resents.

The best answer for a good number of organizations is a hybrid arrangement: on-premise for the environments and data classes that require it, cloud for everything else, ideally with one vendor and one interface so your agents are not switching between two systems. Mint Service Desk supports both models, and the pricing page shows how the feature sets compare across them.

FAQ

Is on-premise ITSM software still available in 2026?

Yes. The market is smaller than it was in 2015 but stable. Options include open source platforms such as Znuny, OTOBO, GLPI, iTop and Zammad, and commercial products with installable editions including ManageEngine ServiceDesk Plus, Ivanti Neurons ITSM, Jira Service Management Data Center and Mint Service Desk. Most large SaaS-native vendors, including Freshservice and Zendesk, do not offer self-hosting.

What is the difference between on-premise and self-hosted?

In everyday use they are treated as synonyms. Where a distinction is drawn, on-premise means the software runs on hardware in your own facility, while self-hosted also covers deploying it into cloud infrastructure that you administer. Both give you control of the data and the upgrade schedule, which is the property that matters for most compliance requirements.

Is on-premise ITSM cheaper than cloud?

It depends on scale and time horizon. Below roughly 15 agents, cloud is usually cheaper. Above roughly 50 agents, on-premise usually wins over five years, because per-agent subscriptions scale linearly while license and infrastructure costs do not. Between those figures the models are close and the decision is driven by compliance and control rather than price.

Can on-premise ITSM meet NIS2 requirements?

On-premise deployment does not make an organization compliant by itself, since NIS2 obligations cover governance, risk management, supply chain and incident reporting rather than hosting location. It does make several requirements easier to evidence, particularly incident logging, access control and reduced third-party ICT dependency. Most member states now have national law in force and enforcement sits with national authorities, so check the specific requirements in each country where you operate.

What replaced OTRS Community Edition?

Two community forks continue the codebase: Znuny, which maintains a long term support branch of the final Community Edition release, and OTOBO. Both are actively maintained open source projects. Organizations wanting a supported commercial product rather than a fork typically evaluate the current OTRS subscription or move to a different platform entirely.

Can a self-hosted service desk use AI features?

Yes, and this is one of the stronger arguments for self-hosting in 2026. AI that runs on your own hardware can summarize threads, draft replies, classify incoming tickets and surface similar past cases without any ticket content leaving your network. Confirm with the vendor that inference is genuinely local rather than encrypted transit to an external provider.

How much hardware does on-premise ITSM need?

For a mid-sized deployment, typically one application server with 4 to 8 vCPU and 8 to 16 GB RAM, a separate database instance, and storage sized primarily by attachment volume. Local AI inference adds a GPU requirement. Most organizations run this on existing virtualization capacity rather than buying hardware.

Can on-premise ITSM run in an air-gapped network?

Some products can, but fewer than claim to. You need offline installation, license activation that does not require internet access, and a signed offline update mechanism. Ask for each of the three explicitly and request a reference customer running the same way.

Next steps

If you are evaluating self-hosted options, the practical sequence is to write down your non-negotiables first, in this order: regulatory constraints, air-gap requirements, agent count over three years, and whether you have a named internal owner. Those four answers eliminate most of the market before you sit through a single demo.

Mint Service Desk has been developed for over 14 years and runs on-premise, air-gapped or in the cloud, with full ITSM and ESM functionality including SLA management, asset management, automation and locally hosted AI. If you want to see how it fits a specific environment, talk to our team or read how Oakford Technology deployed it on-premise across multiple UK schools.

‍