Hybrid Cloud for Enterprise Asset Management

Ask an infrastructure lead at an asset-intensive organisation whether they run a hybrid cloud and you tend to get one of two answers. Either a slightly defensive "well, we are mid-migration", or a confident "yes" that turns out to mean the EAM is SaaS and everything else is still in the comms room. Both answers describe the same situation: workloads split across cloud and on-premise infrastructure, integrated to some degree, with the split determined more by history than by design. That is hybrid. It is the normal state for organisations that own plant, and it is almost never the result of an architecture decision anyone wrote down.

The message up front: the useful question is not "should we go hybrid". You very likely already are, and for some workloads you will stay that way permanently and correctly. The useful question is whether your hybrid is deliberate: can someone in your organisation say, for each significant workload, which side it sits on and why. Where nobody can answer that, you are not running a hybrid architecture, you are maintaining the residue of a migration that stopped.

1. What hybrid cloud actually means

Hybrid cloud means workloads deliberately split across public cloud and on-premise or private infrastructure, with integration between the two sides so they function as one estate. The two defining elements are the split and the integration. Infrastructure in two places with nothing passing between them is not a hybrid architecture, it is two architectures that happen to share a budget line.

Two distinctions are worth making immediately, because readers and vendors blur them constantly.

Hybrid is not multi-cloud. Multi-cloud means using more than one public cloud provider, for example an analytics workload with one provider and a line-of-business application with another. That is a provider-diversity question and it brings its own problems, but it is a different architecture with different failure modes. You can be hybrid and single-cloud. You can be multi-cloud with nothing on-premise at all. The two words are not interchangeable, and treating them as one is how an organisation ends up solving the wrong problem. This article does not compare providers, and if you are at the provider-selection stage that is a separate decision taken on its own merits.

Hybrid is not "we have some SaaS". Subscribing to a cloud application does not make an estate hybrid in any architecturally meaningful sense. Nearly every organisation consumes SaaS somewhere. Hybrid starts when you own the placement decision: when a workload could technically run on either side, and something, latency, regulation, integration density, or simple inertia, keeps it where it is. If you have never had to make that choice for a workload, you have a cloud subscription, not a hybrid architecture.

If you are still at the stage of choosing a deployment model at all, the four-model comparison and the straight cloud-versus-on-premise decision are covered separately in the cloud CMMS versus on-premise comparison. This article assumes that decision has either been made or, more commonly, has been made partially and then left.

2. Why asset-intensive organisations end up hybrid specifically

Plenty of industries drift into hybrid estates. Asset-intensive organisations, the utilities, the process plants, the airports, the large campuses and the multi-site facilities portfolios, get there for reasons that are structural rather than transitional. Understanding which of these applies to you is the difference between accepting a permanent hybrid and endlessly budgeting to escape one.

Operational technology and IT are separate for good reasons. Control systems, SCADA, building management systems and programmable logic controllers live on plant networks. They are often air-gapped, and where they are not air-gapped they are tightly segmented behind layers that exist precisely to stop general-purpose IT traffic reaching them. Those systems are not moving to anyone's cloud, and in most cases they should not. Meanwhile the maintenance system that consumes their data, the EAM or CMMS that turns an alarm into a work order, may perfectly reasonably be a cloud application. So the boundary runs straight through the middle of a workflow that a maintenance planner experiences as one thing. That split is structural. It is not a transition state waiting to resolve itself, and an architecture that treats it as temporary will keep producing plans that never execute.

Latency and site resilience. A site has to keep operating when the link to head office drops, and links drop. A technician standing at a panel needs to look up asset data, confirm an isolation, and record what they did, and none of that can be contingent on a wide area network that is outside the site's control. Work order execution at the point of work, permit systems, and asset data lookup are the usual candidates for something local, whether that is a local instance, a cached replica or an offline-capable client. The requirement is not latency in the millisecond sense for most maintenance work. It is availability during a link failure, which is a different and often more demanding constraint.

