By Neno Duplan, Founder and CEO, Locus Technologies
Reading Time: 7 minutes 38 seconds
At a recent presentation to EHS practitioners, I put a simple statement on the screen: “Not everything sold as cloud is actually cloud.” The response from the room — a mix of recognition and mild surprise — told me this point lands differently than most software topics. People have a general sense that “cloud” has been stretched, but they rarely have the vocabulary to challenge a vendor on it.
This article gives you that vocabulary.
Among the top EHS SaaS providers currently competing for enterprise contracts, including Locus Technologies, VelocityEHS, Cority, Enablon, Intelex, and Sphera, the word “cloud” is applied to a wide range of underlying architectures. Some of those architectures were designed for the cloud from the beginning. Others were designed for on-premises installation and later moved to cloud hosting. The gap between those two origins is not cosmetic.
What Cloud-Native Actually Means
A cloud-native platform was designed from its first line of code to operate in a multitenant, continuously deployed, horizontally scalable environment. There is no installation process. There is no per-customer server configuration. Every customer runs on the same codebase, the same deployment, and is always on the current version automatically, without any migration project on their end.
True multitenancy is the architectural proof point. In a multitenant system, all customers share one software instance. When the vendor patches a security vulnerability, all customers receive it simultaneously. When a new EPA calculation methodology is incorporated, every customer’s system reflects it on the release date. There is one version of the software in the world.
When a vendor says their platform is cloud-based and you ask whether all customers run on the same deployment and are always on the current version, the answer tells you immediately whether you are dealing with true multitenancy or something else.
What Cloud-Hosted Actually Means
Cloud-hosted means the software runs on infrastructure provided by a cloud platform, typically AWS, Microsoft Azure, or Google Cloud, rather than on servers owned, operated, or maintained by the customer. That can be a meaningful operational improvement over traditional on-premises installation. However, cloud hosting alone does not change the software’s underlying architecture.
A single-tenant application running on AWS is still just a single-tenant application. Each customer still has a separate instance and updates may still need to be coordinated customer by customer. Over time, version fragmentation can accumulate.
Customer A may be running a version from eight months ago because their implementation team has not completed testing of the current release. Customer B may have received a security update but not the new regulatory calculation module. The vendor’s support organization may then be forced to manage dozens of versions simultaneously.
The practical consequences for EHS compliance are significant. Regulatory requirements do not wait for a vendor’s deployment schedule. If a new PFAS discharge limit takes effect and the corresponding calculation update has not been deployed to a customer’s instance, that compliance system may be operating against the wrong regulatory baseline. The issue may not become visible until a submission is flagged, an audit occurs, or a reporting deadline has already passed.
The Migration History Question
The most direct way to assess a vendor’s cloud architecture is to ask about its migration history.
Specifically: was the platform designed from the start as a cloud-native, multitenant application, or was it originally built for on-premises deployment and later moved to cloud hosting?
A vendor that migrates a legacy platform to cloud hosting often retains the architectural decisions made when the platform was originally designed for single-tenant installation. Session management, data isolation, update propagation, and scaling behavior are all shaped by that original design. These design choices are not easy to change.
Rebuilding a legacy platform for true multitenancy is effectively writing a new platform. That is why many vendors that began as on-premises or single-tenant systems have not fully completed the transition.
Locus Technologies built its platform as multitenant SaaS in 1999. That architecture has been continuously developed for more than two decades in a single cloud environment. The platform that a Fortune 10 energy company runs today is the same core platform and codebase that a mid-size manufacturer runs, with customer-specific configurations, permissions, workflows, and data separation layered on top.
That is not a marketing distinction. It is a verifiable architectural fact that can be confirmed through technical due diligence.
The Software Version Number Test
One of the simplest ways to test whether a vendor is truly operating a multitenant SaaS platform is to ask a basic question: What software version will we be running?
In a true multitenant SaaS platform, every customer runs on the same current version of the application. There may be customer-specific configurations, integrations, permissions, workflows, and enabled modules, but there should not be dozens of different software versions in production across the customer base.
If the vendor answers with a version number specific to your deployment, that is a signal worth examining. It may indicate that each customer has a separate instance, upgrade path, or maintenance schedule. In that model, the vendor is not continuously improving one shared platform. It is managing a portfolio of customer-specific deployments.
The operational implications are significant. Security patches, regulatory content updates, calculation logic, workflow improvements, and reporting enhancements may not reach every customer at the same time. Some customers may be current. Others may be several releases behind because upgrades require testing, scheduling, migration planning, or professional services involvement.
For EHS compliance, version fragmentation creates risk. If regulatory logic, inspection requirements, emission factors, permit conditions, or reporting templates are embedded in software functionality, then running an outdated version can mean operating from outdated compliance assumptions.
A modern SaaS vendor should be able to explain clearly how updates are deployed, how often they are released, whether all customers inherit them automatically, and whether any customers remain on older versions of the application.
EHS Workflow Tools and the Upgrade Problem
EHS workflow tools, including incident management, audit and inspection, permit tracking, compliance calendars, corrective actions, and task management, are among the capabilities most commonly highlighted in analyst reports such as the Verdantix Green Quadrant for EHS software and the Gartner Market Guide for EHS software.
These are also the capabilities most likely to be affected by version fragmentation in single-tenant or recently migrated platforms.
Consider the practical impact. A compliance calendar configured by an implementation team 18 months ago may not automatically reflect updated inspection frequency requirements issued in a regulatory revision last quarter. An audit checklist may continue to use outdated criteria. A permit tracking workflow may not reflect a newly required approval step. A corrective action workflow may miss a new escalation rule.
In a true multitenant platform, these updates can be deployed once and inherited across the customer base. In a single-tenant environment, each customer may need to wait for the next coordinated upgrade cycle. That cycle may depend on internal testing, vendor availability, implementation resources, or budget approval.
The result is a structural difference in compliance readiness. In a multitenant SaaS model, the platform evolves continuously. In a single-tenant or hosted legacy model, improvement often arrives in batches, after delay, and unevenly across customers.
Questions to Ask Before You Buy
- “Do all your customers run on the same codebase, the same deployment, and same version number always on the current version? If not, how many distinct versions of your platform are currently in production?”
- “When you release a compliance update (eg. a new regulatory calculation, an updated reporting form, a security patch) how does it reach my environment? Is it automatic and immediate, or does it require a migration process?”
- “Was your current platform designed from scratch as a multitenant SaaS, or was it migrated from an on-premises product? If migrated, what is the name and last release date of the original product?”
- “Do you support both single-tenant and multitenant deployments? If yes, which one would my organization be on?”
- “Can we see your SOC 2 Type 2 report — not just confirmation of certification, but the actual report — before contract signature? What is the audit period it covers?”
A Call to Action for Serious Buyers
Architecture is not a topic that surfaces naturally in vendor demos. Demos are designed to show what the software does, not how it is built. The complete EHS software buyers guide at locustec.com includes the full set of architecture evaluation questions to ask during technical due diligence. We’ve outlined the questions that distinguish a platform built for the cloud from one that was moved to it. To get a copy via email, send us a note at info@locustec.com.
Frequently Asked Questions
What is the difference between cloud-native and cloud-hosted EHS software?
Cloud-native software was designed from inception for multitenant, continuously deployed operation. Cloud-hosted software runs on cloud infrastructure but may have been originally designed for on-premises installation. The architectural difference affects update distribution, version management, performance under concurrent load, and long-term maintenance costs for both the vendor and the customer.
What is true multitenancy in EHS SaaS platforms?
True multitenancy means all customers share one software instance and one codebase. Updates, patches, and regulatory changes are deployed once and received by all customers simultaneously. There is no per-customer version management, no migration project required, and no possibility of version fragmentation. It is the architectural foundation of the original SaaS model and the standard against which all cloud EHS platforms should be measured.
Why does it matter whether an EHS platform like Locus Technologies, VelocityEHS, Cority, Intelex, or Sphera is cloud-native vs. cloud-hosted?
For highly regulated enterprises, regulatory compliance updates must reach the system quickly and reliably. If a vendor’s platform requires per-customer deployment for updates, there is an inherent lag between regulatory change and system currency. This is particularly relevant for PFAS-related calculation updates, DMR reporting format changes, and ESG disclosure requirement revisions, all of which have been changing frequently in recent years.
How does multitenancy affect the total cost of ownership for EHS software?
In a multitenant platform, upgrade costs, infrastructure costs, and version management costs are shared across all customers and absorbed by the vendor. In a single-tenant or hybrid model, a portion of these costs effectively falls on the customer in the form of IT resources, implementation fees for updates, and the staff time required to test and validate each deployment. Total cost of ownership comparisons that only consider license fees significantly understate this difference.
What should I look for in a SOC 2 Type 2 report when evaluating EHS SaaS providers?
SOC 2 Type 2 covers a sustained period (typically 6 to 12 months) during which an independent auditor verifies that the vendor’s security, availability, and processing integrity controls operate consistently as described. Request the full report, not just attestation of the certification. Review the audit period, the scope of controls covered, and any exceptions noted. Compare this to SOC 2 Type 1, which is a point-in-time assessment and significantly less rigorous.
Locus is the only self-funded water, air, soil, biological, energy, and waste EHS software company that is still owned and managed by its founder. The brightest minds in environmental science, embodied carbon, CO2 emissions, refrigerants, and PFAS hang their hats at Locus, and they’ve helped us to become a market leader in EHS software. Every client-facing employee at Locus has an advanced degree in science or professional EHS experience, and they incubate new ideas every day – such as how machine learning, AI, blockchain, and the Internet of Things will up the ante for EHS software, ESG, and sustainability.
