On-prem deployment cost: what enterprise deals really add

Why this request changes the deal

A standard SaaS price assumes one shared product, one release process, and a support model you control. An on-prem request breaks that model fast. You stop running the software only in your own environment and start helping a customer run it in theirs, with their rules, network, and security team in the middle.

That shift matters because the work does not stop at delivery. Buyers often say they want the same product, just deployed inside their own environment. In practice, they ask for packaging changes, install guides, environment checks, access rules, backup guidance, answers for audit teams, and help during internal reviews. The product may stay the same. The operating load does not.

That is why on-prem deployment cost has little in common with a normal SaaS subscription. SaaS spreads hosting, upgrades, monitoring, and support across many customers. On-prem pushes part of that work back to your team, one customer at a time. If three buyers use three different clouds, VPN setups, or approval processes, you do the work three times.

It helps to split the deal into two buckets. First comes the one-time work: setup, deployment design, install testing, documentation, security review support, and go-live help. Then comes the recurring work: upgrades, incident support, patching advice, compatibility checks, and security follow-up.

Teams often miss the second bucket. Sales hears "self-hosted" and thinks "same software, different hosting." Engineering and support find the real cost later, usually during procurement or right after signing. That is when the customer asks who owns version upgrades, how fast you respond to production issues, whether you support their Kubernetes version, and what happens when their security team bans a dependency.

A deal that looked simple can turn into a custom operating commitment. If you price it like normal SaaS, margin disappears quietly. The mistake rarely shows up in the first invoice. It appears over the next 12 months, one support ticket, one patch, and one delayed upgrade at a time.

What buyers mean by on-prem

Enterprise buyers often say "on-prem" when they really mean "we want more control." That sounds clear enough, but it can describe very different setups. Each one changes scope, risk, and cost.

Four common setups

True on-prem means the software runs on the buyer's own servers, in their office or data center. Their team usually controls the network, storage, and access rules.

Private cloud means the software runs in a dedicated environment in AWS, Google Cloud, Azure, or another provider. It is separate from shared SaaS, but it is still cloud infrastructure.

Single-tenant means the buyer gets isolated app and database instances. You may still host it and handle most maintenance.

Air-gapped means the environment has little or no internet access. Updates, logs, license checks, and remote support all become slower and more manual.

These are not small wording differences. They decide who owns the work after the contract is signed.

Ask where the software will run. Then ask who controls access. If the buyer owns the servers, VPN, firewall, and admin accounts, your team depends on their process for almost every change. If you host a single-tenant setup, you keep more control, but you also keep more of the operational burden.

The next question is even more practical: who patches the operating system, database, reverse proxy, and backup tools? Many teams price the application and forget the rest of the stack. If nobody names an owner for patching, that work usually drifts back to the vendor during the first security review.

Support terms need the same level of detail. One buyer expects business-hours email support. Another expects 24/7 incident response, uptime commitments, and named escalation paths into engineering. Those are different promises. They should not sit under one vague line item.

A common example: procurement asks for on-prem, but the security team later says a dedicated cloud account is fine. That is not true on-prem. It is closer to private cloud, and it often costs less to run and support. If you do not sort that out early, enterprise on-prem pricing becomes guesswork.

Hosting costs you need to count

Most teams price the license and forget the machines. That is where the quote starts drifting from reality.

The buyer usually expects more than one server and one database. They want enough compute for production, enough storage for growth, enough network headroom for peak traffic, and enough backup space to recover after a bad day. If their security team asks for longer log retention or encrypted backups in a separate zone, the bill grows again.

Production is only part of it. Enterprise buyers often need separate environments for testing, staging, and disaster recovery. Even when those environments are smaller, they still need storage, patching, certificates, and access rules. A deal that looked small on a sales call can turn into four environments before anyone notices.

A realistic budget usually includes compute, storage, and network capacity for normal use and traffic spikes; backup retention and restore testing; staging, test, and failover environments; monitoring and logging; and the engineer time needed to install, harden, patch, and maintain everything.

