I have done the second option and don't recommend it. It would have been far easier to do a complete switch over and have the old tool available as an archive for reference purposes only.

You will have to do a lot of work to close any tickets in the old system and migrate the few ones that can't be closed into the new, but it is nothing compared to the effort required to migrate the entire history from the old to the new.

We've just changed our software.
We logged all new calls on the new system and kept the old system live for closing off old calls and orders (we use our system for ordering also).
After a month we re-keyed any calls that were still being worked on and closed down the rest.

* 1)start using the new system for new calls, and carry on using the old one for existing incidents up to their closure.
* 2)at a certain date, convert all open tickets from old system to new one
* plan and arrange in advance for transfering reporting and statistical data from old system to new one on date 2) , so you don't lose visibility on your quality indicators.

My recommendation is that if you're plan is to decommission the old tool, you're almost always better off migrating all your data into the new took, quickly, and instantly shut down the old tool and start using the new tool.

Why?...

1: There is nothing about such a tool that is business critical. In other words, even if the new tool hiccups, it won't shut down your business.
2: It's expensive and time consuming to run two system, simultaneously
3: Time is critical. Getting it all done and moving on will add more value in the short term and the long term.

The key is to simply make sure that all old data is discernible in the new system, so that you can quickly recall it, when needed, and can identify it as being from the old system, very quickly and obviously.

We find that most enterprises that perform parallel runs usually regret having done so, as they usually realize with hindsight that it's not that hard to just do it right and shut down the old system, immediately.

I used to work for a company that offered a web based incident management tool, more often than not providing helpdesk services as well. With most cases client companies had to deal with their existing tool being decomissioned and data being imported, somewhat the same situation you find yourself in now. (Offering an oursourced helpdesk meant we often couldn't use the client's old tool so we had to do a fast changeover - - lots of pain was always involved.)

I'd recommend evaluating data and seeing how an import / immediate changeover scenario could be put in place. One of the difficulties we used to face was importing data from a system like Remedy to our activity-based system. While Remedy had assignments with timestamps, any updates tended to be mashed together.

If historical incidents can be imported, I don't see why open tickets cannot. Granted that while they may not be robust as incidents created from scratch in the new system, you still maintain historical data and no longer need a second live production environment.

1: There is nothing about such a tool that is business critical. In other words, even if the new tool hiccups, it won't shut down your business.
2: It's expensive and time consuming to run two system, simultaneously
3: Time is critical. Getting it all done and moving on will add more value in the short term and the long term.

The key is to simply make sure that all old data is discernible in the new system, so that you can quickly recall it, when needed, and can identify it as being from the old system, very quickly and obviously.

We find that most enterprises that perform parallel runs usually regret having done so, as they usually realize with hindsight that it's not that hard to just do it right and shut down the old system, immediately.

It's not business critical but it is time critical ! ...

A bit sarcastic I know, but there are a few contradictions in those lines.

1. If not being able to access the service desk has so little impact to the business, why even bother to migrate the old data.

2. Cost of migrating the data more than often higher than a short parallel run (a few days / weeks maybe). Data migration works well when you do an upgrade ... oh, except if you have done a few customizations.

3. As the service desk data migrated gets older, does it provide additional value? ... I'm afraid, it's not like wine.

There are cases when it is a MUST to migrate the data, but those are rare ... in the IT Service Desk space.

A bit sarcastic I know, but there are a few contradictions in those lines.

1. If not being able to access the service desk has so little impact to the business, why even bother to migrate the old data.

Who said that not being able to access the Service Desk had little or no impact on an enterprise? We're talking about the tool that the Service Desk uses, not the Service Desk, itself. In this case, all data would be migrated into the new system and instantly available. I also stipulated that it should be properly tagged so that it can be distinguished from all new data that's input into the system.

Quote:

2. Cost of migrating the data more than often higher than a short parallel run (a few days / weeks maybe). Data migration works well when you do an upgrade ... oh, except if you have done a few customizations.

The cost of migrating the data is definitely something to consider, as it requires development work to extract from the old, map to the new, and upload into the new (to oversimplify the process).

If it's ok for your enterprise to throw away old data, then go ahead and do it. However, that doesn't say much for the value of your data, does it? In most cases, enterprises will keep the older data so that they can use it as a knowledge history/base that they can look through to address future incidents that may have already been addressed in the past.

Quote:

3. As the service desk data migrated gets older, does it provide additional value? ... I'm afraid, it's not like wine.

Again, it depends on how you use it...

1: As a knowledge history
2: If you use it to drive historical trends and patterns that help manage your business(es) more effectively
3: As a way to profile your customer(s)
Etc.

Quote:

There are cases when it is a MUST to migrate the data, but those are rare ... in the IT Service Desk space.

Actually, they're not rare at all. We find that most mid-sized to larger enterprises almost always want to migrate their data. It's usually the smaller ones, the ones with little accumulated data, that will tend to walk away from the old repositories.

Quote:

Always challenge the business needs to migrate the old data.

I agree with this. However, there are definitely many times when it absolutely makes sense to do so.