Migrating from Casetracker to Request Tracker

As we move from Casetracker to Request Tracker as our request tracking system, it’s important to note that Request Tracker is a much more feature-rich and customizable system than Casetracker. However, this also means that migration will not be transparent, and Category owners will need to make certain decisions on how to map current work and Casetracker configurations into the new Request Tracker (RT) environment. You will need to think about your current Category and Subcategory structure, as well as the fields you currently use to manage and track your work. Request Tracker aims to support a much more diverse set of customers than Casetracker, and many things that were global settings in Casetracker, such as software and platform fields, are fully customizable in Request Tracker.

This document describes some key differences between Casetracker and RT. Following the key differences is a decision checklist to help you determine how to migrate your Category to RT. The RT development team will also assist you in this process. We hope to make this as painless a process as possible, but you understand your work and the way you use Casetracker better than anyone else, so we will need your help.

Terms

First, some of the terminology in RT is different from Casetracker. Changes in the basic terms are:

Casetracker term	RT term
Case	Ticket
Category*	Queue
Client	Requestor

A glossary of RT terms and Casetracker equivalents is available on the RT project notebook.

Key differences

Fields

RT has the functionality to allow custom fields on a per Queue basis which was not possible in Casetracker. This opens up possibilities to customize queues to better fit the needs of each category owner. For example, some category owners have subcategories in Casetracker that would be better handled as choices in custom fields, as a way of organizing Tickets. Other category owners may need to track unique data not needed by other categories.

*Categories

In Casetracker, the category/subcategory functionality has been used to serve two purposes:

Organize cases by topic, e.g., Service Desk: Email, Service Desk: Spam, Service Desk: Passwords

Organize cases by ownership, e.g., Service Desk: Contact Center, Service Desk: Security Response, Service Desk: Dispatch Team

As mentioned above, the custom field functionality can replace the Category/Subcategory solution. As part of the migration to RT, you’ll need to give some thought as to how your Category/Subcategories should be converted to RT to best serve your needs.

Some guidelines are:

If your Category/Subcategory structure in Casetracker is your way of organizing tickets by topic, in RT you could accomplish this with one queue and one or more custom fields with topic values.

If you’re using the Category/Subcategory structure to organize cases by ownership, or a mix of ownership and topic, in RT, you could have a queue for each ownership group, and custom fields within each Queue to organize tickets by topic.
If you have unique access requirements for tickets, you would probably need one Queue per access group.

If you require sets of custom fields associated with different sets of tickets, you could have more than one Queue, each with the relevant custom field(s).

Examples

Below is a list of examples of converting Categories/Subcategories into RT.

Casetracker Category/Subcategories	RT queue(s)/custom field(s)
Example 1
Category: Service Desk	Queue: Service Desk
Example 2
Category: Service Desk Subcategories: Email Passwords Spam	Queue: Service Desk Custom field called “Topic” with values: Email Passwords Spam and any additional values identified. More custom fields can be added.
Example 3
Category: Service Desk Subcategories: Contact Center Dispatch Security Response	Queue: Service Desk:: Contact Center Queue: Service Desk::Dispatch Queue: Service Desk::Security Response In addition, custom fields could be added to any of these Queues, if the need for organizing by topic is identified.
Example 4
Category: Service Desk Subcategories: Email Contact Center Dispatch Passwords Security Response Spam	Queue: Service Desk::Contact Center Queue: Service Desk::Dispatch Queue: Service Desk::Security Response A custom field called “Topic” with values: Email Passwords Spam could be created and stored either: -under one or more of the converted queues, if these topics relate to one of them according to the guidelines given above. or under a fourth, new Queue that emerges during the decision making process. or both.

Decision checklist

What queue or queues do you anticipate needing for your work in Request Tracker? Keeping in mind the differences between Queues and Categories, you may end up with a Queue for some or all of your current Casetracker Categories and Subcategories. We are planning to use the naming convention of a double colon if you need to create a pseudo-hierarchy, i.e., Service Center::Dispatch, Service Center::Security Team, and so on.

For each queue, please let us know if you will have a separate group of people working on it, if there are unique requirements for the tickets in that Queue, or if you have some other reason for wanting it separate from your other Queues.

Your planned queues:

What custom fields do you think you will want initially to categorize tickets by topic or track other data important to your work? Examples of custom fields are: Topic, Software, OS, Platform, Account number, Type of problem, etc.

Your ideas for custom fields in your queues:

Time constraints: Please let us know if you have specific requirements for when you can or cannot deal with a migration from Casetracker to Request Tracker. We will try to meet with each Category owner to discuss the migration, if needed.