When Cloud Sounds Like Cheaper Hosting

12 min read

The Infrastructure Illusion

The conversation usually starts the same way.

The owner talks to a customer who asks, “Do you have a cloud version?” A sales lead loses a deal because “IT doesn’t want another on-prem install.” A consultant drops the phrase “cloud migration” into a meeting like it’s a weekend chore. Someone forwards a chart about SaaS (Software as a Service: you run it for customers) margins. A competitor launches a SaaS version.

Then the real question lands, from the person who has to pay salaries: “Are we falling behind?”

The same confusion shows up in It’s Just a Simple Rewrite — A Story of Estimates, Egos, and Eventual Success.

The first thought is always tempting. You already have working software. You already have customers. Cloud providers offer infrastructure. So you move the application from customer servers to your servers in a data center. Done. Right?

Wrong. And the mistake is predictable.

When you’ve been selling on-premise software for years, the cloud looks like an infrastructure detail. Your software works. Your customers use it. Moving it to centralized infrastructure feels like a technical task, not a business transformation.

Installation Is Not Operations

On-premise is not “rolled out” by you in the modern sense. It is installed by the customer.

Somebody runs an installer. A sysadmin schedules downtime. A key user tests it. Then it stays on a version for a long time because upgrades feel like risk.

That upgrade gravity is not a footnote. It defines the product.

On-premise reality:

• Customers decide when to take a new version.
• Many customers never take it until something breaks or a major feature forces their hand.
• You support multiple versions in parallel because you have to.
• Bugs can be fixed and still stay alive in the wild because customers are months or years behind.

SaaS reality:

• You decide when a new version goes live.
• Every release affects everyone.
• You run CI/CD (continuous integration and continuous delivery) and continuous deployment as a normal operating mode. Many teams push changes several times a day.
• Backward compatibility and data migration are now your problem, every time.
• “Ship it and let customers upgrade” stops being a strategy.

Once that lands, the cloud story stops sounding like a bargain and starts sounding like a second company.

What You’re Actually Proposing

When you say “move to the cloud,” here’s what you’re really saying, whether you like it or not:

You’re changing from selling a product to operating a service. On-premise software ships once per customer. You deliver it, they install it, it runs on their infrastructure. Your responsibility largely ends at installation support.

Cloud software runs continuously on your infrastructure for all customers. You’re now responsible for uptime, performance, security, backups, disaster recovery, and incident response. Twenty-four hours a day. Seven days a week. Forever.

You’re becoming a data custodian. Previously, customer data lived on customer servers. If they lost data, it was their backup failure. If they got breached, it was their security problem.

Now you hold all customer data. You’re responsible for protecting it, backing it up, and staying compliant.

In Europe that means GDPR, plus whatever your customers sit under (works councils, sector rules, data residency expectations, audit requirements). In the US it can mean HIPAA (healthcare), PCI DSS (payments), GLBA (financial services), and a growing pile of state privacy laws.

If you get this wrong, you do not just get a nasty email. You get regulatory attention, contractual penalties, and customers who will never trust you again.

You’re accepting continuous operational burden. On-premise software could accumulate bugs. Customers would report them. You’d fix them in the next release. Urgency was often low because customers were running stable versions and could choose when (or if) to install the update.

Cloud software must be monitored constantly. Performance issues affect all customers simultaneously. Security vulnerabilities must be patched immediately. Database migrations must happen without downtime. Every change creates risk across your entire customer base.

You’re shifting from perpetual licenses to subscriptions. This isn’t just a pricing change. It’s a fundamental shift in customer relationship, cash flow, and revenue recognition.

In on-premise, customers buy a license, often pay annual maintenance, and treat major upgrades like a new purchase or a new project. Version lag is normal.

None of this is obvious when you’re staring at AWS pricing and thinking, “We can run this cheaper than our customers run their own servers.”

The Skills Gap Nobody Budgets For

Your development team has been building features for an on-premise product. They understand the domain. They know the codebase. They ship updates twice a year.

Operating a cloud service requires completely different skills:

Continuous releases. You can’t ship twice a year anymore. You need automated pipelines, gradual rollouts, feature flags, and rollback procedures. Releases must be safe to run multiple times per day.

