Cloud-Based Facilities and Maintenance Management

A decade ago a facilities manager evaluating maintenance software had a genuine deployment decision to make. Today that decision has largely been made for you. The modern CMMS and CAFM market is overwhelmingly subscription software delivered from a vendor's cloud, and the few on-premise options left are either legacy estates being maintained rather than sold, or the enterprise asset management tier where a large operator with its own data centre still has leverage. For most FM and maintenance teams the practical question has moved on: given that the product will be cloud, what actually changes in how your department works, and which contract and capability details decide whether the thing succeeds in the field or quietly dies in the plant room.

The message up front: cloud has solved the infrastructure problem and changed almost nothing about the two things that actually determine whether a maintenance system works. Those two things are whether a technician can complete a job in a basement with no signal, and whether the licensing model lets you give access to everyone who needs it. Get those wrong and the best-architected SaaS product in the category will still fail on your sites.

1. Cloud became the default, and what that means for a buyer now

If you shortlist maintenance software in 2026, you will find that the products designed in the last ten years are cloud-native and subscription-only, and that the older enterprise platforms have all been repositioned as cloud offerings whether or not their underlying design started that way. MaintainX, Limble, Fiix and UpKeep were built as SaaS from day one. eMaint has been hosted for years. IBM Maximo, Hexagon EAM, Infor EAM and Planon all have managed cloud paths, and the vendor commercial motion pushes you toward them. SAP Plant Maintenance sits inside whatever ERP deployment the wider organisation has chosen, which usually means the decision is not yours to make.

The consequence for a buyer is a shift in where your scrutiny belongs. Comparing hosting models is now a much smaller part of the evaluation than it used to be, and I would not spend much of a selection process on it. If you do need that comparison, because you are weighing a genuine on-premise option or you have a regulator who cares, the deployment-model analysis lives in the cloud CMMS versus on-premise article rather than here. What follows assumes the answer is cloud and looks at the operational consequences.

There is one genuinely new buyer skill that cloud created. When the software ran in your server room, you decided when it changed. Now the vendor decides, and you inherit a release cadence. That is not automatically bad, and for most FM teams it is a net gain, but it means the questions you ask in a demo need to include how releases are communicated, whether you get a sandbox to test them in, and what happens when a release changes a screen your technicians were trained on.

2. What changes operationally on day one

Strip out the infrastructure story and cloud delivery changes four concrete things in a maintenance department, all of them on the operational side rather than the technical side.

• Mobile is available immediately, not as a project. Every cloud CMMS ships with a mobile app or a responsive mobile web client on the same subscription. There is no separate mobile server, no reverse proxy to publish, no VPN client on a technician's phone. This single change is the largest operational benefit of the category, because it is the thing that moves work order completion from a desk at the end of the shift to the asset itself.
• External parties can be given access without network engineering. Contractors, subcontracted specialists, tenants and requesters reach the system over the public internet with a login. In an on-premise world each of those groups needed a published endpoint or a VPN account, which is why most on-premise CMMS deployments never gave contractors access at all and ran the whole contractor relationship on email.
• Multi-site reporting stops being a consolidation exercise. One tenant holds every site, so a portfolio view is a filter rather than a data warehouse project. This matters most to managing agents and service providers running many client sites. The organisational and security design that makes multi-site work is a separate discipline, covered in multi-site CAFM architecture.
• Releases arrive whether you asked for them or not. Features you did not request appear, occasionally a workflow you depended on changes shape, and the upgrade project you used to run every three years becomes a continuous low-grade change-management obligation instead.

Notice what is not on that list. Cloud does not improve your asset register, does not write your PM schedules, does not clean up your failure coding and does not make your technicians record better data. Those remain exactly as much work as they ever were, and they are still the things that determine whether the system produces useful information a year later.

3. What cloud changes and what it does not

I use a version of this table in selection workshops, because the most common misconception in the room is that moving to cloud software will fix problems that are actually data and process problems.

4. The connectivity problem, which is the real one

This is the section I would ask you to read twice. In every other software category, cloud delivery quietly assumes a connected user. In facilities and maintenance that assumption is wrong more often than it is right, because the physical places maintenance work happens are precisely the places with no signal.