Data residency and data sovereignty, which are not the same thing. Residency is about where data physically sits. Sovereignty is about whose law and whose jurisdiction can reach it, which can bite even when the bytes never leave the country, because the provider operating the region may be subject to another jurisdiction's legal process. Some constraints are statutory, some are contractual, imposed by a client or a regulator-adjacent body rather than by legislation, and the two are negotiated very differently. Establish which kind you are dealing with before you design around it, because a contractual constraint can sometimes be renegotiated and a statutory one cannot. Jurisdictions differ substantially here, so take advice specific to yours rather than assuming another country's position applies.

Legacy systems that cannot move. Either the vendor offers no cloud version, or there is a cloud version and the customisation you depend on makes the upgrade uneconomic. The second case is the more common and the more frustrating, because the blocker is not technical impossibility, it is a cost that has never cleared the business case. For what moving these actually involves when it does clear, see the guide to migrating CMMS and EAM to the cloud.

Acquisition. Buying a company buys its infrastructure, its contracts and its deployment choices. A portfolio that grows by acquisition inherits a hybrid estate it never designed, often several times over, and the integration debt arrives on day one while the rationalisation programme arrives, if at all, several years later.

3. The workload placement question

The practical core of hybrid architecture is deciding, workload by workload, which side something belongs on and being able to say why. These are the factors I would weigh, and the ways I commonly see each one misapplied.

Two notes on reading that table. First, no single row decides a placement. A workload with a genuine regulatory constraint is settled by that row alone, but most workloads are a balance and the honest output is a judgement with a stated rationale, not a score. Second, where the workload in question is analytics on condition data specifically, the edge-versus-cloud trade-off has its own shape and its own answer, which is worked through in the edge versus cloud analysis for predictive maintenance. Defer to that rather than re-deriving it here.

The same placement logic applies outside maintenance systems. Warehouse management is the clearest parallel, because the latency and site-resilience arguments are even sharper where a scanner in an aisle cannot wait for a round trip, and that case is covered in the cloud WMS versus on-premise comparison.

4. The integration burden is the real cost of hybrid

Here is the trade stated plainly: every split you create produces an interface, and interfaces are where the operating pain of a hybrid estate lives. A hybrid architecture has more moving parts than either pure model. Not more than the sum of a cloud estate and an on-premise estate considered separately, more than either one, plus everything in between them. That in-between is the part nobody budgets for.

What the boundary actually costs you:

• Network connectivity and its reliability. A dedicated link, a tunnel, or both, with the bandwidth, the failover and the monitoring that implies. The connectivity itself is the easy part. Proving it works in a degraded state, not just an outage, is the hard part, and it is the state that actually occurs.
• Identity across both sides. Covered in its own section below, because it deserves one.
• Data synchronisation, and the question of which side is authoritative. Also its own section, because it is the hardest problem in this article.
• Monitoring that spans both. Two monitoring stacks that do not share a view means nobody can answer "is this slow because of the application or because of the link". Cross-boundary observability is the thing most often deferred and most often regretted.
• Change coordination. A cloud vendor upgrades on their schedule. Your on-premise systems upgrade on yours. The interface between them has to survive both, and nothing in either release process is obliged to tell you when it will not.

None of this is exotic. It is standard integration engineering, and the patterns are well established: an integration layer rather than point-to-point connections, contracts between systems rather than direct database reads, idempotent operations and a replay path for when a message is lost. Where the volume and the number of interfaces justify it, an integration platform is the usual answer, and the explanation of what iPaaS is and when it earns its place sets out what that buys and what it does not. The failure modes are equally well established, and the catalogue of common integration mistakes covers most of what goes wrong at a boundary like this.

The security dimension of a cross-boundary interface deserves separate attention, particularly where one end of it sits near a segmented network. The practices worth applying are set out in the integration security best practices guide.

5. Identity and access across both sides

A single sign-on story that spans both sides is the difference between a hybrid estate people tolerate and one they resent. This sounds like a convenience issue. It is not. It is a control issue wearing a convenience costume.

