Deploying Omada is extremely complex. The roll-out process was straightforward, but integrating it with SAP ECC was complicated. The connector package from Omada was insufficient. We replaced SAP ECC with SuccessFactors, and the integration was better.  

We went live in one department for around a year. Then, we started onboarding each location one at a time. We had calls with the local IT personnel, HR, and the managers in charge to explain what would happen and things they could not do. After that, we did some testing in our test environment. We compare what will change and which accounts will be removed or created. We spent half a year onboarding location by location. We had two staff members for deployment on our side and two members from Omada. 

I don't have the details about the solution's deployment since I wasn't directly involved in the setup. I just know that it wasn't as smooth and straightforward as we had hoped for.

Migrating from on-premises infrastructure to the cloud proved more challenging than anticipated. Planning for a six-month timeframe was unrealistic, and frankly, an overly ambitious expectation. While some vendors promote swift migrations, our experience revealed a year as a more accurate baseline. In our case, the process stretched to two years. Internal departmental requirements significantly contributed to the complexity.

The challenge wasn't solely about the migration tool itself. A key factor was our desire to migrate all historical data, which accounted for at least half the difficulty. Therefore, attributing the extended timeframe primarily to the tool would be inaccurate.

The project had a core team of at least 5 people who put in a significant effort. A larger group also contributed, but their involvement was more limited. Some of these contributions were temporary and focused on specific phases like testing. While the core team wasn't exclusively full-time, they were all deeply involved throughout the project.

It is cloud-based. It was a straight-up choice. You either go for the cloud setup or you go for an on-premise setup.

The initial implementation of Omada was done by a third party who was asked by the Dutch Omada representative to help us. It was a nightmare. This party did not know much about educational processes. They did not know about our organization. They had not done their homework, and they lacked the knowledge required to do an implementation on this scale. Their main objective was to finish the small task they had to do and start writing out new bills as soon as possible. We parted with this company, and the people from Omada took over. It was a whole brand new experience of happiness. Suddenly, all things went well. Agreements were met, and the things that we agreed upon were indeed carried out to the extent that we expected. For the price that we agreed upon, work was done as we expected it. So, the first part was bad, but the second part was good. In retrospect, we should have gone with asking Omada to implement it for us the first time. It would have saved us hundreds of thousands of euros.

It does not require any maintenance from our side. The Omada platform automatically provides a message when an update is ready and by when we need to do the update, such as at the end of this month or the end of next month. All we have to do is click three times, and the update is done. Being very cautious, we always wait for four weeks before doing an update. If there are any flaws in the update, they will be noticed by other users and corrected in the background by Omada.

The deployment was somewhat complex because we had to adapt our processes from a Onpremise solution to the Omada Cloud Version.

Migrating from the on-prem solution to the cloud took a little longer because we had to adapt our organization to the system and adapt some standard  processes. This should take three to four months if you're starting fresh and have all the data and processes sorted in your company. 

Before we decided to move forward with the Omada cloud version, we did an analysis and determined that we could handle all the new processes within 12 weeks. 

The initial deployment was straightforward. The setting up of the solution was done by Omada and it only took a couple of days. Then they came with a good description of what we needed to do and we were complete within the first week. Everything was up and running. Then we started building the business logic. That took some more time, but the actual setting up of the entire environment and having everything connected took just a few days.

Omada helped us to deploy IGA within 12 weeks. The first phase took eight to 10 weeks. When we started, it was much more about an HR product than an IT project. It was to get the organization to understand that HR needs to be the master of identities. After that, we needed a solution to take that data and turn it into something productive, and that's where we saw the first benefits of Omada.

It is implemented as a global solution. We have Omada running in the cloud. Then we have a VPN collection set up to Omada. And we have different HR systems running in our company and all of them are synchronizing their data on a daily basis to Omada through connectors. And we control AD, Azure, et cetera by the data that we receive.

On our side, there were four or five people involved from different teams. And the team from the Omada side had three people plus a project manager.

From an administrative point of view, there are 10 to 15 people using Omada. Eventually, I hope all our users will go into and do something. For now, we have 500 to 1,000 users who are doing something in the solution. This will increase more and more over time, as more accesses are ordered by the employees.

In terms of maintenance, there are always new things that we do in the system, but Omada takes care of everything when it comes to patching and upgrading the environment. The only thing that we do is upgrade it when there's a new version out. We just have to go into an admin site and say, "Now we want to do the upgrade," and it's one click of a button and it's done.

