Cloud-Based CMMS: What Buyers Should Understand

Buyers usually arrive at this decision with a single question: is a cloud CMMS better? It is a reasonable question, and it is incomplete, because it treats deployment as a product feature rather than as a choice about who operates what.

Imagine two maintenance organizations. The first runs 100 geographically dispersed facilities with a small central IT team and technicians who work from phones and tablets all day. The second runs a single industrial site where maintenance has to keep going when external connectivity is unreliable, and where important plant systems stay local by design.

Both organizations can benefit from cloud technology. They do not have the same requirements. The first is mostly deciding how much technology operations work it wants to stop doing. The second is deciding which maintenance capabilities must survive when a connection drops.

So the useful question is not whether cloud is better. It is this: which technology responsibilities do we want to own, which are we comfortable transferring to a provider, and which dependencies can our maintenance operation tolerate?

Cloud is not simply a hosting decision. It changes the boundary between what you operate, what the provider operates, what you control, and what you have to trust.

This guide is written to help a maintenance buyer answer that question with their own operation in mind. It does not argue for cloud, and it does not argue against it.

“Cloud-based” does not describe one thing

NIST defines cloud computing through five essential characteristics — on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service — and then separates service models from deployment models. Service models describe how much of the stack the provider operates: Software as a Service, Platform as a Service, Infrastructure as a Service. Deployment models describe who the environment serves: private, community, public or hybrid.

Those two axes are independent, which is the part vendors often blur. A CMMS buyer may encounter any of the following, all described in sales conversations as “cloud”:

• Software as a Service, where the vendor operates the application and you use it through a browser or mobile client
• A vendor-hosted or managed deployment of software that was originally designed to be installed
• The vendor's application running on public cloud infrastructure, licensed and operated more like traditional software
• A private-cloud environment dedicated to one customer
• Traditional on-premises deployment on the customer's own servers
• Hybrid arrangements that combine a hosted application with local components

These labels are not used consistently across the CMMS market. Two vendors can describe the same architecture differently, and one vendor can use “cloud” for several different products.

Cloud-based does not automatically mean SaaS, and SaaS by itself tells you nothing about whether a CMMS is secure, reliable, inexpensive, portable, easy to integrate or right for your operation.

You need enough vocabulary here to ask precise questions, not enough to pass a cloud-architecture exam. The single most useful question at the start of a vendor conversation is: when you say cloud-based, which service model and which deployment model do you actually mean?

The transfer–dependency principle

This is a CMMSBuyersGuide framework rather than an industry standard. It exists to make the central trade of any cloud decision visible.

For every responsibility you transfer to a provider, ask two questions: what burden did we remove, and what dependency did we create?

Dependency is not a defect. Transferring infrastructure work to a provider that does it well, continuously, at scale is frequently the whole reason SaaS is worth buying. The point of the principle is not to discourage the trade. It is to make sure the trade is made deliberately, with both sides of it named.

Every responsibility you transfer becomes, to some degree, a dependency you acquire.

Cloud reduces technology operations without eliminating technology governance

A SaaS CMMS can genuinely remove work. The organization may stop operating application servers, database infrastructure, patching cycles, traditional upgrade projects and portions of backup infrastructure.

What generally does not go away is governance. Someone in the organization still has to make decisions about:

• Identity, authentication and who is allowed in
• Access levels and permissions as roles change
• Integrations with other systems and what happens when they break
• Vendor security posture and what evidence you require of it
• Configuration choices and who is allowed to change them
• The operational impact of vendor releases
• Data retention and portability requirements
• Continuity requirements and what the organization does during disruption
• Contractual commitments and what they actually oblige the provider to do
• Provider changes to the product, the pricing model or the integration surface

CISA's cloud guidance describes this as a shared responsibility model, in which the split between provider and customer shifts depending on the service model. In infrastructure services the customer retains most of the stack above the hypervisor; in software services the provider takes on far more, and the customer's remaining responsibilities concentrate around identity, data and configuration.

The important caveat is that the boundary is not identical across providers, even within SaaS. Two CMMS vendors can offer materially different splits on logging, configuration control, integration support and security responsibility.

Ask the vendor directly: what exactly becomes your responsibility, what remains ours, and what is shared?

