OpenText Operations Orchestration Reviews

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

Buyer's Guide

OpenText Operations Orchestration

June 2026

Free Report: OpenText Operations Orchestration Reviews and More

Learn what your peers think about OpenText Operations Orchestration. Get advice and tips from experienced pros sharing their opinions. Updated: June 2026.

DOWNLOAD NOW

900,644 professionals have used our research since 2012.

What was my experience with deployment of the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and support?

How was the initial setup?

What about the implementation team?

What was our ROI?

Which other solutions did I evaluate?

What other advice do I have?

What is most valuable?

How has it helped my organization?

What needs improvement?

For how long have I used the solution?

Which solution did I use previously and why did I switch?

How was the initial setup?

Which other solutions did I evaluate?

HP Operations Manager has been around a long time in the Enterprise server management space. I first started working with it around 2001, and I’ve always had a soft spot for it, but I’m ready to declare it abandoned. HP has failed to develop the product, and they now seem to be actively working on a viable alternative.

HP Operations Manager (HP OM) is an agent-based server monitoring system. Agents are installed on monitored systems. Monitoring policies are defined at the central server, and pushed to agents. This keeps the bulk of the processing local, as agents only need to raise exceptions. It also makes agents very powerful – they can do anything on a managed node – check processes, monitor logfiles, run actions, etc. HP OM can also act as a Manager-of-Manager, receiving and consolidating events from other systems – e.g. HP SIM, NNMi, Storage Essentials, SiteScope, etc. It has been around in some form or another since 1993. It’s had a few name changes over the years – OpenView Operations, ITO, VantagePoint Operations, and now just Operations Manager. It has Windows and Unix versions (abbreviated to OMW and OMU/OML respectively). The Windows and Unix variants use the same agents, and can share policies, but the administrative and operator interfaces are completely different.

Development for HP Operations Manager appears to have stalled recently. The last update for OMW (9.0) was in September 2010, and the last update for OML/OMU (9.10) was in November 2010. Since then we have seen further releases for the underlying Operations Agent, and some small patches for Operations Manager, but no real enhancements. HP OM has increasingly ill-suited to modern dynamic environments, and unsurprisingly I hear that sales are well down, and crucially support renewals are dropping significantly.

HP OM has not adapted well to modern demands. It does not deal well with VMs being deployed at a high rate. It does not offer service monitoring capabilities. It does not offer any way to connect to cloud provider APIs. The agents have continued to be unstable. The administrative interface for OML/OMU looks like something I wrote over a weekend based on a shopping cart – it does not look like a piece of software that costs tens of thousands of dollars. Or actually maybe it does – Enterprise software in general tends to be ugly. HP didn’t even develop it themselves – they licensed the admin interface from Blue Elephant Systems. The Java GUI for OML/OMU was a disgrace in 2002 – and it hasn’t changed since.

Java GUI circa 2002

Java GUI circa 2012

(OK, so I cheated, those images are the same – but that’s because it hasn’t changed).

I can only assume this lack of development was because they lost out politically, and could not secure the necessary funding and resources. I believe the turning point for HP Operations Manager was the 2006 purchase of Mercury Interactive. This completely reshaped the HP Software division. That portfolio included SiteScope, an agent-less server monitoring system. OM’s design and architecture just didn’t fit into this model. Efforts to integrate them have been derisory – e.g. the system for using HP OM to manage policies across multiple SiteScope servers is the sort of poor code that I might do as a quick hack. It does not meet the marketing message of “fully integrated.”

Also consider this diagram showing how Operations Manager should fit into your overall architecture:

Image from www.softpanorama.net

Note how everything feeds into Operations Manager, which then feeds into Operations Manager i (OMi)? To the uninitiated: OMi is a different product, in spite of the near-identical name. When you look at that, you ask yourself – what’s the point in HP OM there? Why not just feed directly into OMi?

So what’s the future of OMW/OMU? Let’s try reading between the lines – look at the recent announcement by HP about OMi Monitoring Automation. This separates monitoring policies (configuration, thresholds, etc) from implementation (agent-based, agentless). It bypasses the OM server requirement, with agents directly managed by the OMi server. I haven’t seen enough of the implementation details yet to confirm that OM has been completely replaced, but it’s clear enough to me what the future direction is. Development has continued for Operations Agent, but clearly Operations Manager is surplus to requirements. Well maybe it all makes sense – why the hell did they ever have two separate products, one named “Operations Manager”, and another named “Operations Manager i”?

