For us, it was a very complex setup. It was not only setting up a server, installing Octane, and doing configurations. Our plan was to have a shared Workspace concept with six or seven Workspaces. We did have a major challenge in doing all the configuration stuff, defining methods and processes. We also had to connect at least ten major tools or databases, which are synchronizing information into Octane, or which are used for the special methods of test planning and test automation; pulling information from Octane and running them on our test benches in semi-automated cars.

That was a very complex process.  There were some small problems and some bigger problems but we found solutions for all of them.

Because we have some 70 to 80 suppliers that are part of an automated defects exchange, our development, our testers, are reporting defects and those defects are exchanged with those 70 to 80 suppliers. So it's a very complex situation we are in.

Of course, users have to learn different things compared to ALM.Net, the old version of the tool. But we're getting good feedback from the users that as soon as they are used to the idea that they have to use a different tool, they are learning how to use it very fast.  There are fewer obstacles in the tool, in this regard, compared to others. Even if you're a JIRA user, you have to overcome that, "I have to use a different tool" issue. There are people who are doing this very easily and with a smile, while some are just trying to stick to the known tools. But that's the change process.

For deployment and maintenance of the tool, there was a major team of experienced IT guys and process guys from our side, about 25 people, supported by about 60 other people just for the special processes of the different development departments. We call them "key users." They are collecting information and reporting it to the core team. For maintenance, it's a team of six people who are implementing changes requested by the core team. Depending on the workload, on average, maintenance is done by three people. There were numerous software developers working on the interface tools, perhaps some 30 IT guys working on the different tools we needed to launch with Octane.

The initial setup is straightforward.

There's a migration SHIFT from ALM to Octane that is straightforward.

The product's initial setup phase was straightforward.

The solution is deployed on an on-premises model.

The time for the product's deployment phase is something that depends on how much of the product a user wants to use. In my company, we actually indulge in the product's onboarding process team by team and project by project, meaning it's not about just implementing the product all the time but moving in a step-by-step manner.

Around ten people who take care of administration and engineering areas in our company take care of the deployment and maintenance of the product.

I don't want to call it complex, but it was different. The initial setup felt a little complex just because it's a different architecture, and we were also doing it on-prem. If it's a SaaS, obviously, you don't even have to worry about setting it up.

One thing we have noticed, since we have done two upgrades, and we're getting ready for the third one, is that the upgrades have been so simple and easy. In the previous legacy platform, upgrading was a project for us. There was a lot of planning, a lot of people were involved, and there was a lot of downtime. 

For Octane, we get quarterly upgrades and we lag for a couple of weeks and then start upgrading our environment. That's been a huge difference. That way, we are not staying on an older version for many months or even years. We just upgrade as soon as the versions are available from Micro Focus.

We installed it on the side of the existing one, and we migrated step by step or project by project. 

To start with, it was pretty complex because it was a pretty new solution when we installed it. We were probably one of the first bigger companies installing it. So, we were quite early adopters, but it is a lot easier today to install this. We haven't had any problems. There are very few errors in the solution.

It was done a long time ago, but we spent a lot of time because we had to explore enabling single sign-on, etc. That contributed to taking some time, but that had nothing to do with the product. It is probably a lot simpler today.

The deployment of the solution can take approximately four hours. However, it depends on the environment. The solution can be integrated with GitHub.

I rate the initial setup of Micro Focus ALM Octane a seven out of ten.

The initial setup for Micro Focus ALM Octane was pretty straightforward, but its infrastructure requirement needs improvement because you need a lot of resources to set up Micro Focus ALM Octane.

It only took a day to complete the software installation, but for the infrastructure, that's my main obstacle because it's resource-heavy.

The initial setup for Micro Focus ALM Octane is very straightforward.

The initial setup process is straightforward. The platform has well-defined, out-of-the-box workspaces and projects incorporating good practice workflows.

I rate the product's initial setup a seven on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on an on-premises model.

