On-premise software options give organizations a way to control their data boundary. Your servers, your data center, your jurisdiction. You control the infrastructure, so you control the sensitive data. That model is being systematically dismantled, vendor by vendor, product by product.
This article does not answer whether you should migrate to your provider's cloud option. For many, that may be inevitable. The questions discussed are why this is occurring, what control of your data you surrender, what to consider pre-migration, and what you can do about retaining control over your most sensitive data.
On-premise options matter most for organizations collecting and processing data they cannot afford to expose. For these organizations, on-premise is not a legacy preference but a deliberate compliance and security decision.
Vendors frame the removal of that option as a technology upgrade. Cloud platforms are genuinely more capable in many ways. But the upgrade comes with a transfer of control that vendors do not advertise. You move from infrastructure you own and operate to infrastructure a vendor, owns, operates, and can access. That vendor is subject to their own government's laws, has visibility into your usage data, and strong commercial incentives to expand what they charge for it. The pace of that transfer has accelerated as AI bundling and consumption-based pricing have made customer data sitting in vendor-controlled environments increasingly valuable to the vendors themselves.
Vendors Are Setting the Deadlines for On-Premise
The shift away from on-premise is not driven by customer demand. It is a deliberate commercial strategy by enterprise software vendors to retire on-premise products and move customers to their cloud-hosted, subscription-based alternatives.
Several commercial and technological forces have converged to make this the moment vendors are pushing for the transition and sunsetting their on-premise offerings.
SAP is Ending Support for SAP ECC
SAP is ending mainstream support for SAP ECC on December 31, 2027. Extended maintenance runs until 2030 but at a premium.
The primary migration path SAP is pushing customers toward is RISE with SAP, a managed cloud subscription that bundles S/4HANA, SAP's next-generation ERP, with infrastructure and support services hosted on AWS, Azure, or Google Cloud. Organizations moving from on-premise ECC to RISE with SAP are moving from an environment they controlled to one managed by SAP on third-party cloud infrastructure, both subject to foreign jurisdiction.
Salesforce Wants You to Migrate to Hyperforce
Salesforce has never offered an on-premise product. It has always been a cloud-hosted platform, historically running on its own proprietary data centers. Salesforce is migrating all customers to Hyperforce, its next-generation infrastructure architecture that moves the platform from Salesforce's own data centers onto cloud infrastructure provided by AWS, Azure, and Google Cloud. This migration is not optional. Salesforce has stated that Hyperforce is the future of the platform and all customer organizations will move to it.
For data sovereignty purposes this creates a layered exposure. Your data sits in Salesforce's environment, a US-incorporated company. That environment runs on AWS, Azure, or Google Cloud, also US-incorporated.
Jira and Confluence are Removing Data Center
Atlassian ended support for its Server product line on February 15, 2024, removing the affordable self-hosted option for Jira and Confluence. A self-hosted Data Center option remains available at significantly higher cost, but Atlassian has announced that Data Center will reach end of life on March 28, 2029. Atlassian Cloud is the destination.
Atlassian was founded in Sydney and remains globally headquartered there, but redomiciled to the United States in October 2022 as a Delaware-incorporated company. It is listed on NASDAQ and maintains a US headquarters in San Francisco. As a US-domiciled company, it is subject to US jurisdiction, including the CLOUD Act. Organizations moving project data, documentation, and sensitive workflows from self-hosted Jira and Confluence to Atlassian Cloud are moving that data into an environment subject to US legal reach, regardless of which data center region they select.
ServiceNow is Sunsetting Edge Encryption
The retirement of on-premise deployment is not the only cause for concern. ServiceNow are retiring the product that made sovereign use of their cloud product possible. ServiceNow Edge Encryption is a proxy that runs in your environment, on infrastructure you control, and encrypts sensitive data before it leaves your environment, destined for ServiceNow. ServiceNow's cloud received only ciphertext. They never held plaintext.
The replacement, Platform Encryption, performs encryption inside ServiceNow's cloud environment. Sensitive data enters the platform in plaintext before being encrypted within its infrastructure. The cryptographic separation that Edge Encryption provided is gone. ServiceNow now holds plaintext, if only briefly, and that is enough to change the legal and security exposure entirely.
Learn more about how StratoKey can help replace ServiceNow Edge Encryption
Why the Cloud, and Why Now?
AI Product Development
The first is AI. Every major enterprise software vendor is building AI and automation capabilities into their platform. Those capabilities require your data. Vendors are not just moving customers to the cloud. They are building their next generation of products exclusively for it and need your data to do it.
Maintaining On-Premise Costs Vendors
The second is the cost of maintaining parallel products. Supporting both on-premise and cloud versions of the same software requires significant ongoing investment, especially as the features and capabilities diverge. Vendors have made a commercial decision that the on-premise customer base no longer justifies that cost.
Greater Revenue Growth Opportunity for Vendors
Lastly, (and not least), when software runs on your infrastructure, the vendor has limited visibility into how you use it. Cloud changes that. When the vendor hosts the environment, they have more granular visibility into usage patterns across their entire customer base. That data informs new products, drives pricing tiers, upsells services, and enables stronger license controls.
Vendors are locking customers into recurring revenue streams with regular annual uplifts at each renewal that they work out based on how you use their platform.
AI has accelerated the commercial shift in three ways.
First, it is used as a justification to raise prices. Vendors rebundle existing products with AI features and increase costs. Adobe increased prices by up to 27% using AI as the primary justification.
Second, AI is sold as a premium upsell. Features that were previously included are separated into higher tiers or add-on products. ServiceNow's Now Assist AI add-on adds 25 to 50% on top of existing platform costs.
Third, AI introduces the hybrid pricing model of consumption-based pricing on top of the common seat based. Rather than paying a fixed amount per user, organizations now face usage meters tied to tokens, API calls, and AI task execution.
What On-Premise Actually Protected
When your organization ran software on its own servers, the vendor had limited access to your data. The software ran on your infrastructure, operated and controlled by your own team.
This meant the vendor could not be compelled to produce it, could not expose it through a breach of their systems, and had limited visibility into it. For organizations handling regulated or sensitive data, that separation was the protection. Secondary to that, you were protected from the usage telemetry leveraged by vendors as they developed their pricing models, as well as the rise of marketplaces, plugins and AI.
Issues When You Move to the Cloud
In a standard SaaS deployment, the vendor manages the application, the infrastructure, and in many cases, any cryptographic features they also offer. Your data sits in their environment, likely hosted by a separate cloud provider. This creates exposure from both a data security and compliance perspective. There are several issues to consider:
-
Vendor access: The vendor and their employees, including support staff, have access to the environment your data lives in.
-
Third-party integrations: Most enterprise SaaS platforms connect to dozens of third-party services by default. Each integration is a potential access point with its own security posture and jurisdiction.
-
AI Exposure: AI capabilities embedded in SaaS platforms have access to data. In some cases that data informs model training or improvement. This is a poorly understood, hard-to-govern, and often overlooked expansion of the vendor's access to your data.
-
Legal compulsion from foreign jurisdictions: A court order served on a US-incorporated vendor reaches any data in their possession or control, regardless of which region it is stored in. The CLOUD Act, FISA Section 702, and Executive Order 12333 create three separate channels of US government access to data held by US providers (that's the lion's share of the market).
-
Breach exposure: Cloud vendor environments aggregate data from thousands of organizations, making them high-value targets. A single successful breach, whether through the vendor's systems, their identity management, agent, or a third-party integration, potentially exposes every customer at once.
-
Compliance: When sensitive data sits in a vendor-managed environment, that environment becomes part of your compliance boundary. This is harder to manage and can increase the scope and cost of compliance. Frameworks like CMMC, CPCSC, NIST SP 800-171, and ITAR require demonstrable control over where regulated data sits and who can access it. Not all cloud products have the ability to meet these requirements.
Using your vendor's cloud is not inherently a worse option than on-premises across use cases. For many organizations, it is the right choice and provides efficiencies and access to better features and less maintenance. But for organizations handling sensitive data, the default cloud model contains both regulatory and data security risks. Any benefit has tradeoffs.
What Do You Do if Your Provider Wants to Sunset Their On-Premise Offering?
The right response depends on why on-premises mattered to your organization. Work through these questions to help inform decisions.
What data are you protecting?
Take stock of your data. Not all data carries the same risk or requires the same access controls. Identify which fields or datasets are sensitive. Personnel records, IP, ePHI, CUI, and contract data carry different obligations than general operational data. This is the data you need to consider when choosing cloud hosting options or additional controls.
What are your compliance obligations?
You are likely already across this one. Are you subject to HIPAA, CMMC, NIST SP 800-171, ITAR, or DFARS? Does your framework require data to remain within a specific boundary or region? Or that you can demonstrate control over who accesses it? What are the requirements that your on-premises boundary provides that need to be considered before a migration?
Who needs access to your data and who does not?
Moving to the cloud means the vendor has access. Contractually saying they will not access your data is not the same as actually not being able to access your data. Assume a zero-trust approach. What are the controls they offer? Who needs access? What controls fall short?
Where will your data physically sit, and under what jurisdiction?
There may be options to select a cloud region or sovereign cloud. Keep in mind this is only a data residency decision, not a true sovereignty one. Organizations should understand which country's laws govern the vendor and whether that creates exposure for their specific data (and regulations).
Can you keep sensitive data from the vendor's environment entirely?
The previous questions may have exposed that you do have sensitive data, but not all of your data is sensitive. The next thing to consider is if your most sensitive data ever needs to leave your control and enter the vendors' at all? With pre-ingress tokenization and encryption, it does not have to. The key term is pre-ingress - your vendor's encryption feature likely falls short (that's why the sunsetting of ServiceNow Edge Encryption for example is problematic), as the cryptographic function managed within their environment means your sensitive data is still exposed to that environment in plain text.
Why you should host your own encryption gateway
StratoKey's Cloud Data Protection Gateway Secures Data Pre-Ingress
If you need to manage access and sovereignty, moving from on-premises to the cloud is still possible without forfeiting control. Pre-ingress tokenization and encryption, like that offered by the StratoKey Cloud Data Protection Gateway, means the vendor never receives sensitive data in readable form.
The Tokenization and Encryption Gateway is deployed into your environment. It sits between your organization and the vendor's cloud. Sensitive data is intercepted and tokenized or encrypted before it reaches the vendor. Access to the original plain text stays within your controlled boundary.
Your sensitive data is not accessible; The vendor processes tokens or ciphertext and the cloud application runs as usual for your users, while you maintain sovereign control over that sensitive data. Access to the underlying sensitive data is controlled through the gateway by your organization.
Wrap Up
A vendor that never received plaintext cannot produce it in response to a demand. A breach of their systems exposes nothing sensitive. Your compliance scope shrinks because sensitive data never enters their environment in readable form.
On-premises gave you control through infrastructure ownership. StratoKey gives you the same control through hosting your own encryption and tokenization gateway. The infrastructure may be changing, but your control over sensitive data does not have to.
The Death of On-Premise and What it Means for Your Sensitive Data
On-premise software options give organizations a way to control their data boundary. Your servers, your data center, your jurisdiction. You control..
Salesforce Breach Highlights Why Encryption Gateways Are Essential
In October 2025, Salesforce confirmed it would not pay a ransom demand following claims that nearly 1 billion customer records were stolen via..