The initial setup is definitely on the complex side. The topic, because of the different interfaces in many, many different systems. It is due to a complex environment. It's not due to Omada.

For us, it is a SaaS solution. Omada was one of the top solutions in our tender because of the capability of doing all from the cloud. Its implementation took us about two years.

In terms of maintenance, we have to execute the updates ourselves. Omada tells us that there is a new release, and we can execute it ourselves. Within a time period, we can allow it to happen, which is nice. Within the system, we also have our configured workflows. We have to keep checking that everything is running properly. When there is an update done by Omada, we test it in staging before releasing it in production. We want to ensure that our most important flows are doing exactly what they are supposed to do. That is what I call maintenance.

Due to our prior experience with the system, which had thousands of users and resources, the migration process was relatively straightforward for us. Since it was not related to the grid field, we had all our necessary resources. We had to migrate both our system and our processes, including company policies for onboarding employees and the necessary steps that should occur, such as setting up an executive account. Overall, the migration process was relatively straightforward due to our existing processes and the commitment of our management.

Its deployment was very easy. To get everything ready, it took about a month or a little bit longer than that. We already had MIM, so everything that we had in the portal had to be built in Omada.

It is deployed on-premises, and we are using its latest version. We are working very hard to get everything standardized so we can go to the cloud. We have a lot of custom stuff, but we are doing our best. The email attachment issue is a big issue for me because I do not know how to get the right information to the new people then.

When we started with this system, it was Omada that hired some temporary project managers to implement the solution at our place, and they did not do a good job. We found out later that something was just not implemented. For example, if we rehire a former employee, we have no process to handle that in the system. We only found out about this after the original implementation. Today, they use their dealers to implement the system. I don't think Omada itself implements nowadays. Maybe it's better that way, but we were not satisfied with the way that it was implemented originally.

Our deployment was a long story because, in the middle of the implementation, Omada gave up and said, "You can go further with a dealer called ICY Security." They handed over the implementation to this dealer. It's difficult to say exactly how long it took, but if I have to give you a number, we are talking about between six and eight months.

Up until now, it has been our dealer, ICY Security, that has maintained the system. We recently took over maintenance of the system and the databases ourselves. But if there is development needed, it will still be our dealer that helps us with this. The whole area of identity management is complex, but ICY Security is doing a good job to help us grow in this system.

Omada's solution is in the cloud, but it integrates with an on-prem agent. It was deployed when I joined the company, but I was told that a new Omada project can take one or two years. 

The integration is potentially complex because you might need to connect it with hundreds of other systems. However, you can quickly migrate data from your HR system and connect it to your Active Directory. The standard installation is straightforward but grows in complexity with each new system you integrate.

After deployment, the only maintenance is regular system updates. You can schedule those with your sales team. I prefer the cloud version because the on-prem solution requires you to do everything yourself. You have detailed knowledge of databases, operating systems, and communication between the various servers. 

We messed up the data a few weeks ago, but restoring a backup snapshot from the previous hour was easy. We rolled back the database by an hour and were up and running in under 30 minutes. It's easy and convenient for us.

It was a complex process in terms of technicality and the amount of effort needed for setting it up from Omada's point of view.

We started in August 2018, and we finally deployed the solution and were ready for production in June 2020. So, it took 18 months.

We had to deploy or onboard a part of our infrastructure at once. We onboarded a couple of applications and our SAP solution on day one. Omada would probably call it the big bang, but it was definitely not the big bang. We deployed a lot of functionalities at once, but it was a very limited part of our total application portfolio that we deployed with Omada. It is not yet done. The first one and a half or two years will go into implementing the rest of our application portfolio in the solution.

We have deployed it on-premises, and we are in full control of the infrastructure and the servers. We are still on-premises, but we are looking at the cloud solution. I am comparing a lot of things and assessing how we can work with customization in the cloud environment. A lot of decisions need to be taken if we want to go the cloud route in the future.

Its initial setup is quite complex. The most complex thing was getting the software from version 6, which was the initial version we used, to version 12. From version 7 to 12, there were a lot of structural and data models changed within Omada. They needed to be adapted to our environment, so the updates took a lot of effort, but it has gotten much better over the past three years because they did not do any big structural changes.

It took a few months to plan and implement it, but the deployment just took a weekend because of the prior planning we did.