The initial set up was very simple. The tool from getting our license to starting to use it, there is not a lot to do. We have evolved with the tool, as the tool has gone on, but we started using it straightaway. There was nothing that we needed to do to make that tool work. We have taken a very step based approach. We started using it, then we developed some changes in the way the workflow flowed. We have added additional fields here and there, where we decided we needed to do so. Then, we added additional bits of functionality through other bits of integrations as we've been seeing the need or when we know we've embedded it in processes with other things. We've rolled things out slowly. It seems slowly to us, but it's actually not taken that long.

There is not a deployment. It's literally they give you access. They go, "Your licenses are ready," and you login. That's it, then you start using the tool.

The planning phase for me was a year long project, getting everyone on the system and all the data migrated. Initially, it was about creating a need, because no one knew they needed a new tool until someone looked into it. I identified the need and problem, did the analysis, made the recommendations, presented the options, made the recommendations, and collected the requirements. There were a lot of requirements. Then, I went out and engaged with our InfoSec Department and our procurement process. I officially got sponsorship from the directors in about March for the project who saw it and put some money aside to be able to do it. It was a fairly smooth process from start to finish, but it was hard for me because initially there was no need for it. I created the need for it, then from that point on, it was a very smooth process.

I was the single person driving that process, but then it was a member of staff from procurement. I touched base with multiple areas of the business that would have been using it to gather requirements, so nine scrum masters for half an hour each. Architects were all advisory. Contract specialists/managers to do the contracts. We had our legal team. I was the single resource that drove the process, created the documentation, and found the supplies.

I am the person now maintaining the system. It shouldn't take more than me, but it probably won't be me forever. The only reason it requires maintenance at the moment is because of misuse, so it's not like things go wrong with it all the time. It's more of a case of that it's self-sufficient and I can go through and review the work that people do, ensuring they are using the tool and populating it as we would like them to, thus we can get quality data out of it. 

The solution's initial setup process is reasonably easy. On a scale of one to ten, where one is difficult, and ten is easy, I rate the initial setup an eight out of ten, considering its ease of installation.

There are various options to deploy the tool. In the company that I worked for, we did not use much of the tool. We were only providing this tool for our customers. So, mostly the solution was deployed on-premises even though there were options to deploy the solution on the cloud. The deployment process can be carried out in three to four days or a week maximum.

We have the SaaS. The system was all set up and working through the Micro Focus SaaS team. For me, it was just a matter of getting access to it. They said, "Here, put in your user ID and password," and that's how long it took.

Setting up ALM Octane is straightforward because we were already using Micro Focus ALM for testing. We were implementing it in the business requirements area. That was four years ago, so I can't remember exactly how long it took, but it was a few months. I'd say maybe two to three months. We did it on our own with Micro Focus guiding us. And Micro Focus had a statewide user base at the time. Other departments were using it, so we were able to share what everyone was doing. I have two FTEs. One is in charge of the business requirements module, and the other oversees the test testing and defect management.

It was pretty straightforward. Everything was written in the documentation, down to the smallest details. The package was as an RPM package which was good for our administrator in doing the installation. The only thing that bothered me was the configuration of the .YML file. It was actually really simple, according to what they described about what to configure there, but there were some delicate points that we had to pay attention to. Other than that, everything was really good.

The installation itself only took our administrator a few minutes. If I hadn't had problems with the .YML configuration, it probably would have taken me a couple of hours to complete the installation.

The onboarding, the transition from the old tool to the new, is quite a challenge though. We have been using ALM.NET for ten years or more. We are still finalizing the pilot, but our thought is that if we go to Octane, we would prefer to go with a greenfield approach. It's not that we're going to migrate stuff from ALM.NET to Octane. We will just start fresh, from scratch, in Octane. 

The reason is that the tool provides really good functionalities for us, especially for testing. It's good to take a chance. There will be a review process and we'll try to really integrate the process with the tool.

For us, the initial setup involved three to five people, until the application was ready to be used. We have been maintaining it for 13 months with two people, myself and the consultant.

The initial setup was difficult and took over three months.

The deployment was straightforward. The documentation clearly states the requirements regarding what hardware is required. Additionally, all the installation and deployment guides are good.

