Basically, I need to know if there is an officially supported migration path to go from SD 4.5 to Service Manager. Or will we have to start from a clean install and rebuild all our data? Can anybody answer this?
I signed up for that online course in your link. I'm about half way through it. Thanks for the link.
1) It only migrates some data 2) Has various problems (localized data, custom fields, etc) 3) Does NOT migrate ANY logic and thus all the logic has to be re-implemented(!) 4) All the integrations have to be re-implemented as there is no backward compatibility at all. 5) The complexity of administration is incomparable to SD - it is a programming task complicated by next points: 6) It is 20 year old legacy code with cryptic language 7) It's storing data in database but not having stored relations between objects as foreign keys in tables. For example there are 2 clobs containing pairs of variable names and their respective values. The representation is like first line of first clob contains variable name, first line of second clob contains that variable's value. There are no primary keys AFAIK - they just use names...
One more thing that complicates SM maintenance beyond anything imaginable in ServiceDesk:
Due to not having relations stored as database keys it gets very complicated to do things like:
A) rename a field (for example rename one of the Status entries) B) add new item into list (for example new Status) C) remove item from the list
In ServiceDesk you just opened Administration Console and did eny of these without much of a problem:
A) not much could happen here- except maybe some integration that relied on the old text could stop working B) again - not much of a possible problems - the worst thing would be that existing rules not written properly could start on catching this new item C) SD would stop you if things relied on the item preventing you from creating inconsistent state
Now in SM everything gets referenced by its name. So any of the aforementioned changes could break existing flows and you have no tool to find out where it is referenced (what logic/scripts) which makes it hard to implement any such thing without side effects. With every patch any such change has to be re-done and its side effects re-investigated again which makes it very complicated to maintain.
The bugs might be worked out a 4.x to 5.x "upgrade", but OVSD 5.1 itself still remains a study in negligence and incompetance. If anyone suggests you even consider OVSD 5.1, have security escort them to the door.
SM7? Only if you put a gun to my head. I have no confidence that the team responsible for OVSD 5.1 has the competance to unify the design philosophies of two different tools. And lets be honest here... "migration" is a completely shady way to be describing a 4.5 to SM7 move. Its a re-implementation, pure and simple. A re-implmentation that's going to cost you stupid amounts of money, make your current admin skill set obsolete, and comes with ZERO documentation.
If that's not enough, start asking some old Service Center folks to describe the delicate balance between customization and supportability of the tool. No good news there either. The message I got was loud and clear: Customize to your hearts content as long as you don't want patches or upgrades.
I do not think there is SD 5.x (or 4.5) team involved with SM 7 at all. SM 7 is the same thing as Peregrine SC and few SD-like features (templates, views, etc.) cannot change the fact. I agree that 5.x has been a disaster in all aspects you describe. However I strongly believe that SD 4.5 code base is stable, mature and could be a foundation of something far better than SM7 is ever going to be. I am thinking of starting a petition to HP for open-sourcing SD once they stop supporting it.
In some point everyone will has to discontinue using ServiceDesk unless HP open-sources it and someone else steps in to support it and adding new features (I would), etc. Contact your HP representatives and have them create you an offer for SM "upgrade" that would retain all existing functionality. Ask them to provide cost for maintaining it to free yourself from all the inefficiencies I described. Than you'll have a clear understanding what it's TCO is (maybe comparing to investments to ServiceDesk).