So is cloud better?

It deserves a direct answer rather than a shrug. Cloud and SaaS tend to be particularly attractive when an organization:

• Has limited desire or capability to operate CMMS infrastructure
• Has geographically distributed sites that need one consistent system
• Needs convenient browser and mobile access for technicians who are rarely at a desk
• Wants standardized, vendor-managed releases instead of periodic upgrade projects
• Needs controlled access for dispersed employees or contractors
• Can support its required integrations through the vendor's architecture
• Has connectivity and continuity arrangements it considers acceptable

Cloud deserves more careful investigation when:

• Maintenance happens where connectivity is unreliable or intermittent
• Certain maintenance capabilities must remain available locally during disruption
• Unusual or local operational-technology integrations are important
• Highly specialized customization is genuinely required
• Infrastructure or data-control requirements are unusual for the sector
• Provider-controlled release timing would create real operational problems
• Portability requirements are demanding because of history volume or regulatory need
• Cloud, network or identity dependencies would create failure modes the operation cannot accept

In the second list the answer may still be cloud. It may be hybrid. It may be on-premises. What changes is how much of the evaluation goes into continuity, integration and exit rather than into features.

Requirements first. Architecture second.

If your requirements are not written down yet, that work comes before this decision. How to Build Your CMMS Requirements covers how to derive them from the operation instead of from a feature list.

Cloud changes control as well as workload

Underneath most cloud decisions is a recurring trade: burden removed against control surrendered.

• Vendor-managed releases remove upgrade work and may reduce your control over when the software changes
• Vendor-managed database operations remove administrative work and may reduce direct database access
• Provider-managed infrastructure removes server responsibility and limits infrastructure control
• Standard SaaS configuration can simplify upgrades and limit deep customization

Losing control is not automatically bad. Most maintenance organizations do not want to control database indexing or patch scheduling, and paying to retain that control is pure cost.

The question worth asking is narrower: which controls actually matter to this maintenance operation? A plant with a validated process may need release control. A facilities team with three integrations probably does not. Do not pay operational cost to keep control you will never use, and do not casually surrender control you genuinely need.

Dependency concentration

This section is CMMSBuyersGuide analysis built on the cloud literature rather than a finding from it.

On-premises software depends on local servers, database systems, internal IT capability, backup processes, network infrastructure and upgrade expertise. Those are dependencies too; they are simply distributed across things you operate.

SaaS removes or transfers many of them, and concentrates the remainder in the provider and the surrounding network and identity ecosystem. NIST's cloud guidance treats this explicitly, discussing network dependence and the harder case of a prolonged outage, alongside network dependence and limited portability between software services, as risks a customer should plan for rather than assume away.

The scenarios worth thinking through are not hypothetical for a system you expect to run for a decade:

• A prolonged outage during a period when maintenance work is heavy
• Discontinuation of the product or of a module you depend on
• Acquisition of the vendor and a change in product direction
• Discontinuation of an integration you built a workflow around
• A change in pricing model at renewal
• Provider financial distress

None of this is a reason to speculate about specific vendors. It is a reason to ask two concrete questions:

• What happens operationally if this service is unavailable for a day?
• What happens strategically if we no longer want, or can no longer use, this provider?

Availability is not one thing

Vendors quote uptime. Uptime answers one of four separate questions, and usually not the one that matters to a technician standing in front of a machine.

Service availability

Is the vendor's application operating? This is the number in the service level commitment.

Path availability

Can your location actually reach it? Depending on the implementation, the path may involve internet service, WAN links, DNS, an identity provider, firewall and network services, and VPN or another access architecture. Any one of them can be the thing that fails. Not every implementation has all of these dependencies.

Device availability

Can the technician's actual device reach what is needed? Battery, signal inside a steel structure, a device left in a truck and a broken screen are all availability problems that no service level commitment addresses.

Work availability

Can maintenance still do the necessary work? This is the only one of the four that the maintenance organization is ultimately accountable for.

Cloud uptime and maintenance continuity are not the same thing. A cloud service can be perfectly healthy while a technician at a plant cannot reach it.

Ask what must survive