The deployment went through phases. First, we installed the system, which was pretty fast. After that, we migrated all the data from Quality Center, which was an additional task.

The upgrade was super fast. We were so impressed. We ran a test first, but after that, it took maybe 90 minutes altogether. That includes the backup of systems. Before the upgrade, we backed up our Elasticsearch because ALM Octane comes with Elasticsearch, and in our case, it runs on Unix machines. So, we backed up Elasticsearch, the data repository for all the attachments, etc., then took a snapshot of the database and the Windows machine, which was the longest part. Some of the snapshots, we did in advance, and some of the snapshots we did just prior to the upgrade. 

We did two upgrades at once because we missed the previous one. The upgrade to 15.1.20 took about 10 minutes, then we did some checks and everything was working fine. We then did the further upgrade to 15.1.40, which was another 10 minutes. 

I don't do the software installation or that side of things, but in terms of our implementation strategy, we have four environments in which there are seven servers. In our lower environments, our base environment, we have one server that gets installed. 

We don't have any integration that we support currently, so it's a standalone environment. We do integrate into an Elasticsearch farm, as well as to LDAP for user creation, password validation, etc. We have those basic types of integration setup, but we don't have integration to other tools such as DevOps tools, yet. We are currently working on integration to PPM, and that's going to be deployed in the next couple of weeks.

Once we get up to our stage and production environments there are multiple servers on a load-balancer, so that adds an extra degree of complexity to the setup. They're also externally exposed to the internet so that our clients and external users can have access to the tools.

We are on SaaS. Setup and deployment were immediate and required no effort on our part, except to make the request. This was also true for staging environments for a PoC.

Initially, our implementation strategy was to enable a trial period of six months to one year. The community response was so overwhelming that we went into a production mode within the first quarter and began setting up and migrating teams within the first year. Even emphasizing that the platform at that time was essentially a PoC, teams adopted it, even with the risks, and never looked back.

We work directly with our Micro Focus CSM. The technical team, including R&D, is first-class.

We are working with the Hybrid version, but It even extends to on-premises. It is both the on-premises and cloud versions.

The initial setup is straightforward.

I believe it depends on the circumstance, getting it up and running seems to be rather simple. It appears to be suitable for standing up in a bigger setting.

If I compare it to Jira, for example, and you are in a complex environment, you have to ensure that everything is updated and all of the plugins, and everything works every time there is an update, but you don't have that problem with Micro Focus' Octane.

The initial setup was absolutely perfect and very easy. It was fast getting into the work. We were up and running in a very short amount of time. We switched from one tool to another in days, which is very good. 

It was really straightforward. It was a pleasure to implement our approach with it, compared to ALM or to the older tools. It was really easy. I started from zero with Octane. I had never seen it before. It was brand new and I really learned it on my own, everything in there, including the setup and how to implement the processes, etc.

In terms of maintaining it, right now it's just one person. Once we scale it, I don't expect it will take many more people to maintain it because it's very easy to maintain. If it's set up well there shouldn't be too much work to do there. For the technical parts, we will still need only one person and, within the project - depending on the number of projects - we will need, perhaps, one guy who's taking care of it from time to time.

I was involved in it, yes, but I have to qualify that. It's SaaS. All I have to do is call Mike. I didn't have to do anything, really, other than start using it. It's intuitive as can be.

Because we came from ALM QC, and that tool was in use for quite some time, there were a lot of user-defined things and customization. Initially what we had to do was a cleanup on the QC side: what we wanted to take over and what we didn't want to take over. We really cleaned out stuff that wasn't needed anymore. That took one or two months. 

The actual installation of Octane was very quick and straightforward. The customization and configuration of Octane took about two months. That was because we were very new to the application. If I set up a workspace now, it's much faster.

We have 1,100 users and their roles are really across the company. We have project managers, developers, testers, release managers, and test managers. We also have business users and product managers on the Agile side. Any role you could think of is using it, apart from the C-level.

What I like a lot about Octane is that it's very easy to handle from an admin point of view. The maintenance is very low compared with ALM QC where it took several hours or days, even, to set it up and upgrade it. Those processes are very easy with Octane.

