Oracle Just Rewired How Your PMS Talks to Everything Else. Most GMs Won't Notice Until Something Breaks.
Oracle's new OHIP Streaming API replaces the old polling model with real-time push notifications for OPERA Cloud integrations. The technology is genuinely better... but the question nobody's asking is what happens at your property when the transition isn't optional anymore.
I worked with a GM once who kept a laminated card behind the front desk. It listed every system that talked to the PMS, what each one did, and... this is the part that mattered... who to call at 2 AM when any of them stopped talking. She updated it every quarter. Her regional VP thought it was quaint. Her night auditors thought it was the most important piece of paper in the building. They were right.
Oracle just made a move that's going to matter to every hotel running OPERA Cloud, which at this point is a significant chunk of the industry. They've shifted their integration platform (OHIP) from a polling model to a streaming model. In plain English: instead of your connected systems constantly asking the PMS "anything new? anything new? anything new?" every few seconds, the PMS now pushes updates out in real time the moment something happens. Reservation change, room status flip, guest check-in... the data flows immediately to every system that needs it. They're using GraphQL Subscriptions and WebSockets, which (for the non-technical folks) is essentially the difference between refreshing your email every 30 seconds and getting a push notification the instant a message arrives. It's faster, it's lighter on the system, and it means fewer of those maddening moments where a guest checks in but housekeeping's system doesn't know for another three minutes.
Here's what I like about this. It's a real architectural improvement, not a marketing rebrand of existing functionality. The old polling approach created lag, ate bandwidth, and generated unnecessary server load... especially at properties with dozens of integrations all pinging the PMS simultaneously. With 1,200-plus partners building on the OHIP platform and 650-plus live in the marketplace, that's a lot of simultaneous conversations. Streaming cleans that up. And for properties where your infrastructure is already strained (and let's be honest, if your building was wired before 2010, your infrastructure is strained), reducing that constant back-and-forth polling traffic is meaningful. The real-time piece also opens the door for things like instant mobile key delivery, live housekeeping dashboards that actually reflect what's happening right now, and revenue management systems that can react to booking patterns as they unfold rather than on a delay. That's genuine operational value.
But here's where I start asking the questions that don't show up in the product announcement. Oracle is actively sunsetting their legacy SOAP-based integrations in favor of OHIP's REST-based APIs. That's industry speak for: the old way your systems connected is going away, and every vendor you work with needs to rebuild their connection to the new standard. If you're running OPERA Cloud with eight or ten integrated vendors... your door locks, your payment gateway, your housekeeping system, your RMS, your guest messaging platform... every single one of those vendors needs to migrate to the streaming model or eventually get cut off. Some of your vendors are Oracle marketplace partners with dedicated engineering teams. They'll be fine. Some of your vendors are smaller companies running lean, and rebuilding an integration isn't a weekend project. The timeline between "Oracle announces new architecture" and "your door lock vendor actually supports it" can be months. Sometimes longer. And during that gap, you're running a patchwork of old connections and new connections and praying they all play nice together. I've seen this movie before. The technology gets better. The transition is where things get ugly.
The other thing nobody's talking about: Oracle's cloud revenue just hit $8.9 billion in Q3 (up 44% year-over-year), and their remaining performance obligations are at $553 billion. That's not a hospitality number... that's the whole Oracle machine. Hospitality is a vertical inside a company that is aggressively, almost maniacally, moving everything to cloud subscription revenue. Which means the pressure to migrate every property off legacy systems and onto cloud-based, subscription-priced products is not going to slow down. It's going to accelerate. If you're still running on-premise OPERA and thinking you've got time... you have less than you think. The integration ecosystem is being rebuilt around OPERA Cloud. The partners are building for streaming APIs. The old architecture isn't getting investment. Nobody at Oracle is going to call you and say "we're forcing you to migrate." They don't have to. They just have to make staying where you are progressively more painful until moving is the only rational choice. That's not a conspiracy. That's how platform companies work. I've watched it happen with three different enterprise vendors over the last 20 years. Same playbook every time.
If you're running OPERA Cloud with multiple third-party integrations, pull up your vendor list this week. Every single one. Find out which ones have migrated to the OHIP streaming API and which ones are still on the old polling or SOAP-based connections. The ones that haven't migrated are the ones that are going to cause you problems in 12-18 months when Oracle starts deprecating legacy connection methods. This is what I call the Vendor ROI Sentence test... if your vendor can't tell you in one sentence how they're keeping up with your PMS platform's architecture changes, that vendor is about to become a liability on your operations, not an asset. And if you're still on on-premise OPERA thinking migration is optional, start getting quotes now. Not because you need to move tomorrow. Because when the integration partners stop supporting your version, the decision gets made for you... and it's always more expensive when you're reacting than when you're planning.