“Does the mobile app work offline?” is too shallow a question to produce a requirement. The better question is: which maintenance capabilities must remain available when centralized systems or connectivity are unavailable?

Depending on the operation, candidates include:

• Emergency procedures and safety documentation
• Currently assigned work
• Asset identification and location
• Procedures and checklists
• Critical documents and drawings
• Inspections
• Meter readings
• Notes
• Photos
• Labor capture
• Parts usage
• Reporting a new problem

Not all of it needs to survive. A portfolio dashboard does not matter during a plant connectivity outage. Emergency maintenance instructions might matter a great deal. Sorting the list into what must survive and what can wait is the actual requirements work.

Define the minimum maintenance capability that must survive loss of connectivity, then evaluate products against that definition.

Offline is not a checkbox

Rather than asking whether the mobile CMMS works offline, ask what exactly works offline, and have the vendor demonstrate each item rather than confirm it.

• Which work orders are available offline, and how are they selected
• Whether asset details are available
• How much asset history is available, and how far back
• Procedures and checklists
• Attachments and documents
• Inspections
• Meter readings
• Notes
• Photos
• Barcode and QR functions
• Parts usage
• Labor capture
• Work completion
• Creation of new work

Then ask the harder half of the question: what happens after reconnection?

Work through a specific scenario with the vendor. Technician A takes a work order offline. While Technician A is disconnected, Planner B changes that same work order — reprioritizes it, reassigns it, edits the scope. Technician A then updates the offline copy and reconnects.

• What synchronizes, and in what order?
• What is treated as a conflict?
• Which value wins?
• Is anything silently lost?
• Is the conflict visible to anyone?
• Can someone later understand what happened from the record?

Offline capability is not a checkbox. It is a defined subset of the maintenance workflow plus a synchronization strategy.

There is no universally correct synchronization design. Last-write-wins is defensible for some fields and dangerous for others. What matters is that the design is explicit and that the organization understands what it does to the record.

The consequences of a silent overwrite are a data-trust problem more than a connectivity problem, which is the subject of Maintenance Tracking Software.

The physical world makes maintenance hybrid

Even when the CMMS is pure SaaS, maintenance itself is not centralized and never will be. The chain from equipment to completed work crosses several boundaries:

PHYSICAL EQUIPMENT → LOCAL SENSOR / TECHNICIAN / CONTROL SYSTEM → NETWORK / EDGE / GATEWAY → CLOUD APPLICATION → HUMAN DECISION → PHYSICAL MAINTENANCE WORK

The CMMS may be centralized in the cloud. Maintenance never is.

This is why connectivity, integration and local continuity keep appearing in a discussion that started as a hosting question, and it is the same boundary that matters when condition monitoring has to become controlled work — the subject of Predictive Maintenance Software.

This section is about the hybrid physical and digital reality of maintenance work. It is a different idea from NIST's hybrid deployment model, which describes a composition of distinct cloud infrastructures.

Cloud does not eliminate architecture

A manufacturing environment that adopts a SaaS CMMS may still be operating a cloud ERP, a cloud identity provider, local PLC and control systems, a local historian, an edge or IoT gateway, a predictive-maintenance platform and external supplier systems.

Cloud does not eliminate architecture. It moves the boundaries.

The buyer questions that follow are operational rather than technical:

• Which system is authoritative for each type of data?
• Which direction does information move, and does anything move both ways?
• Which integrations require real-time access, and which can tolerate delay?
• What happens when one system is unavailable?
• Are failed transactions retried, and how many times?
• Can duplicate records be created by a retry?
• Who monitors failed integrations, and how would we notice?
• Who owns integration maintenance over the system's life?
• What happens when an API changes or a version is deprecated?
• What happens when an asset identifier changes on one side?
• Can integration history and errors be investigated after the fact?

For an operation where plant systems stay local, this is often the decisive part of the evaluation. CMMS for Manufacturing goes further into how maintenance software meets production systems.

“Has an API” is not enough

Almost every modern CMMS has an API. That statement carries much less information than buyers assume. Investigate what the API actually permits:

• Read assets, and create or update them
• Read work orders, and create or update them
• Retrieve historical records rather than only current state
• Access custom fields
• Access meter data
• Retrieve attachments
• Bulk extract records rather than paging through them one at a time
• Receive event notifications or webhooks where your workflow needs them