Think about where your technicians actually stand when they complete a job. A basement plant room behind a concrete slab and a steel door. A chiller plant on a roof with a weak, intermittent cell signal. A lift shaft or a machine room. A pump house on a remote site with no fixed connectivity at all. A substation. A tunnel. An offshore platform or a rural water asset with satellite backhaul at best. Those environments are not edge cases in facilities management, they are the normal working conditions for a large share of the planned maintenance workload.

A cloud CMMS whose mobile client requires a live connection to load a work order, read an asset record, or save a completion is simply unusable in those locations. What happens next is completely predictable. The technician carries a printed job sheet again, writes the readings on it, and keys everything in at the end of the shift or hands it to a coordinator. You now have a cloud system with the same data latency and the same transcription errors as the paper process it replaced, plus a subscription cost.

There are degrees of offline capability, and the difference between them matters more than any feature comparison you will do:

• No offline. The app is a thin client over the API. Fine for an office-based coordinator, not viable for field maintenance.
• Queue-only offline. You can create a record offline and it uploads later, but you cannot read the asset register, PM procedures or history while disconnected. Better than nothing, but a technician who cannot see the asset's last three failures is working blind.
• Cached-scope offline. The app downloads the technician's assigned work, the relevant assets, procedures, parts list and attachments before they go in, then operates fully offline and reconciles on reconnect. This is what you actually need.
• Cached-scope offline with conflict handling. The same, plus defined behaviour when two people changed the same record, and visible sync status so a technician knows whether their work has landed. This is the mature version and it is worth paying attention to, because silent sync failure is worse than an obvious one.

Offline sync is genuinely hard engineering, which is why the quality varies so much across products that all claim it on their feature list. Ask how much data is cached, whether attachments come down or only metadata, what the storage footprint is on the device, how long a cache stays valid, and what the app does when a sync fails halfway. For the wider question of what makes a field app usable at all, see mobile CMMS and field-ready maintenance apps.

5. Who gets access, and the per-user licensing trap

The second thing that quietly decides the fate of a cloud maintenance system is its licensing model, because the licensing model decides how much of your organisation is ever allowed to touch it.

Most cloud CMMS and CAFM products price per named user per month, sometimes split into tiers such as a full user, a technician or limited user, and a requester. Some offer unlimited requesters. A few price by asset count, by site, or by a platform fee with user bands. Without quoting numbers, the structural problem is the same in every case: if the people who generate and receive work are charged for individually, someone in finance will eventually cap how many of them there are.

Here is how that plays out in a facilities operation. You have a core FM team who obviously need licences. You also have, in a typical mid-sized estate, a long list of people at the edge of the process: helpdesk staff, duty engineers, night shift, subcontracted lift and fire specialists, an HVAC contractor, a cleaning provider, building managers, tenant representatives, and every ordinary employee who might report a fault. Licence all of them and the subscription becomes a line item that attracts attention at renewal. Licence only the core team and everyone else interacts through the core team, which means email and phone calls, which means the system stops being the record of what happened and becomes a place where the FM team retypes what other people told them.

Practical things to negotiate rather than accept. Ask for unlimited or free requester access, since a requester who cannot log a fault is the main cause of work arriving by email. Ask whether contractor users are licensed per firm, per named individual, or through a portal that is priced separately. Ask whether concurrent licensing is available for shift-based technicians who share devices, because a three-shift operation licensed per named user pays roughly three times for the same seat. Ask what happens to your data and your read access if you reduce licence count at renewal. And read the agreement properly rather than the price sheet, using the approach in reading an enterprise software licensing agreement.

6. Integrating a cloud system with equipment on an internal network

Facilities and maintenance software rarely lives alone. It needs alarms from the building management system, occupancy or incident data from access control and CCTV, purchase orders and cost postings to and from the ERP, employee records from HR, and sometimes meter data from an energy platform. The awkward part is that most of those systems sit on an internal or operational-technology network that cannot reach the internet and must not be reachable from it.

Three patterns work, and I would choose between them on the basis of how urgent the data is rather than on elegance.