In terms of maintenance, it does not require that much maintenance. The maintenance is mostly at the data level. You have to clean up the data in the database once in a while. Overall, the maintenance is quite low.

It is deployed in the cloud. I was involved in its initial deployment.

As soon as you sign the contract with Omada, they give you a call and say that everything is open and you start configuring. It took a couple of days before we could start looking at it, but that was only the test version. We had the accelerator pack where we deployed and onboarded connections to Entra ID, to a business application, and to the HR system, importing the HR data and getting the right data from HR. They take 12 weeks to onboard something, but the biggest delay factor is usually the HR system. I am still waiting to see an HR system that delivers correct data in the first go. 

Deploying Omada is highly complex. We work in finance. It requires a high level of control because of regulatory compliance. When it was installed, we ran an executable and had to follow up with it. 

However, it wasn't plug-and-play because we needed more control over storage. We couldn't simply provide domain admin and database owner access to a sales account. It took us almost two years before we could deploy Omada in a production environment. The deployment team consisted of about 10 to 15 people, including our infrastructure partner. 

Omada requires some ongoing maintenance. We have to do data input differences in our connected systems. It's nothing unexpected. 

The initial deployment was difficult and took over one year to complete.

Several teams came together to deploy and integrate Omada into the baseline systems required for the IGA to add value. 

The deployment took a year to complete due to the complexity of our environment. We encountered dependencies on a log server, firewall ports, and various other infrastructure elements, which significantly extended the lead time. Otherwise, it would have been a straightforward deployment.

Things went well when we finally deployed Omada. There were a few issues to iron out, but it was smooth when we went live. All in all, it was a good implementation. It took about two or three working days to complete. 

Omada requires minimal maintenance after deployment. You need to review some of the reported data, but that probably has more to do with the HR information we're fed. There are also periodic updates or things that aren't working correctly that must be fixed. Overall, you don't need to put much effort into the solution to keep it running. 

Omada is a cloud-based solution. Omada helped us deploy IGA within 12 weeks by focusing on fundamentals and best practices. From what I hear, deployment was a straightforward process, and the company completed it in a couple of weeks. We have a small IT team. Only four people are in charge of administering Omada, updating the platform, and responding to error messages. We've had some problems during patches and cloud updates, but most of our issues involve errors when importing data. 

Omada Identity has a complex setup. How long the deployment takes would depend on how you planned the installation. My best experience was when everything ran smoothly after I had been very thorough and I've taken care of requirements. If you do the planning upfront, the process of installing Omada Identity is rather quick, and you don't get errors, and deployment would take a week or so.

You need to make sure that everything works. Often, when I install the solution, there's more than one system such as the production environment, the test environment, the development environment, the education environment, etc., so planning the setup of Omada Identity takes a long time, but that's okay, and in larger organizations, you're often not alone when installing the solution.

Planning the installation of Omada Identity is mandatory because then you need to have the SQL team working on the databases, the network team handling the firewalls, the web team taking care of the information server, etc., so a lot of people are often involved in larger organizations.

Its installation is easy. You can install it over a weekend, but connecting with different parts of the organization takes time, which is applicable to all products in this area. The core installation is simple and easy, but integrations take time.

The initial setup is highly complex. Full deployment took around a year. Including preparation, planning, design, and implementation, it was about a year and three months.

The initial setup took a long time, over six months, because of our supplier. Omada said that they have an integration with CyberArk, so we wouldn't have to build anything because it was there already. We would only have to install it. Then, the supplier told us, "We have to make it," but it was already there. If it was there, I don't understand why it took so long.

The deployment is not easy. It takes too long. My colleagues always have issues after deployment.

The deployment took months to complete because our infrastructure presented challenges for Omada to integrate with. The initial deployment itself was quite complex. However, we've made significant changes to our internal infrastructure that have greatly simplified things. Omada has also made improvements that contribute to this ease of use. While the deployment was complex back then, I doubt it would be as challenging today.

Two people were involved in the deployment.

The initial setup was complex. We have so many different stakeholders in our company and they all have their specific requirements, but we were trying to standardize things. We have struggled with all the requirements and have tried to reduce the special implementations to a standard.

Our implementation of Omada took about half a year.

In terms of maintaining the solution, we have four people involved. Two are technical application managers who are in charge of the operation of the system. And we have two guys who are mainly dealing with the implementation of the employee processes, connecting to the target systems, as well as some scripting.

