In the world of enterprise software, a seismic shift is underway. For years, companies chose on-premise solutions for control and stability, but now, vendors are increasingly mandating a move to the cloud. This vendor-led push is changing the rules of the game, forcing businesses to re-evaluate strategy, risk, and their very relationship with technology partners. We’re joined by Vijay Raina, a veteran architect who has guided large organizations through these exact transitions, to unpack what he calls the “great SaaS squeeze” and explore how enterprises can navigate this new reality.
We’re seeing established vendors like Epicor sunsetting their on-premise ERPs. What are the primary business drivers for this vendor-led push to SaaS, and how does this shift the balance of power in the vendor-customer relationship?
This is absolutely a vendor-driven trend, not a response to customer demand. The balance of power has decisively shifted from buyers to vendors. For software companies like Epicor, the business case is overwhelmingly clear. Managing a single, cloud-based code base for products like Kinetic and Prophet 21 is dramatically less expensive than supporting countless on-prem versions. They can centralize security, accelerate upgrades, and roll out new AI-powered features universally. It creates a predictable, recurring revenue stream and simplifies their entire engineering organization. But that efficiency comes at the cost of customer choice, and we’re seeing enterprises being pushed, not pulled, into a model that primarily serves the vendor’s bottom line.
For mission-critical systems, many enterprises chose on-prem for control and reliability. When a vendor mandates a move to the cloud, what specific anxieties around latency, security, and operational uptime immediately emerge for that company? Could you walk us through a typical client’s initial concerns?
The anxiety is immediate and palpable. I recently spoke with a long-time client right after Epicor’s announcement, and their concerns were far from theoretical. They chose on-premise ERP precisely because its reliability is mission-critical to their operations. The first fear is always latency—the idea that processes which used to happen locally will now be subject to network delays, which can be devastating for something like shop-floor automation. Then comes security and compliance; their entire risk model, which they’ve spent years refining, is suddenly upended. They have to trust the vendor’s security posture on a public cloud like Microsoft Azure. And finally, uptime. We all saw major cloud outages last year, which served as a stark reminder that the cloud is no panacea for risk. The feeling is one of losing control over the systems that are the lifeblood of your business.
When a vendor moves its software to a public cloud like Azure, a company’s compliance posture can change overnight. What key questions about data residency, contractual remedies, and sovereign cloud options must a business in a regulated industry ask?
This is one of the most critical and often overlooked areas. You absolutely cannot assume your existing compliance status will just carry over. The first thing I tell clients is to demand specifics and supporting evidence. You need to ask tough, direct questions. Where will our data actually reside, and can you provide transparency and guarantees on data residency? What are the specific penalties and contractual remedies if a compliance issue arises on your platform? For those in tightly regulated sectors, you must press on whether the SaaS environment supports regional or sovereign cloud options that might be required by law. The burden of proof is on the vendor, and if they can’t provide clear, contractual answers, that’s a massive red flag.
Consider a manufacturer with latency-sensitive, shop-floor automation. How should they rigorously test a vendor’s SaaS offering for real-world performance impacts before migrating, and what specific performance service-level agreements should they demand in their contract?
For a manufacturer in that position, vendor-provided averages are useless. The testing has to be rigorous and mimic their real-world environment. This means conducting benchmarks using their actual workloads, from their specific user locations and production facilities. Even small delays in a latency-sensitive workflow can ripple through the entire production line. They need to demand data on where the service is physically located and the network path their data will travel. More importantly, this must be formalized in the contract. They should be pressing for specific performance service-level agreements (SLAs) that define acceptable latency and uptime. If a vendor is hesitant to commit to performance SLAs, it suggests they may not be confident their centralized SaaS solution can meet the demands of that specific use case.
Moving to a vendor-managed model means losing self-management during outages. What new risks does this introduce for operational continuity, and how can companies negotiate contracts to ensure clear recovery objectives (RTOs/RPOs) and guaranteed data access outside the vendor’s “walled garden” during a crisis?
The loss of self-management is a profound shift in risk. When you ran the system on-prem, your team could roll back a bad patch or manage an outage directly. In a SaaS model, you’re entirely dependent on the vendor’s support team and their escalation paths. This introduces the risk of being stuck during a crisis, waiting in a support queue while your business is down. To mitigate this, contract negotiations are paramount. You must secure clear, contractually-defined Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Furthermore, you have to fight for a way out of their “walled garden.” I always advise clients to negotiate for guaranteed data access and portability, ensuring that in a worst-case scenario—like a prolonged provider outage—you have the means to access your core data and maintain some level of operational continuity.
If a vendor’s SaaS model is a poor fit for a company’s specific needs, what are the most viable alternatives to consider? Beyond simply switching vendors, how can they build a practical exit strategy into a new SaaS contract to ensure data portability in the future?
If the vendor’s rigid SaaS model genuinely cannot meet your non-negotiable requirements for compliance, latency, or control, it’s time to seriously evaluate if the relationship should continue. The market does offer alternatives, such as managed private clouds that provide more control, hybrid solutions, or even open-source ERP systems for certain niche cases. However, if you do decide to proceed with the SaaS transition, building in an exit strategy from day one is non-negotiable. This goes beyond a simple break clause. The contract must include explicit guarantees that you can get all your data out in a standard, usable format. This contractual guarantee of data portability is your insurance policy, ensuring that you have the practical ability to migrate to a new provider if the relationship sours or the service fails to deliver down the line.
What is your forecast for the on-premise software market? Will it disappear completely, or will a new equilibrium between SaaS, private cloud, and on-prem solutions emerge for certain industries or use cases?
While the vendor-led push to SaaS is incredibly strong and the traditional on-premise market is certainly shrinking, I don’t believe it will vanish entirely. Instead, I foresee a new, more complex equilibrium emerging. The one-size-fits-all SaaS model simply won’t work for every organization, especially those with unique compliance, security, or performance needs in sectors like manufacturing or government. This will force a market for alternatives to mature, including specialized managed private clouds and sophisticated hybrid architectures. Enterprises are becoming more vigilant, demanding tighter governance and more rigorous contracts. Success in this new era will belong to the best-prepared companies—those who approach this shift with clear eyes, strong questions, and a willingness to explore architectures that truly fit their business, rather than simply accepting the trade-offs a vendor imposes.