Tooling gets missed all the time. You may already use Grafana, Prometheus, Loki, Sentry, or similar tools in your own setup, but the customer may require separate instances, paid connectors, or their internal tools instead. That adds more setup work and more moving parts to maintain.

Engineer time is often the biggest blind spot. Someone has to prepare the servers, harden the operating system, configure secrets, set backup jobs, test recovery, tune alerts, and keep packages up to date. Then someone has to repeat part of that work every month. If you price only hardware or cloud spend, you leave out the labor that keeps the system healthy.

A small example makes this obvious. A buyer asks for a self-hosted app for 500 internal users. Sales prices one production cluster. Operations later adds a staging environment, a reporting replica, nightly backups, log retention for 90 days, and an offsite recovery target. The monthly bill changes, but the bigger change is staff time.

If you already run lean infrastructure, you can keep some of this under control. Careful architecture cuts waste. It does not remove the extra environments, tooling, and maintenance that enterprise buyers usually expect.

Support work after go-live

After launch, the work changes shape. Fewer people talk about the deal, and more people open tickets, request access, report errors, and call when something breaks on a Friday night.

Many teams guess low here. That is one of the easiest ways to understate cost, because support on a customer-run install almost always takes more time than support on your own hosted setup.

Start with ticket volume, not hope. Use whatever history you have from enterprise deals, pilots, or support logs, then adjust for the buyer's setup. A customer with custom SSO, strict firewall rules, and separate test and production environments will create more work than a buyer using your standard cloud version.

The first 30 to 90 days usually bring the heaviest load. Users ask for role changes, admins need help reading logs, and someone wants proof that backups, alerts, and scheduled jobs work the way they should. Those requests are normal. They still cost time.

You also need a clear line between user issues and platform issues. If you leave that fuzzy, your team becomes the help desk for everything.

A practical split is simple. The buyer's IT team handles password resets, user onboarding, local network access, and device problems. Your team handles product bugs, deployment failures, data issues inside the app, and configuration problems you own. Shared issues, such as SSO failures or mail delivery problems, need one named contact on each side.

Incident response needs its own price. If the buyer expects a one-hour response, weekend coverage, or an engineer on standby, do not hide that inside a vague support fee. Standby time costs money even when nothing happens because you are reserving someone's evening, weekend, or holiday.

Count the small tasks too. Access requests, log reviews, certificate checks, environment health checks, and "can you verify this is working" messages can eat hours every month. None of them look big on their own. Together they can turn a decent deal into a bad one.

A fair support model usually has three parts: a monthly base fee, a defined number of hours, and a separate rate for after-hours work. That keeps expectations clear and gives sales a number they can defend.

Upgrade work that keeps coming back

A cloud customer can usually take your next release when you ship it. An on-prem customer often cannot. They have their own maintenance windows, approval chain, security review, and testing calendar. A release that takes one hour in your hosted setup can turn into a two-week process on their side.

This is where cost grows faster than many teams expect. You do not just build the new version once. You package it for their environment, check whether it still works with their database version, OS, network rules, and local integrations, then prepare a safe way back if the upgrade fails.

That recurring work includes packaging and testing for the buyer's setup, compatibility checks against their current stack and any custom changes, a rollback plan that actually works, scheduled change windows that may land at awkward hours, and post-upgrade testing after approval.

Most on-prem customers also skip your preferred upgrade schedule. They may stay six months or a year behind because another internal project takes priority or because they want to avoid retraining users. When that happens, they still ask for security fixes and selected feature updates. Now your team supports two paths at once: the current release and an older branch. That means custom patch work, extra QA, and more decisions about what to backport.

The slow part is not only technical. Internal approvals eat time. Someone has to fill out change requests, answer questions from security or operations, wait for a maintenance slot, and then run the same checks again when the slot finally opens. If the buyer delays the window, your team repeats part of the work.

A fair price should treat upgrades as an ongoing service, not as a one-time setup fee. If the buyer wants quarterly updates, old-version patching, and weekend change windows, put each item in the quote. Otherwise the margin disappears later, one "small" upgrade at a time.

Security work sales teams often miss