• An on-premise integration gateway or agent. A small service inside your network holds the credentials for the BMS or access control system, subscribes to the events you care about, and pushes outbound to the cloud API. All connections are outbound, so no inbound firewall rule is needed. This is the cleanest pattern for near-real-time alarm to work order flows, and most serious vendors either offer an agent or support one.
• Middleware or an integration platform in the middle. A broker sits between the OT side and the SaaS side, handling protocol translation, mapping, retries, throttling and audit. This is the right answer when you have more than two or three integrations, when the mapping logic is non-trivial, or when you need to shield the cloud product from a chatty BMS that would otherwise generate thousands of duplicate work orders a week.
• Scheduled file export and import. Unglamorous, robust, and entirely appropriate for anything that does not need to be immediate: nightly cost postings, weekly asset synchronisation, monthly meter reads. If a batch file at 02:00 satisfies the business requirement, do not build a real-time interface to look modern.

Two cautions from experience. First, alarm volume is the thing that breaks BMS-to-CMMS integrations, not connectivity. Without filtering, deduplication and a defined set of alarms that genuinely warrant a work order, you will bury your planners. The reference patterns for doing this properly are in the BMS to CAFM integration reference architecture. Second, involve your IT and OT security colleagues early and give them the outbound-only design before they ask for it. A gateway proposed by the FM team with a security rationale attached is approved far more easily than a firewall exception requested late in a project.

On the security framing itself, the useful vocabulary for these conversations comes from the cloud and OT security guidance published by bodies such as NIST , and in the UAE the national regulator TDRA is the reference point for telecommunications and digital infrastructure policy.

7. Data residency, and who owns the asset register

Two questions in this area produce more contract friction in facilities than anything else, and both are worth settling before signature.

Where the data physically sits. For government, defence, healthcare, utilities and critical national infrastructure work, and for many public sector clients in the Gulf, in-country hosting is a hard requirement rather than a preference. Ask the vendor which region your tenant will run in, whether that is guaranteed contractually or merely current practice, where backups and disaster recovery copies are held, and where support staff who can view your data are located. A product hosted in the region but supported from a team with unrestricted production access elsewhere may not satisfy a strict reading of your obligation. Certification frameworks published through ISO are the usual shorthand here, but ask for the actual certificate and its scope rather than accepting a logo on a slide.

Who owns the data when a service provider hosts it. This is the one that catches facilities management companies and their clients, and it is specific to this industry. A managed service provider often holds the CMMS subscription and runs the client's building on it. The asset register, the equipment history, the PM procedures, the failure records and the photographs are all built up during the contract term. Then the contract goes out to tender and the client discovers the operational history of their own building lives in a tenant belonging to the outgoing provider, on a product the client never licensed.

The way to prevent that is boring and effective. Write into the FM contract that asset and maintenance data is the client's property, that a full structured export in an agreed format will be provided at agreed intervals during the term and at exit, and that photographs, attached documents and closed work order history are included in that definition rather than treated as the provider's working papers. Whichever side of that contract you are on, raise it at the start. Raised at handover, it becomes a negotiation you will lose.

8. Faster to stand up, exactly as hard to populate

Cloud genuinely compresses one part of the implementation. There is no procurement cycle for servers, no database licensing, no build and hardening, no environment request queue. A vendor can hand you a working tenant in a day, and a pilot site can be live in weeks rather than quarters. That is a real advantage and it is the thing cloud vendors are right to advertise.

What has not changed at all is the part that consumes most of the project. You still have to decide the asset hierarchy and location structure. You still have to extract asset data from spreadsheets, handover documents, a legacy system and somebody's memory, and reconcile the duplicates. You still have to write PM schedules and job procedures, build the failure coding structure, define the priority and SLA matrix, set up cost centres, and train people. None of that gets easier because the database is in someone else's data centre.

The risk that fast provisioning creates is a project that skips the design work because it can. A tenant that goes live in three weeks with an imported asset spreadsheet and no hierarchy discipline will produce unusable reporting within a year, and by then the bad structure is embedded in thousands of work orders. If you are moving from an existing system, treat the data work as its own workstream with its own plan, as set out in the CAFM data migration strategy. If you are starting from nothing, the foundations to get right first are covered in the CMMS buyer's introduction.

A phasing pattern that works well with cloud provisioning: configure and populate one representative site properly, run it for a full quarterly PM cycle, fix what the cycle exposes, and only then roll the proven configuration across the estate. Cloud makes that pilot cheap to stand up, which is the best use of the speed advantage. Using the speed to go live everywhere at once is the worst.

