1 of 1 people found this helpful
Here's the thing with migrating data.. FROM any system... TO any system...
First thing.. It's expensive. Why? Because it is time-consuming. Why? Because what a lot of people fail to realize is... it's not just about importing data. You need to export the data.. you need to massage/update/replace the data.. then and only then can you import the data. The bulk of the time is spent on steps 1 and 2. Step 3, importing, is generally quick and painless.
I recently wrote this, and while it does not strictly apply here, there is some good information: Import issues? You can do it manually!
In the ideal world, you always want to bring your data over. But the question you need to ask is.. is the data worth the money you'll spend to bring it over?
A few things to keep in mind:
1) Generally, attachments are not brought over. Each tool stores attachments in their own ways and its hard or impossible to export attachments, and in the case of all the tools I've worked with.. there is no (supported) mechanism to import attachments.
2) Generally, the tickets are brought over in their current state. Historical information about the ticket is generally excluded. At least, in my opinion. This is primarily due to cost. Now full disclosure FootPrints does not support importing historical information, but I've done it a few times manually in the database (refer to the article I posted above).
3) Data can be lost. Things such as people and categories change or are removed. Sometimes you can't load this in the new system without loading people who no longer exist (and you generally don't want to do that).
4) It might be worth to limit data loading to certain modules (ie: if you have a good knowledge base, why bother bringing closed incidents over?) or to certain states (ie: only open incidents, not closed ones) or certain time frame (ie: tickets within the last year). The last one, generally so that some reports in the new system will have data to report against.
5) Your old system - assuming on-premise - does not have to go away. You own those licences, so you can keep the old system in a read-only state for a while. Once you feel you don't need it anymore, archive it and get rid of it.
6) I always recommend doing data export and data manipulation at the same time. If the source is an SQL database, it's easy (but time-consuming). Write your SQL query to handle your data manipulation at the same time. Generally by using CASE statements. This way your data manipulation is automatic and easily reproducible, and you don't spend hours or days manually fixing data... only to have to do it again days or weeks later when it's time to go-live.
Finally... If you've read all the above and moving the data is important to you... and you don't have experience doing this. Reach out to someone who has. Professional Services are worth a lot in this area.
We were in a similar situation when implementing Footprints from an older tool. Our license was going to expire on that system and lock us out, we we'd have the SQL data, but no easy interface to view it later.
What I did was create a second workspace in footprints as an archive, and built it to match the fields of our old system. Nothing too complicated- just a bunch of text fields to ensure dates, links, etc from the old system came over. One thing I did need to do was create an "Original Ticket Number" field, since the Footprints ticket number would not match what our old system was. By doing it this way, I didn't need to worry about making old data match the new architecture and instead simply captured as is for future reference.
Once this was imported I gave our agents read only access to it, and since have only used our real workspace for production.