Security work starts long before the buyer signs. Enterprise teams often send security questionnaires, architecture reviews, data handling questions, and legal security terms during procurement. If you quote the deal before you see that package, you are guessing. That guess usually cuts your margin.

A basic review rarely stays basic. One buyer asks for a deployment diagram and backup plan. Another wants proof of encryption settings, access controls, audit logs, vulnerability management, incident response steps, and patch windows for every part of the stack.

Count the setup work, not just the software. In self-hosted deals, teams often need to harden servers, lock down admin access, define how secrets are stored and rotated, confirm what gets logged, and test whether backups actually restore. Each task sounds small on its own. Together, they add real hours.

Before you send a number, ask for the buyer's security review pack, list the hardening tasks for servers and databases, define secrets handling and audit log scope, estimate scans and pen tests with follow-up fixes, and decide who owns emergency patch timing and approvals.

Vulnerability scans and pen tests need honest pricing. The test itself costs money, but the larger cost often appears after the report arrives. Your team may need to explain accepted risks, fix medium findings that are not urgent, retest, and answer another round of policy questions from security and procurement.

Policy work also takes time. Buyers ask who can access production, where logs live, how long data stays in backups, and what happens during a security event. These are not filler questions. Someone has to write clear answers, and someone technical has to check that those answers match reality.

Patch ownership causes trouble when nobody decides it early. If a serious security issue appears on Friday night, who approves the patch, who applies it, who tests it, and who accepts downtime risk? Put that in writing before go-live. If you skip it, support turns into an argument during the worst possible week.

Security review work belongs in enterprise on-prem pricing. It is not a free extra.

How to price it step by step

Start with one scope sheet that records every buyer demand in plain language. If it is not on that sheet, do not price it yet. Enterprise buyers often say "on-prem" when they also mean VPN access, SSO, audit logs, custom backup rules, staged releases, and a security review.

A clean estimate splits the work into three buckets. Setup covers the one-time work to install, configure, document, and test. Monthly operations cover monitoring, patching, backup checks, support, and routine security work. Change requests cover everything the buyer adds later, such as a new identity provider or a custom upgrade window.

For each line item, estimate people time first and infrastructure second. Teams often price servers and forget the hours from engineers, DevOps, support, and project management. That is where estimates usually go off track.

A good worksheet includes setup tasks with hours by role, monthly operations with expected hours, buyer-specific requests that sit outside the base quote, tool and vendor costs such as security scans or audits, and a buffer for unclear items or slow buyer approvals.

Tool costs matter more than many teams expect. You may need monitoring, log retention, backup software, a VPN, a private container registry, or extra CI runners. Some buyers also ask for audit evidence, penetration testing, or long security questionnaires. Those requests take time even when no code changes.

After you total the hours and direct costs, turn the estimate into a price with limits and assumptions. State how many environments are included, who owns the infrastructure, what response times you cover, how upgrades happen, and what sits outside scope. If you skip this part, the quote can look fine at signing and start losing money after go-live.

One habit helps a lot: attach a short assumptions page to every enterprise on-prem proposal. If the buyer later asks for SSO, air-gapped updates, or a separate staging cluster, you can price that as a change request instead of absorbing it for free.

A simple example with one buyer

A mid-size SaaS company sells quality management software to industrial clients. One regulated manufacturer wants the product, but only if the vendor hosts it in the buyer's environment, provides access through a VPN, and assigns two named support contacts for any issue that reaches production.

That can look like a normal enterprise request. It is not. The team can no longer treat delivery, support, and upgrades like their standard cloud plan.

A first pass might look like this:

• Setup and deployment work: about $29,000
• Monthly support and access management: about $5,000 per month
• Each planned upgrade: about $6,000
• Base software subscription: $72,000 per year

The setup cost grows quickly because the vendor has to do more than install the app. They need to package it for the buyer's environment, work through VPN access, test backup and restore, prepare a rollback plan, and sit in several meetings with the buyer's IT and security teams. That can easily take 150 to 170 hours before go-live.

Monthly support is not just ticket handling. Two named contacts mean the vendor must reserve specific people, keep access working, review logs, help with certificate renewals, and coordinate maintenance windows. Even if nothing breaks, the team still spends time on the account. A realistic budget is around 20 support hours a month plus an after-hours retainer.