Observability. You need logging, metrics, tracing, and alerting across the entire stack. When something breaks, you have minutes to diagnose and fix it, not days. You must know what normal looks like so you can detect abnormal.

Incident response. At 3 AM on Sunday, when the database starts timing out, someone needs to investigate, mitigate, and fix the issue. You need on-call rotations, runbooks, post-incident reviews, and the discipline to actually use them.

Security operations. Patching vulnerabilities immediately. Managing secrets safely. Rotating credentials. Monitoring for intrusions. Responding to security incidents. Passing compliance audits. This isn’t optional. It’s the price of holding customer data.

Performance engineering. When all customers share infrastructure, one customer’s spike affects everyone. You need resource isolation, capacity planning, auto-scaling, and performance monitoring. “It works on my laptop” is no longer sufficient.

Database operations. Schema migrations without downtime. Backup verification. Replication monitoring. Query optimization under load. Point-in-time recovery. These are specialized skills your team may not have.

Your three developers who’ve been shipping features twice a year? They don’t know how to do any of this. Neither does your support team. Neither do you.

Predictable delivery requires technical practices that drive business results, not just good intentions.

The Support Model Transforms

On-premise support is reactive. Customer calls with a problem. You help them troubleshoot. If it’s a bug, you fix it in the next release. If it’s their configuration, you guide them to fix it. Either way, the problem is localized to one customer.

Cloud support is proactive and universal. You must detect problems before customers report them. When you release a buggy version, all customers experience the bug simultaneously.

To even survive that release cadence, you need orchestration: rolling upgrades without downtime, staged rollouts by cohort, canary releases, feature flags, A/B tests, and the ability to roll back fast when reality disagrees with your plan.

When performance degrades, everyone notices. Your support team, trained to handle individual customer issues, now needs to think in terms of platform health. They need dashboards showing system-wide metrics. They need to distinguish between individual customer issues and platform-wide incidents. They need to coordinate with development during releases.

This requires new tools, new processes, and new skills. Support tickets stop being “Customer A can’t print invoices” and start being “Database query performance degraded 40% in the last hour: which customers are affected?”

The Cost Structure Nobody Mentions

The sales pitch for cloud is cheaper infrastructure. No more customers buying expensive servers. Centralized hosting means economies of scale. Lower costs, better margins.

Be precise about what that pitch is and who it was made for.

“Cloud is cheaper” is the hyperscaler story told to software vendors who already run SaaS and already carry the operational burden. Those vendors are comparing their own data centers to renting someone else’s capacity.

If you’re coming from on-premise, you are not making that comparison. You’re buying your way into a new line of business: operations.

Reality is more expensive than anyone budgeted:

Infrastructure costs. You’re not just hosting the application. You need production environments, staging environments, development environments, disaster recovery environments. You need monitoring infrastructure, logging infrastructure, backup storage, and redundancy. The monthly AWS bill grows faster than customer count.

Operational headcount. You need DevOps engineers, database administrators, security specialists, and site reliability engineers. These aren’t optional. They’re the minimum team to keep a cloud service running safely.

Security and compliance. GDPR obligations. ISO 27001 audits (or equivalents, depending on your customers). Penetration testing. Vulnerability scanning. Data encryption. Access controls. Compliance consulting. It adds up fast.

On-call compensation. When you expect people to respond to incidents at 3 AM, you pay them for availability. On-call rotations aren’t volunteer work.

Higher development velocity. You can’t ship twice a year anymore. Competitors ship daily. You need continuous integration, automated testing, and faster development cycles. This requires better tooling and more disciplined engineering.

What Your Customers Actually Get

You’re selling this transition as “same great software, now in the cloud.” Your customers hear “convenience” and “reduced IT burden.”

What they’re actually getting:

Loss of control. They can’t choose when to upgrade. They can’t customize the installation. They can’t run modified versions. They depend entirely on your operational competence.

Shared fate. When your service goes down, their business stops. When your database has issues, their data is inaccessible. When you ship bugs, they suffer the consequences.

Subscription dependency. They can’t stop paying without losing access to their data. They’re locked into your pricing. They’re vulnerable to price increases.

Privacy concerns. Their data now lives on infrastructure they don’t control. They must trust your security, your compliance, and your business stability.