9. Configuration versus customisation in a SaaS product

In an on-premise world, heavy customisation was painful but survivable. You owned the code, you controlled the upgrade, and if you chose never to upgrade, that was your decision to make. In SaaS the vendor upgrades everyone on a schedule, and that changes the economics of customisation completely.

Configuration means the things the product is designed to let you change: fields, forms, lists, workflow states, approval rules, roles and permissions, report layouts, notification templates, mobile screen layouts. These survive upgrades because the vendor tests them as supported surfaces. Customisation means anything beyond that: scripted behaviour, bespoke modules, altered core logic, deep integrations that depend on internal structures. Those are the things that break when the vendor ships, and in SaaS you do not get to decide when the vendor ships.

The discipline I would apply is a simple order of preference. First, change the process to match the product, if the product's way is defensible. Second, configure within supported surfaces. Third, if you truly need bespoke behaviour, build it outside the product against a published API, so that it is your code in your environment and the vendor's release cannot silently break it. Only as a last resort, and with a named owner and a regression test plan, accept in-product customisation. The same reasoning applies at the enterprise tier, where platforms such as IBM Maximo and Hexagon EAM draw the configuration boundary in their own way, and the principle transfers unchanged to any SaaS CMMS.

10. The contract terms to insist on

With cloud, the contract is the system. You have no server to inspect, no database you can back up yourself, and no ability to freeze a version. Everything you rely on has to be written down. This is the due-diligence table I would work through before signature.

Of those, the two I would refuse to sign without are unrestricted self-service data export and a workable exit clause. Every other weakness can be managed. Being unable to get your own asset history out of a product you have outgrown cannot.

11. A short evaluation sequence that keeps you out of trouble

Compressing the above into something you can run, in order, because the order matters more than the length:

• Count the real user population including contractors, tenants and requesters, and price that population with every vendor before you look at features.
• Test offline mobile in flight mode, on your phone, on a full job cycle, in the demo. Treat a refusal to demonstrate this as an answer.
• Take the shortlist to your worst site, the basement, the remote pump house, the roof plant, and try it there rather than in a meeting room.
• List your integrations and name the pattern for each, gateway, middleware or scheduled export, and confirm your IT and OT teams accept the design.
• Separate configuration from customisation in your requirements list, and check every customisation item against what the product supports natively.
• Settle residency and data ownership in writing, particularly if a service provider will hold the subscription on a client's behalf.
• Work the contract table above before signature, not at the first renewal.
• Plan the data work as its own workstream with its own owner, and pilot one site through a full quarterly cycle before rolling out.

If you are specifically evaluating for a facilities operation rather than a plant maintenance one, the functional requirements differ in ways worth knowing, and those are set out in CMMS for facilities management.

The idea to walk away with

Cloud is not the decision any more, it is the delivery model. What remains genuinely decidable, and what you will live with for years, sits in four places: whether the mobile client works where the work happens, whether the licensing model lets the whole participating population in, how the product reaches the systems on your internal network, and what the contract says about your data when the relationship ends.

Everything else in a cloud evaluation, the feature grids, the dashboard screenshots, the AI module on the last slide, is secondary to those four. I have watched capable products fail on the first two and unremarkable products succeed because they got them right.

Final thoughts

The most useful shift in mindset for an FM or maintenance manager buying cloud software is this: you are not buying an installation, you are entering a long relationship on terms someone else drafted. The infrastructure worry is gone, and that is a genuine improvement. In its place you have a dependency on a vendor's release schedule, a licence model that shapes who in your organisation participates, and an exit that only exists if you negotiated it.

So spend your evaluation effort where the operational risk actually lives. Put the app in flight mode. Count the contractors. Name the integration pattern. Read the exit clause. Then get on with the unglamorous work that determines whether any of it produces useful information: a clean asset hierarchy, honest failure coding, and PM schedules people actually complete. That part was never a cloud question, and it is still the part that decides whether the system earns its subscription.

Related reading: Cloud CMMS vs on-premise, Mobile CMMS: field-ready maintenance apps, CMMS for facilities management, What is a CMMS: a buyer's introduction, Multi-site CAFM architecture, BMS to CAFM integration reference architecture, CAFM data migration strategy, Reading an enterprise software licensing agreement.