Upgrades are where many teams underprice self-hosted software support. In the vendor's normal cloud product, they ship updates once and move on. For this buyer, every major release needs a test cycle in the buyer's environment, change approval, a scheduled install window, and post-upgrade checks. If the buyer wants two planned upgrades a year, that adds roughly $12,000 more.

Now the price looks very different. Sales first thought they could close the deal at $72,000 a year with a small $10,000 setup fee. After honest scoping, year one is closer to $173,000: $72,000 for the product, about $29,000 for setup, $60,000 for support over 12 months, and about $12,000 for planned upgrades.

That gap is the real cost of the on-prem request. If the buyer wants the control, the vendor has to charge for the work. If the price feels too high, both sides can trim scope first, such as using one named contact instead of two or limiting upgrades to once a year.

Mistakes that eat your margin

The easiest way to lose money on an enterprise deal is to treat on-prem as a hosting choice. It is not. It changes delivery, support, security review, upgrades, and who carries the risk when something breaks. Most of the cost comes from labor, not servers.

A lot of teams price the buyer's infrastructure and forget the service around it. Someone has to help with install guides, network rules, certificate setup, backup checks, restore tests, and odd constraints inside the buyer's environment. If their stack is older or heavily locked down, your team can burn days before the product even runs cleanly.

Custom patches can wreck margin faster than almost anything else. A buyer asks for one fix outside the normal release cycle, then wants another change on the same old version a month later. Now your team keeps a separate branch, tests more combinations, and explains why their environment behaves differently. That work needs its own line item.

Security work also gets underpriced all the time. Sales hears "security review" and thinks of one call. In practice, the buyer may send long questionnaires, request access reviews, ask for audit evidence, and push follow-up questions to engineering. Even a small deal can eat a week here.

Support estimates often fail for a simpler reason. The buyer says ticket volume will stay low, but each ticket moves slower in an on-prem setup. Your team may need a maintenance window, VPN access, a customer admin, and approval from their internal IT group before anyone can even inspect the issue.

The worst mistake is saying yes before ops and finance review the numbers. That review should cover extra engineer hours before go-live, patch and upgrade policy, security review workload, support response rules, access limits, and the margin if the deal drags on longer than planned.

If you bring in senior technical help early, hidden work shows up faster. That is often where someone like Oleg Sotnikov can help: reviewing the real support, infrastructure, and upgrade load before sales locks in a number. A short advisory pass is much cheaper than carrying a bad contract for a year.

Quick checks before you commit

Enterprise buyers often say "we can host it" as if that settles the issue. It does not. A deployment plan is still vague until both sides name who does the work when servers fail, backups break, or an update goes wrong.

Before you price the deal, get written answers to a few points. Who owns the servers, backups, monitoring, and incident response? If the buyer runs the machines but expects your team to wake up at 2 a.m., you still carry operations work.

What support hours do they expect? "Business hours" and 24/7 support create very different staffing costs. Pin down response times, escalation paths, and who joins a live incident call.

When can you deploy upgrades, and how do rollbacks work? Some buyers allow a monthly window. Others want weekend work, formal approval, and a tested rollback for every release.

Who can approve emergency changes and security patches? If nobody can sign off fast, your team may own the risk but lack the authority to fix it.

And if the scope is still fuzzy, stop and sell a paid discovery phase before you lock in a fixed price.

That last point matters more than many teams admit. A short discovery phase can uncover hidden work fast: firewall reviews, VPN setup, audit logs, separate staging environments, patch rules, or extra documentation for the buyer's IT team. Skip that step and a "simple" deal can turn into months of work that nobody priced.

You are not only pricing software here. You are pricing waiting time, coordination, approvals, and ownership when something breaks.

If your team does not estimate custom hosting, support, or security work often, get a second opinion before you sign. On oleg.is, Oleg Sotnikov works with startups and small teams on exactly this kind of technical scoping, from infrastructure and product architecture to AI-driven engineering workflows. A short review before the contract is signed can save a lot of money after it is.