Where identity is fragmented, three things follow reliably. Users accumulate separate credentials and manage them badly, which is a security outcome, not a user-experience one. Joiners, movers and leavers processing has to run twice, and the second run is the one that gets missed, so access persists after someone leaves. And access review becomes a reconciliation exercise across two directories rather than a report, which means it happens less often and tells you less when it does.

The target I would set is one authoritative identity source, federated to everything else, with group membership driving entitlement on both sides rather than local permissions maintained per system. That is achievable with ordinary enterprise tooling and it is not where the difficulty sits. The difficulty is organisational: agreeing which directory is authoritative, and getting the systems that currently maintain their own local accounts to give that up. In an estate that grew by acquisition, this is typically the single largest piece of hybrid remediation work, and it is worth sequencing it early, because almost every other improvement is easier once it is done.

One case deserves naming. Systems on the plant network frequently cannot reach the enterprise directory, by design. Shared operator accounts on a control system are a known and sometimes deliberate exception rather than an oversight. Treat that boundary explicitly, document why it exists, and compensate with physical and procedural controls, rather than quietly leaving it out of the identity design because it is inconvenient.

6. The data question: which side holds the master record

For any piece of data that exists on both sides, one side must be authoritative. That rule is simple to state and it is where most hybrid designs quietly fail, because the honest answer is often "both, a bit", and nobody wants to be the person who says so.

The workable patterns, in rough order of how much trouble they cause:

• One master, one-way replication. One side owns the record, the other holds a read-only copy. Simple, debuggable, and the right answer far more often than it is chosen. Conflicts are impossible by construction, which is the whole point.
• One master, with queued writes from the other side. The secondary side can capture changes offline, but those changes are submitted to the master rather than applied locally as truth. Work order completion from a disconnected site is the classic case. Harder than one-way, still tractable, because there is never a question about who wins.
• Partitioned ownership. Each side masters a distinct subset of records, for example the cloud EAM masters the asset register while the site system masters live meter readings. Works well, but only if the partition is genuinely clean. A partition with grey areas is bidirectional sync with extra paperwork.
• Bidirectional sync between two authoritative systems. Both sides can write the same record. This is the hardest pattern in this article and I would avoid it wherever there is any alternative. It requires conflict detection, a resolution rule that is defensible to the business and not just to the integration team, and a way to show an auditor why one version won. Teams routinely underestimate it because the happy path is easy to build and the conflict path is where all the work actually is.

Related to this is where the master asset register itself should live, which is a prior question to the hybrid design and one worth settling first. The considerations are set out in the overview of cloud-based asset management software. Where the enterprise suite and the asset layer come from the same stack, that constrains the placement decision in ways worth understanding early, and the look at Oracle Cloud and Fusion for enterprise asset management is a useful worked example of how a vendor stack shapes the boundary.

7. Operating a hybrid estate

The design is the smaller half. Running a hybrid estate means carrying two of several things permanently:

• Two skill sets. Cloud platform engineering and traditional infrastructure are related but genuinely different disciplines. Few teams are strong at both, and the weaker side is where incidents cluster.
• Two patching regimes. One you control and schedule, one the provider controls and announces. Coordinating them around an interface is ongoing work, not a project.
• Two security models. Perimeter and segmentation thinking on one side, identity and policy thinking on the other. They have to meet somewhere, and the meeting point is usually the least examined part of the estate.
• Two support routes. When something spans the boundary, the first forty minutes of the incident are frequently spent establishing which party owns it.

The organisational failure worth naming explicitly is this one: cloud belongs to "the cloud team", on-premise belongs to "infrastructure", and the space between them belongs to nobody. The interfaces, the connectivity, the identity federation and the cross-boundary monitoring all sit in that gap. They are the components most likely to fail and the components least likely to have a named owner, a runbook or a line in anyone's objectives. I would treat assigning that ownership as a precondition of going hybrid deliberately, not as something to sort out later. It costs nothing to decide and it is the single most reliable predictor of whether the estate is operable.

8. When hybrid is the right answer

Without hedging, there are four situations where hybrid is correct and should be stated as the target architecture rather than apologised for:

• A genuine regulatory constraint that has been verified against the actual instrument and the actual jurisdiction, not assumed from a general impression that the sector is regulated.
• A genuine latency or resilience requirement that has been tested, in the sense that someone has established what happens to operations when the link degrades, rather than asserted in a design document.
• A plant network that must stay segmented, which in practice covers most organisations running control systems. The segmentation is the control. Weakening it to simplify the architecture is the wrong trade.
• A staged migration with a defined end state and a date, where hybrid is explicitly the interim and the interim has an owner, a plan and a budget line.

The fourth one is conditional on all three qualifiers. A staged migration without a defined end state is not a staged migration. It is the next section.

9. When hybrid is just an unfinished migration

The tell is simple and it works almost every time. Pick a workload and ask why it sits where it sits. If the only available answer is that it always has, that placement is not a decision, it is sediment.

An accidental hybrid is not automatically a crisis. Many of them run acceptably for years. The cost is that nothing can be optimised, because no principle governs placement, and that every new system lands wherever the project that bought it happened to put it, which compounds the problem one procurement at a time.

10. Making it deliberate

Turning an accidental hybrid into a deliberate one is mostly documentation and decision-making rather than engineering, which is why it rarely gets funded and why it is nonetheless the highest-return work available in this area. Three artefacts carry most of the value.

• A workload inventory with a stated placement rationale. One row per significant workload: where it runs, why, what it integrates with across the boundary, and who owns it. Writing the rationale column is the exercise. It is where you discover which placements are architecture and which are sediment, and it typically takes a few sessions rather than a project.
• A defined target state, including the option of "permanently hybrid". This is the one organisations resist. Writing down that a workload stays on-premise indefinitely feels like admitting the cloud programme failed. It is the opposite: it closes the item, releases it from the migration backlog, and lets you invest in running it properly rather than treating it as temporary for another five years.
• A review trigger rather than a review calendar. Annual architecture reviews get skipped. Triggers do not, because they attach to events that are already happening: a contract renewal, a major version upgrade, a change in the regulatory position, an acquisition, or a material change in the volume crossing an interface. Attach the placement question to those events and it gets asked when it matters.

Cost modelling belongs in this decision too, and it is more subtle than comparing a licence to a subscription, because the hybrid case carries the boundary cost that neither pure model does. The total cost of ownership comparison between cloud and on-premise is worked through in the cloud versus on-premise total cost of ownership analysis, and I would read the placement question and the cost question together rather than letting either decide alone.

11. The honest limitations

Three things about hybrid are true and uncomfortable, and an article that leaves them out is selling something.

The idea to walk away with

Hybrid cloud is not a strategy an asset-intensive organisation adopts. It is a condition most of them are already in, arrived at through OT and IT separation, site resilience requirements, data constraints, legacy systems and acquisition. The work is not deciding whether to be hybrid. It is converting an accidental hybrid into a deliberate one: knowing which workload sits where, why, who owns the boundary between them, and which side holds the master record for every piece of data that exists on both.

That conversion is mostly writing things down and assigning owners. It does not need a platform, a programme or a vendor. It needs someone to ask, workload by workload, why this sits here, and to keep asking until the answer is a reason rather than a habit.

Final thoughts

If I had one recommendation for an organisation reading this and recognising itself, it would be to spend a morning building the workload inventory with the rationale column filled in. Not an architecture review, not a programme, just the list. It is uncomfortable to produce, because the blank cells are visible and they are the point, and it usually reveals that two or three placements are genuinely constrained while the rest are historical.

From there the decisions get easier. Some workloads will have a real constraint and should be declared permanently hybrid, properly owned and properly funded. Some will have no constraint at all and can be scheduled to move on a date, or equally legitimately left where they are with that choice recorded. And the boundary itself, the part that today belongs to nobody, gets an owner. That is most of what separates a hybrid estate that works from one that merely persists.

Related reading: Cloud CMMS versus on-premise, Cloud versus on-premise total cost of ownership, Migrating CMMS and EAM to the cloud, Edge versus cloud for predictive maintenance, What iPaaS is and when it earns its place, Common integration mistakes, Integration security best practices.