I think the only issue we've had is our recent upgrade to Geneva went a little wonky. But I think that was partially our fault. We had gotten a little bit behind on patching Fuji and then jumped to Geneva Patch 5. I think there was items missed. Even though it should have been cumulative, I think we had some items that were missed in there.

The other issue we had is when we deployed ServiceNow, we started with domain separation. Mostly because the consulting company we used said that's the only way to do it. It probably shouldn't have been done, but that's not a reflection of the product as much as the consultants we used at the time.

My first instance was a June 2011 instance, and upgrading was a nightmare from that point. It got progressively better. Right now it is flawless, and it takes very little effort to do an upgrade, but getting to that point has been very very difficult. That's probably one of the other things that would be nice for ServiceNow to give us the ability to sort of see all the things that we have changed. Not in the middle of the upgrade, but just ahead of it, so you can try to knock those things out.

Deployment, no. I don't think it's really deployment, I think it's more of individuals just getting used to if they're not used to something like ServiceNow. Getting used to the way that ServiceNow works. The concept of ServiceNow users and just getting to understand "Can you have notifications for this?" or "Do you want notifications for this?" Those types of things. I think it's hard when users are going through change whenever to modify something and then they take that grace period where they can get used to something new.

There were issues deploying Fuji, but not after that.

Deployment issues were very rare in all projects that had a dedicated ServiceNow Development lead (with a team of Dev and DB skilled staff assigned to the project) involved as a team member with the combined process owners in Rapid Process Design workshops. These workshops involve more than five process owners designing each other's new processes, based on ServiceNow out-of-the-box requirements, guided by the Dev lead and the ITSM expert facilitator (a seasoned facilitator with ITIL Expert certification and ServiceNow bootcamp credentials is recommended).

This approach ensures all process owners and the tool design expert understand the complex integration points between all processes; a key to CMDB relationship requirements insight.

There were no issues with the deployment.

Deployment through Update Sets can be challenging at first but after some practice they become easy as a breeze.

The point is, when you do heavy customization, it takes some time to upgrade. But that's not ServiceNow's fault, because sometimes you need a special feature, or something implemented in a special way, and they just need to keep track of that every time you upgrade. But usually it's not that complicated, just review it. The new features in Helsinki are great when you have this nice overview. You review the feature, then you call ServiceNow, and you're done. The rest works seamlessly.

One of our partners is the technical guy, he's developing now on the development instance.

I wasn't really involved in the installation of it. I'm more on the admin side so I can't really speak to that.

There were no issues with the deployment.

In fact, it solved a lot of those issues for us, because our Remedy implementation was all on-prem, so we had database servers we had to update, we had Tomcat servers. We had every other kind of thing, and not enough staff to run them, and so it really was an effort whenever we had to bring a service outage back that we didn't know sort of what was happening. Same thing with upgrades. You had to coordinate several people, and it was a lot of effort, whereas now it's literally just, "Hey, we need to do a patch this weekend, so let change know that we're doing a patch," and in the morning the patch would be there, and so from our standpoint, that was really the biggest thing, is that we haven't seen the issues now that we saw previously. As far as implementation, uptime, we really haven't had any problems.

It is usually user error rather than system error, and even on the largest deployment that I took part in, that was muddled by an inexperienced admin. I was able to back out and fix within a two hour span of time.

Implementation is always a little rough, but once you have everything up and running the only thing you really have to worry about are the ways in which you modify things so there won’t be any conflicts during future version updates.

The only bugs are related to the configuration, not from the ServiceNow side, but from the partners that are doing something because they don't understand how it works.

Everything is fine for me.

There were no issues with the deployment.

They had suggestions for how we could do certain things, and I guess what I was expecting was ServiceNow to push - since ServiceNow can do so much. I can code it to do anything that I want, and so the issue was that they should have pushed back more and said, well, that really isn't how you should do it, you should do it this way. It was more, "OK that sounds good" and they let us do something that we shouldn't have done, and then it bit us, so we ended up having to come back and we ended up doing basically our own home-grown SDLC process in the system through requests, and we're on version 3.25 of that. It just took us three months longer than it did to implement change. It was a struggle.

No issues encountered.

No issues encountered.

There were no issues with the deployment.

There have been no issues with the deployment.

No issues encountered.

We encountered no issues with deployment.

There were no issues with the deployment, but some were encountered during upgrades.

No.

Deployment is specific to us because we have an on-premise installation. We have different servers and different security zones. The out-of-the-box functionality to retrieve an updates ad, for example, it's very nice and easy to use. It's okay, but if you're in different security zones in your infrastructure, then it's a little bit harder. It depends on how the developer know ServiceNow and how the process is defined. It's not a problem of ServiceNow.

There were no issues with the deployment.

No, deployment is very smooth and your production instance will be up and running in no time.