What future for HP OM then? It now only makes sense as a Manager-of-Managers for organisations that are too small to commit to the whole HP BSM suite. Even those organisations need to re-think their use of OM though, as it can’t handle a dynamic environment, and stands little chance of being able to integrate proper APM, or cloud service monitoring. There are other products out there that are better suited to modern medium-sized organisations.

To the HP people reading this: Obviously you can’t publicly confirm any of this. You’ve promised ongoing support to those still paying their annual support fees. But if I’m wrong, then show me the code. Deliver some updates to the product, and show us that it is being actively developed. Vague promises of continued commitment mean nothing without shipping code. To customers using HP OM: My advice is to start planning your migration away from it, if you haven’t already. To customers considering purchasing it: Don’t, unless you’re buying it as part of an overall BSM/OMi implementation, and the salesfolk have guaranteed you can change your licensing over at no cost in future.

Disclaimer: The company I work for is partners with several vendors including HP.

I give HP Operation Orchestration 4 stars - compared to other similar orchestration products, it is an excellent solution.

Use Of Solution:

4-5 years.

Valuable Features:

The ease of use (Studio). You don't have to be a programmer and it's something that anyone can pick up and put to good use to deliver solid solutions.

Improvements To Organization:

The best example I can think of is where I had Network Engineering management asking for customizations to Network Automation and reporting that would be done outside of Network Automation. Operations Orchestration provided an easy solution! I was able to integrate Network Automation and Operations Orchestration and create some basic flows that would collect the custom information that the manger was interested in and pass that on to Network Automation. Another flow was able to produce the reports they were looking for - the beauty was they were not able to tell that the report was not out of Network Automation and the custom data that was collected wasn't an out-of-the-box Network Automation function.

Another example was creating a solution for a client who had Network Automation, Server Automation and Operations Orchestration. I needed to collect Network Automation logs on a set routine (for support) and was able to create a rather basic flow using Server Automation (OGFS).

Room For Improvement:

It can be tricky of flow management (promotion of flows from one environment to another). Stability and scaleability are something you need to plan for when you do your initial design - I would say it is more stable than it's competitors - make sure you have an idea of how many flows you are planning on running in a set time. Redundancy (disaster recovery) is a bit of a problem, but there are ways to do it.

Note: version 10 does address many of these issues, but wanted to comment on the version I had worked most with.

Deployment, Stability, Scalability Issues:

Initial deployment is great. As I mentioned above, the key for stability and scalability are tied to the initial design.

Previous Solutions:

I have used other products since I started using Operations Orchestration (as it was in use by another client) - BMC Atrium Orchestration.

Alternate Solutions:

No

Customer Service and Technical Support

I would say it is on par or better than it's competitors. There is also an exceptional community of users who are willing to help and share information - what worked and what didn't work.

Initial Setup:

Rather simple.

Implementation Team:

I've done both, first with vendor team and they were great for ensuring that we had a solid design.

ROI:

N/A - I do not feel I can comment on this as I not involved with these companies. I will say that one client showed ROI based on time & quality savings, the other was in dollars.

Other Advice:

Take your time and plan the design. It is very easy to get over-excited about the power and possibilities with Operations Orchestration and try to do too much too quickly. One should learn how to walk first. The beauty of the product is you can easily add and expand initial flows, so you aren't throwing away your work if you need to add / expand. Take your time, educate staff as to how it works and what it can do for the company. Create a way to evaluate possible flows and part of this can be to figure out ROI on a flow basis (it can be a bit difficult to do after the flow is done). If you are replacing a manual process of existing script(s) - make sure that everything is well documented.

Valuable Features:

Improvements to My Organization:

Room for Improvement:

Use of Solution:

Initial Setup:

Implementation Team:

Other Solutions Considered:

Other Advice:

I'm just starting to transition flows from 9 to 10 now. Central definitely seems quicker and more secure. Developing in studio is quite different given that we are now working with projects and are required to reference content packs and their operations (it feels similar to developing in visual studio in the way you create new projects and add references to dll's) but I must admit I am still learning v10. SCM seems to be a great alternative to the public repo in version 9. I'm hoping at some point HP allow us to utilise third party SCM's such as team foundation server so organisations can utilise their corporate SCM solution.

My challenge at the moment is converting our custom .Net ops from version 9 to 10. Also with exchange operations within the business applications content pack, if you get any invalid ops stating 'Plugin data Jar was not found in studio plugin repository' you may require a 64-bit version of microsoft.grouppolicy.interop.dll on your windows OS. (HP do have a work around)

HP documentation and the OO community have come a long way in providing a one stop shop for content, doco and updates. Although I'd love to see more videos of OO on the community page, such as development of new ops/plugins using maven as this is quite new to me.