Initial setup can be a bit difficult, particularly for people who are unfamiliar with all the components. For us, setup took about six months.

It's straightforward. Because it's a SaaS application, we got access to the server. And then the URL was sent and we started using it. So it's that straightforward.

The initial setup was in between: not very complex, not so simple. Medium.

I thought the initial setup was pretty straightforward for us. We started off with ALM.NET on-premise. We then took the SaaS offering. So our initial challenge was to migrate our existing ALM.NET projects into the SaaS product. We then were made aware of Octane, which was made available to us quite easily, and we were able to start using it.

What we didn't do, because of various challenges with our program, was we didn't really get too involved early because we weren't ready. So although the tool was ready, we weren't ready to consume it. But in the last few months, we've made quite a few strides with that. We're now at the stage where we need to say, "What more can give this give us?" There's a lot we can do. What is it we want to do? That's probably where we are now.

Our implementations strategy for Octane was quite simple. Because we've got this program of work, which is a cloud transformation program, we used that program as a proof of concept with Octane. That program worked, which is lifting and shifting 70 business applications. They are being migrated from on-premise to cloud, and each one of those migrations, on an application-by-application basis, is being managed by Octane. So our implementation strategy was to use it for this program of work. Once we realized the good and the bad, we could then start implementing it across the rest of the organization.

The staff from our side required for deployment was none. For us, it was just a request to Micro Focus and then agreeing to pay for licensing. It's a URL, basically.

For administration within our organization, the overhead is that there are several admin tasks, such as creating new backlogs, creating users, and administering users. It's no more of an overhead than with any other test management tool. The admin side is still the same. You have to set up your folder structures, you have to set up the users, you have to disable users when they leave the organization. It's simplistic and it's quite easy.

Here, because we're quite a small organization, we've got three people with admin rights, and between them they handle requests as they come through. We've got a site admin and a project admin. It's a layered type of admin, as much as it was in the previous products. The site admin can do everything and project admin can do everything within that project.

The product was there for us. As soon as we requested it, it was made available, so there was no implementation, as such, for the product. It was down to us to make use of it, and start creating our backlogs, and our structures, etc.

The actual Octane installation is straightforward, but it was a complex process for us because it is a cluster architecture. We have two Octane applications, three Elasticsearch, two databases, and seven to nine servers. While complex, we are not experiencing any issues so far. 

It was a nine week activity where we did the initial setup. The process was complex. We found issues while doing the integration between Jenkins and the DevOps and automation tools. 

When we started the integration with the other tools, like Jenkins, Selenium, or UFT, and tried to automate things or integrate with Jira, then it took more time because of the compatibility issues. It may not be working as expected and my automation framework may be different as well as Octane may not support my automation framework. My automation framework may be using Selenium, so I have to change my automation framework to ensure that it works with Octane. These things have to be in front of the client in advance to work out and give advanced information about compatibility issues of the automation framework and compatibility with the Octane, so an evaluation can be done during the due diligence on the first week of the kickoff meetings. Then, we can save time during the implementation.

The end-user in charge of testing could easily deploy Octane, onboard new users, and train new users.

We did the SaaS version, so if anybody has loaded up Octane SaaS, you just put in your email and request a version, that's basically the setup. So it's just as easy as implementing any kind of open source tool, maybe even easier, because you have built-in support right there. It's extremely easy to do.

You need technical knowledge in order to install this product, the documentation is complex but it could be made easier to read

The initial setup was not complex. It was very good for us.

The initial setup of Octane was straightforward. Because you are talking about development and software developers, it's not like a normal tool for business users. It was not complicated for people to get along with the tool and use it and integrate it.

Usually, deployment takes, on average, a maximum of two months. The deployment plan definitely depends on what the current technologies are, the integrations needed, and on what types of development environments and what types of IDEs are involved. It also depends on whether there are other systems and tools available already.

Just one person is required for deployment and maintenance of the solution. Rather than a developer, that person would be an administrator for the system.