It is deployed on a cloud, but I was not involved in its deployment. When I joined, Omada Identity was already there for 6 months.

We have three environments. One is for development, one is for testing, and one is for production. Omada is on the cloud, so it can be used everywhere.

It does not require any maintenance from our side.

The initial setup was complex. We did it manually because I was a senior expert. Better to do it that way, because otherwise, it's hard to get it to work. It has a complex installation procedure. 

The first time I did it, it took around two weeks. But now I can do it in a couple of days.

My strategy was to follow the installation guidance. 

In terms of the installation, the initial setup of the suite and the components is very straightforward and well documented.

When it comes to the introduction of the Identity and Access processes with Omada, it can be very complex and it can also be very straightforward. It depends on the complexity of the processes that the customer demands. Omada has a best practices paper that explains how to set up various types of projects. When you follow that process, starting with some basic setup, then moving on to the improvements and continuing to roll out iteratively, I think it's very straightforward.

In terms of the time required for deployment, it again depends on the complexity of the processes that need to be integrated. You can have projects where it is fully deployed within weeks, and you can have bigger projects for bigger companies with more complex processes that can take a year or even longer to deploy.

Our implementation strategy begins with the need for a business concept. After that, we do some requirements engineering and talk about existing processes with the customer. Together, we decide what to migrate and what to introduce.

We then begin with a basic setup to introduce the first phase of the project. From that point, we use an iterative or agile approach to onboard more applications.

The complexity of the initial deployment of Omada depends on the customer. But one of the reasons we chose to become a product vendor for Omada is because of the simplicity. It's the perfect fit for a lot of customers that don't need the complexity of an Oracle, or of a CA, or even a SailPoint. That's one of the main factors that attracted us to the product.

The implementation strategy is going to depend on the customer and where they are in the process. The pre-implementation strategy is to find customers that meet what we've defined as the sweet spot of customers, where Omada is the best fit for them. They are customers that are looking for this, this, and this, they're this size, and they're at this stage in their maturity model. We like Omada for the SMB market because you can get your hands around an implementation. You can get them on the cloud version and get them up and running pretty quickly. 

If it's a customer that doesn't require a lot of complex workflows, it's a simple product to get installed and get up and running. However, it still does have the heft to be able to support some of the more complex custom configurations and workflows, if they need that in the future.

There is no such thing as an "average deployment," but 90 days would not be a stretch for getting some of our clients up and running and getting an app or two onboarded, with some pre-built-in workflows.

The number of staff required for deployment is also deployment-specific, but we'll typically have a team of between two to ten people, depending on the size of the deployment and what the customer wants to do.

Some of our legacy clients—and when I say legacy, I'm talking about two to three years ago—are using the on-prem version. Whether a client goes with the SaaS or the on-prem really depends on what the customer is looking for. A lot of customers are going for SaaS because of the "flash-to-bang." The pitch is that with one of the starter packs, you can get them up and running with a system of record in a shorter amount of time than with the on-prem version. That's typically the preference. Customers want to get up and running. They're running from an audit, they're running to meet compliance, they're running for a deadline. They typically want to go SaaS so they can get some quick wins under their belts. The on-prem takes a little bit more coordination with their onsite technical and security guys.

If you are using the provided connectors and configuration out-of-the-box, then it is straightforward. However, if you require custom connectors or configurations, that setup is can get complex. 

An average deployment takes three to six months.

Our implementation strategy varies based on the customer's requirements.

The initial setup should have been straightforward, but because of the SAP implementation at our company, it was still pretty complex. The initial step in the implementation was to hook up our SAP systems to Omada, set up the identity life cycle management and to connect the access rights for SAP systems. Our SAP systems are quite complex and had some technical depth to them, which we needed to solve via Omada, which was horrible. Even though it was a simple setup, it still became pretty complex.

We are starting the configuration stage right now. 

The initial setup has been straightforward. It is a quick setup, which is flexible and user-friendly.

Considering the scope of the project, the setup was quite straightforward.

I find the initial setup quite straightforward, however, I can imagine it being complex for some people. It can become very complex with the connections to external systems. I know of one customer here who has had very great problems with it, but another one found it a bit easier.

The main problem is going to be the amount of shoe-horning your own systems into it. That's the big problem; modeling so that everything fits.

Was complex, a lot of org implementation questions, master data issues, process workflows, too much compared to what we needed.