Then ask about the conditions attached to it:

• Authentication approach and how credentials are managed
• Rate limits, and whether they are compatible with your volume
• Whether API access or a service tier carries an additional charge
• Versioning and how long versions are supported
• Deprecation and change policy, and how much notice you get
• Documentation quality
• Sandbox or test environment availability where you need it

API availability and integration freedom are not the same thing.

Not every buyer needs every capability on those lists. A single-site facilities team with no integrations can skip most of it. An organization planning three integrations should test them, not read about them.

Backup, recovery, availability and continuity are four different questions

These words get used interchangeably in sales conversations. They answer different questions, and a product can be strong on one and weak on another.

Two terms are worth knowing precisely, because they appear in service commitments and in cloud contract guidance. The recovery point objective describes how much recent data could be lost in a recovery scenario — effectively, how far back the restored state may sit. The recovery time objective describes how long recovery is intended or required to take.

There is no universally correct pair of numbers. An RPO of 24 hours is unremarkable for some facilities operations and unacceptable for others. What matters is knowing which numbers apply to you and whether the operation can absorb them.

“Backups included” is not enough

• What information is backed up?
• Are attachments, photos and documents included?
• Is configuration included, or only transactional data?
• How frequently are backups taken?
• How long are they retained?
• How are they protected?
• What recovery point objective applies?
• What recovery time objective applies?
• Who initiates a restoration — us or the provider?
• At what granularity can data be restored: whole tenant, module, record?
• Is recovery tested, and can you describe the last test?
• What happens if the primary environment or account is compromised?
• What continuity options exist for us while recovery is underway?

In SaaS the customer usually should not be operating backups directly, and asking to is often the wrong requirement. The requirement is understanding precisely what protection and recovery exist, and what the organization does during the gap.

Security: the wrong question is “is the cloud secure?”

Security in a cloud service is divided, and the division depends on the service model and on the individual provider. CISA's reference architecture describes how responsibility shifts as you move from infrastructure services toward software services: the provider takes on progressively more of the stack, and the customer's remaining responsibilities concentrate around identity, data, configuration and the people using the system.

A SaaS CMMS can transfer substantial infrastructure and application security responsibility to the provider. What typically remains with the customer includes users, permissions, identity, authentication, endpoints, configuration choices, integrations and organizational process.

The useful question is: secure against what, controlled by whom, and which part is still ours?

Areas worth evaluating, to the extent your requirements call for them:

• Single sign-on support and whether it costs extra
• Multi-factor authentication and how it is enforced
• Role and access controls, and how granular they are
• Account lifecycle and provisioning, including how leavers are removed
• Logging and auditability, and how long logs are kept
• Provider security documentation
• Incident response and notification obligations
• Encryption where it is relevant to your requirements
• Data location and residency where that matters to you
• Third-party assurance and certifications where they map to a requirement you actually have

A certification is evidence that a provider was assessed against a defined scope at a point in time. It is not proof that a product is secure, and it is not a compliance conclusion for your organization. Where compliance obligations are genuinely at stake, that determination belongs with the people in your organization responsible for it.

Multi-tenancy

Resource pooling — serving multiple customers from shared infrastructure with logical separation — is one of the essential characteristics of cloud computing rather than a shortcut taken by a particular vendor.

Single tenant is not inherently secure and multi-tenant is not inherently insecure. The label answers almost nothing on its own.

When a tenancy question comes up, find the requirement underneath it. Buyers usually ask about tenancy because they are concerned about isolation, customization scope, release control, performance, a regulatory requirement or data location. Each of those is answerable directly, and the architecture label is a poor proxy for any of them.

Updates: a real benefit with a real tradeoff

SaaS can remove traditional upgrade projects and end the situation where five sites run four versions. That is a genuine advantage and often one of the strongest practical arguments for the model.

It also moves release timing to the vendor. Understand what that means in practice:

• Release frequency
• How much notice you receive
• Whether release notes are useful and specific
• What testing you can do before a release reaches production
• Whether a sandbox or preview environment is available
• Whether releases change APIs you depend on
• How deprecated features are handled
• Training impact on technicians who use the system daily
• What the rollback or correction process is when a release causes a problem
• Whether new or optional functionality can be turned on by you rather than automatically

Most SaaS releases are uneventful. The point is not to treat vendor updates as a hazard, but to know where the remaining change-management work sits.

Ask: what does vendor-managed updating remove from us, and what change-management responsibility remains ours?

Cost: cloud changes the structure, not the existence, of cost

Cloud is not automatically cheaper. The cost structure changes, moving from capital and internal labor toward subscription and vendor services, and the comparison depends heavily on what the organization was already paying for.

Subscription and cloud-side costs can include:

• Subscription fees
• User, site or asset tiers
• Implementation
• Storage, particularly where attachments and photos accumulate
• API or integration access
• Premium support
• Single sign-on or security features, depending on the vendor
• Test or sandbox environments
• Professional services
• Data extraction
• Price increases at renewal
• Migration and exit costs

Customer-operated costs, whether on-premises or self-hosted, can include:

• Licenses
• Servers and infrastructure
• Database software
• IT labor
• Monitoring
• Patching
• Security work
• Backups
• Recovery capability
• Upgrades
• Hardware refresh
• Remote-access infrastructure

No vendor charges for every item on the first list, and no organization pays every item on the second. Build the comparison from your own situation.

Ask: which responsibilities and risks are included in the price, which remain ours, and how does that change over the expected life of the system?

Portability: go much deeper than “can we export?”

NIST's cloud standards work treats portability and interoperability as first-order concerns, describing data portability as the ability to move data between systems at acceptable cost, and stating that cloud platforms should allow data to move into and out of providers. NIST's synopsis makes the same point from the buyer's side, treating import and export capability as something a customer should evaluate rather than assume.

That literature is about cloud computing generally. The four levels below are our application of those principles to maintenance information, and they are CMMSBuyersGuide synthesis rather than a standard.

Level 1 — File portability

Can we retrieve the records and files at all? This is the level most vendors mean when they say data is exportable.

Level 2 — Structural portability

Do the relationships survive the export? In a maintenance record the relationships carry much of the meaning:

• Work order to asset
• Component to parent asset
• Inspection to work order
• Photo to inspection
• Part to work order
• Meter to asset
• Follow-up work to the originating work

Level 3 — Semantic portability

Can another person or system understand what the information means? If a row says failure_code = 17, where is the definition of 17? If status = 5, what did status 5 mean in this organization, in that year?

Semantic portability requires that code dictionaries, units, field definitions, custom-field definitions, statuses, timestamp meanings and relationship definitions come with the data and are documented.

Level 4 — Operational portability

Could another system realistically resume maintenance operations from what was exported? This usually requires more than a folder of CSV files, and it is the level almost nobody tests before signing.

Owning your data and being able to leave with a usable maintenance record are different things.

Ownership, access, portability and deletion are four different rights

UNCITRAL's notes on cloud computing contracts discuss these as contractual matters, covering export procedures, export assistance, the time period during which data can be retrieved, possible charges for export, and deletion of data after termination.

Whether those provisions appear in your agreement, and in what form, is a procurement and legal question rather than a technical one. This guide does not give legal advice, and contract language should involve the appropriate legal, procurement and security stakeholders in your organization. What the maintenance side can contribute is a clear statement of which technical outcomes actually matter.

Data ownership without usable extraction can still leave an organization operationally locked in.

The exit problem

Software selection concentrates almost entirely on entry: migration, configuration, integration, training, go-live. Exit gets a sentence in the contract and no testing at all.

Ask the question the other way around. If we leave this system after eight years, what exactly comes with us?

• Assets and the asset hierarchy
• Locations
• Work orders
• PM history
• Meter history
• Inspections
• Failure information
• Labor records
• Parts usage
• Costs
• Warranties
• Documents
• Photos and attachments
• Custom fields
• Status and code definitions
• Change and audit history where you require it

Not every organization needs every element. A facilities team may care most about assets, work history and documents. A regulated manufacturer may need the change history too.

Then ask the follow-up questions:

• In what format?
• How are relationships preserved in that format?
• How long after termination do we have to retrieve it?
• What charges apply?
• Is assistance included, and what does it cover?
• What happens to provider-held copies afterwards?

Test exit before you enter

This is the single most useful practical recommendation in this guide, and almost no buyer does it.

During evaluation, ask the vendor to export a representative slice of maintenance history. One asset is enough, provided it is a real one:

• Its hierarchy and location
• Several years of work history
• PM records
• Meter readings
• Parts
• Labor
• Inspections
• Attachments and photos
• Custom fields

Then inspect what you get:

• What files are actually provided
• Whether the relationships between records survive
• Whether attachments are included or only referenced
• Whether codes and fields can be interpreted without the original system
• Whether the export format is documented
• Whether another system could reasonably reconstruct the history from it

Do not wait until year eight to discover what “your data is exportable” actually means.

This is not a formal migration test and it does not need a project plan. It is a portability test, and it usually takes a vendor a few days to produce.

Switching cost tends to grow with success

This is CMMSBuyersGuide analysis rather than a research finding.

A CMMS becomes more valuable as it accumulates history, procedures, asset structures, inspections, documents, workflows, integrations and organizational knowledge. That accumulation is the whole point — it is what turns a work-order tool into an operational record, as Equipment Maintenance Software describes for individual assets.

The same accumulation makes migration harder. Which produces an uncomfortable symmetry: the more successfully a maintenance organization uses a CMMS, the more valuable portability becomes, and the more expensive it is to exercise.

SaaS does not uniquely cause lock-in. On-premises systems create substantial switching costs too, sometimes worse ones, because the data sits in a schema nobody documented. What cloud changes is that the provider controls the boundary at which you can reach your own record, which is why the extraction question deserves attention up front.

In SaaS, the contract becomes part of the operating model

Some capabilities the maintenance organization depends on are governed partly by agreement rather than by software behavior alone. UNCITRAL's contract notes discuss the categories where this typically applies:

• Service levels
• Data return
• Export assistance
• Post-termination access period
• Deletion
• Support scope and response
• Storage limits
• API entitlements
• Security commitments
• Notification obligations
• Transition assistance

In SaaS, some of the technical capability you depend on may be guaranteed — or limited — by the contract rather than the interface.

Again, this is not legal advice. The practical action for a maintenance buyer is to turn the technical requirements that matter into written procurement questions, and to give the people negotiating the agreement a clear list of what the operation actually needs.

The reversibility test

A second CMMSBuyersGuide concept, and a short one. For each decision inside the architecture, ask: if this choice stops working for us, how difficult is it to change course?

The harder a decision is to reverse, the more seriously it should be tested before purchase.

This is not an argument against cloud. It is an argument for proportional due diligence: spend evaluation effort where reversal is expensive, and stop agonizing over the parts you can change next quarter.

Four operations, four different evaluations

A — Multi-site manufacturer with a small IT team

Three or more facilities, distributed maintenance, mobile and browser access that matters daily, and little appetite for administering application infrastructure. SaaS is likely to be attractive here, and the burden it removes is real.

The evaluation should still concentrate on connectivity at each site, the integrations to production systems, identity and access across sites, portability and exit.

B — Industrial site with unreliable external connectivity

Important maintenance activity has to continue when the external link is down. Cloud can still work here, and frequently does. What changes is that offline scope, synchronization behavior and continuity architecture stop being features and become primary requirements.

C — Large distributed facility portfolio

Many locations, many technicians, and contractors moving in and out. Centralized administration and consistent deployment are worth a great deal. Identity and access management and the quality of the mobile experience become the dominant evaluation criteria.

The work patterns behind this scenario are covered in Facility Maintenance Software.

D — Organization with complex legacy and OT integrations

Older ERP and plant systems, specialized interfaces, significant historical logic embedded in the current system. Cloud can reduce infrastructure burden here while making integration and migration architecture the hardest part of the project. The deployment decision should follow the integration analysis, not precede it.

None of these scenarios has a predetermined winner. They show how the same set of questions produces different answers when the operation changes.

The CMMSBuyersGuide cloud decision map

This is our framework, not an industry standard. It runs from the operation toward the architecture, deliberately, because doing it in the other order is how organizations end up with a deployment model that fights their maintenance work.