For some customers, this trade-off is worth it. For others, especially in regulated industries or with strict data sovereignty requirements, it’s unacceptable.

Your pricing strategy may push you there anyway. Expect churn from customers who valued control over convenience.

The Migration Nobody Planned For

Moving existing on-premise installations to your cloud service sounds straightforward. Customers export their data, you import it, they start using the cloud version.

In practice, migration is a nightmare:

Data consistency. Every customer has years of accumulated data in slightly different schemas because they installed different versions over time. You need migration scripts that handle every version, every edge case, every customization.

Downtime windows. Customers running 24/7 operations can’t tolerate downtime for migration. You need online migration strategies that keep both systems running during transition.

Testing. How do you verify migrated data is correct? Automated tests only catch so much. Manual verification across hundreds of customers is impractical.

Rollback. When migration fails mid-process, and it will, how do you roll back safely without losing data?

Support load. Every migrating customer needs hand-holding. Your support team, already stretched, now handles migration support on top of normal operations.

Successfully governing legacy modernization requires treating migration as a first-class project, not a weekend task.

Perpetual licenses generate large upfront revenue. Customer pays €50,000 once. You recognize the revenue immediately. Cash flow is predictable. Annual maintenance fees provide steady baseline income.

Subscription revenue is the opposite. Customer pays €500/month. You do not get the cash up front. Churn is always waiting. You need more customers to replace the same perpetual license revenue.

Most established software companies underestimate the financial transition period. For two to five years, you’re supporting both models: on-premise customers on maintenance and new cloud subscribers. Revenue dips. Costs increase. Then it stops being theory and becomes cash flow.

You still have payroll. You still have support obligations. You still have customers on old versions who will call on Friday afternoon with a production issue and expect you to care.

If this feels like failure, that’s because it looks like failure for a while. It’s the J-curve of business model transformation. It requires reserves and discipline that many owner-operated companies underestimate, because day-to-day delivery already eats everything.

What It Actually Takes

Moving an established software business to the cloud is doable. It’s just not cheap, and it’s not a side project. Success requires you to stop lying to yourself about what you’re signing up for:

Operational investment. Budget for DevOps engineers, database administrators, security specialists, and SRE capacity before you launch. Trying to operate cloud infrastructure with your existing feature development team is a recipe for disaster.

Skill development. Send your developers to training on cloud-native architecture, observability, incident response, and security. This isn’t optional education. It’s survival.

Cultural change. Your engineering culture must shift from “ship features twice a year” to “operate a service continuously.” This requires new incentives, new processes, and new leadership.

Dual-track support. Plan to support both on-premise and cloud simultaneously for years, not months. Budget for the duplicate operational burden.

Financial patience. Subscription revenue takes years to exceed perpetual license revenue. Ensure you have runway to survive the transition.

Customer empathy. Not all customers want cloud. Offer hybrid options. Respect customer concerns about control and data sovereignty.

The Way Forward

Cloud isn’t just cheaper hosting. It’s a fundamental transformation from product company to service operator.

If you’re an established software company considering this transition, here’s what you must understand:

It’s harder than it looks. The infrastructure is the easy part. The operational discipline, the cultural change, and the business model transformation are what determines success or failure.

Your current team isn’t ready. They’re skilled at building features. Operating a service requires different skills. Invest in training or hiring before you launch.

The financial transition is painful. Budget for years of dual operations and depressed revenue before subscription income exceeds perpetual licenses.

Not all customers will follow. Some prefer control. Some can’t legally use cloud services. Plan for attrition.

Competitors who started cloud-native have advantages. They built operational discipline from day one. You’re retrofitting it onto an existing product and culture. That’s harder.

The companies that succeed stop pretending it’s just infrastructure. They invest in operational capability. They train their teams. They communicate honestly with customers. They swallow short-term pain for long-term survival.

The companies that fail treat it as a technical migration. They underfund operations. They underestimate the culture shift. They assume existing capabilities transfer. Then they’re surprised when the service is flaky, customers churn, and costs spiral.

Cloud isn’t magic. It’s a different business model with different demands, different economics, and different risks. Respect that, or join the graveyard of traditional software companies that thought hosting was the hard part.