It’s cold, grey and wet here in the Northeast today, and I keep hearing a Johnny Cash song in my head:
“I’m stuck in Folsom Prison, and time keeps dragging on”
The singer didn’t want to be in jail, but the life choices he made forced the situation:
“But I know I had it coming, I know I can’t be free”
So, let’s pull this ball and chain metaphor back around to IT Service Management. As I’ve been advocating in some of my earlier writings, you shouldn’t let yourself become too stale when it comes to software packages. We all know the mantra, right? New software has more current generation features, less bugs, more opportunities for automation, fewer security issues, etc. This should serve as the impetus to keep you evolving along with the field, staying relatively close to the peak (and not the bleading edge) of the software curve. And, as previously said, if you use Ivanti products, upgrading is relatively painless in the financial dimension. Yes, it’s time to say goodbye to HEAT Classic, ITSM 6, ITSM 7 or any version of Ivanti Service Manager before 2017. Your users will love you, as will your upper management.
Now, what happens to the data within the old system? There are certain industries where this data is required to be held for several years time, just in case of delayed audits or (heaven forbid) legal inquiry. Other agencies use old tickets as a form of uncurated Knowledge Base – one where you glean what you can from tickets past. Sadly, there are organizations that use old ticket data as an makeshift Configuration Database. I’m asked by most of my upgrade clients whether ISM has a way of importing old ticket data. The truthful answer is “yes, but why would you want to go down that path?”
“…my Mama told me, “Son, Always be a good boy…”
Experience has demonstrated to me that migrating tickets from an older Ivanti product can take up to 50 (yes, fifty) additional hours of work. And not only does this keep your consultant from working on setting up new features, the migration (once complete) now fills your database with scads of old tickets. That’s more ancient data to be searched when you look for answers. It’s more time to wait as your dashboards get populated. It is more data to exclude when you run reports. This is the moment of soul searching right here. Are you going to already put a ball and chain on your new system just in case something bad happens down the road? Remember, nobody tells you to delete the old databases. If you need to run reports off of the data, your Crystal and SSRS Reports will always work even if you no longer have the application up and running.
My suggestion? If you are not confident with just keeping the DB around (off-line or possibly backed up onto archive media), then build a pair of virtual hosts, one with a SQL server on it. Move your old data onto the virtual with the SQL server, and then move the application onto the other host. Once you’re now in a virtual setting, declare that on one day, the old system will be taken down. And then power off the virtuals. If an auditor (or worse, lawyer) comes calling, you can always power them up and your data is still there, the same as it was when it was taken off-line.
“Far from Folsom Prison, that’s where I want to stay”
It seems to me that it is always a well-meaning management decision to keep old ticket data available for instantaneous query. Keep in mind that Management is rarely in the trenches where Support is answering the calls. Tickets more than 1 year old more than likely contain stale, outdated information. The stuff you would not want to point a brand new analyst to in order to solve a problem. And Management never really understands how rapidly mobile your support world is when it comes to configurations. Using anything other than a proper CMDB for “current state” data is a mistake for all involved.
When you leave that old UI behind, leave the data with it. Everyone will thank you for it.
-Jeffrey Bromberger, Consultant – CISA, CRISC
Contact the consulting team at consultants@dataseti.com
Find us on dataseti.com or read us on dataseti.blog.
Follow us on LinkedIn, Facebook and Twitter!