OPERATION → CONTINUITY → RESPONSIBILITY → CONTROL → DEPENDENCY → SECURITY → INTEGRATION → ECONOMICS → PORTABILITY → REVERSIBILITY → ARCHITECTURE

Requirements first. Architecture second.

Buyer questions

• When you say “cloud-based,” which service model and deployment model do you actually mean?
• Which technical responsibilities belong to you, which remain ours, and which are shared?
• What control do we give up in exchange for what you take on?
• What happens if your service is unavailable?
• What happens if our site loses internet access?
• Which maintenance capabilities work offline?
• How does offline synchronization and conflict handling work?
• What are your availability commitments, and what do they exclude?
• What backup and recovery arrangements apply?
• What recovery point and recovery time objectives apply where they are relevant to us?
• How do identity, single sign-on and multi-factor authentication work?
• What integrations and APIs are available?
• Are APIs, storage or security features subject to separate tiers or fees?
• How are releases managed, and what notice, control and testing options exist?
• Where is our data stored, where location matters to our requirements?
• Can we export our complete maintenance record while we are a customer?
• What exactly is included in an export?
• Are attachments and relationships preserved in it?
• What happens when the contract ends?
• How long can we retrieve data afterwards?
• Is export assistance available, and what does it cost?
• What happens to provider-held copies after termination?
• How difficult would it realistically be to move to another CMMS?

The vendor demo and due-diligence test

“Show us your cloud CMMS” produces a polished demonstration of the happy path. Use three tests instead, each of which removes something.

Test 1 — Remove the internet

Have the vendor demonstrate a realistic technician workflow on a device. Then say: now assume the technician loses connectivity. Show us exactly what still works.

• Which records remain available
• Which records become unavailable
• What data entry is still possible
• Whether attachments can be opened and captured
• Whether inspections can be completed
• Whether work can be completed
• How synchronization behaves on reconnection

Then create the conflicting edit described earlier — an online change to a record a technician holds offline — and ask them to demonstrate what happens after reconnection, if the product supports that scenario at all.

Test 2 — Remove the service

Ask: assume the cloud service itself is unavailable. What can our maintenance organization still do, what information is accessible, and what is the recovery and continuity process?

Keep this distinct from the first test. A provider outage and a local connectivity loss look similar to a technician and are entirely different problems for the organization.

Test 3 — Remove the vendor

Ask: assume we decide to leave your system after several years. Show us how we retrieve a representative maintenance record. Use an asset with hierarchy, work history, PM history, meter history, an inspection, parts and labor, attachments and custom fields.

Have them show the actual export and explain the format, how relationships are represented, where the field and code definitions live, how attachments are delivered, the timing, the charges and what assistance is included.

If a vendor can show you what happens when the internet disappears, when the service disappears, and when the vendor relationship disappears, you have learned far more than a checkbox labeled “Cloud: Yes.”

Where these capabilities live

“Cloud-based CMMS” is a description of an operating model rather than a product category. The same capabilities appear in systems sold as CMMS, EAM, facility management, asset management or field service software, and the boundaries between those labels are inconsistent. If you are still placing the category itself, What Is a CMMS? and Do You Actually Need a CMMS? come first.

Organizations moving off spreadsheets often meet this decision at the same moment they meet the software decision; CMMS vs. Spreadsheets covers that transition. How work itself should move through the system is covered in Maintenance Work Order Software, and how competing demand becomes a credible schedule in Maintenance Scheduling Software.

The decision underneath the question

A buyer who finishes this guide should have stopped asking whether cloud is good. The questions that replace it are more specific and more answerable:

• What responsibilities do we want the vendor to assume?
• What dependencies does that create?
• Which maintenance capabilities must survive when systems fail?
• How will our physical and local systems connect?
• What does the complete operating model cost?
• Can our maintenance knowledge leave with us?
• How difficult will this decision be to reverse?

The important question is not whether a CMMS is in the cloud. It is what the architecture allows your maintenance organization to stop owning, what it requires you to start depending on, what happens when those dependencies fail, and whether you can change course later.

Choose the operating requirements first. Let those requirements choose the architecture.