Have a nice fresh RT5 server with all the newest features and without all the bizarre configuration decisions made by predecessors.
Have our old tickets (thousands) available within this new server.
Here is the plan suggested to me:
Setup and and configure rt5 instance.
Export (mysql dump) new rt5 instance database (“rt5newdb”).
Import (via mysql) old RT database with old tickets (“rt5olddb”), replacing rt5newdb.
Run make upgrade-database and then confirm rt5olddb is working on new server.
SQL dump out the “tables that only held relevant ticket data” (“rt5oldticketsdb”)
Reimport the entire rt5newdb database.
Import the rt5oldticketsdb (containing only “relevant ticket data”) on top of the rt5newdb database.
To me, determining which of the many tables “hold relevant ticket data” is the tricky part as that seems wider-spread than you’d initially think. And what will then be necessary to bring over (users, queues, attachments) would then potentially conflict with goal #1 above. And I’ve read many threads here and elsewhere that caution against these types of procedures.
However, I don’t want to prejudice any responses. I would, however, like a different perspective on this than my own and my colleague’s. It’s ultimately up to me but I want to fairly consider the plan above before I shy away from it based on vague warnings I’ve read around the interwebs.
–B
P.S. Would rt_serializer and rt_importer be a better/saner option?
When you say “relevant ticket data” do you mean not only the ticket history, but attachments, custom fields, queues, ACLs, groups, roles, and users? It might be easier for you to consider tables that aren’t directly ticket related instead, such as Articles, Templates and Scrips, as I suspect there’a a lot fewer of those in RT. RT is based around tickets, ticket workflows and ticket management so most if it is relevant to tickets.
We faced the same issue when pulling up from 4.4.1 to 4.4.7 and the preparation of rt5 in the future.
Our RT started in 2002 and there are a lot of things nobody knows any more.
First we wanted to proceed the same way you describe: start with a nice, plain RT(5). We decided this way not valid because it takes too much ressources at one time to bring up the new RT with alle required configuration, migrate the data and fix remaining errors.
Another reason is very much tables are needed to import tickets with transactions and you won’t get rid of this configuration you don’t want any more.
Then our approach was to simplify the configuration (userspace) and decrease the amount of customizations (callbacks, overlays and other source) step by step. Some before and some after the upgrade.
For cutomizations it worked very well. Nothing to tell about.
The changes in configuration showed up to be with many side-effects. We changed a set of configuration to be more simple as before and brought up other problems.To solve this problems we tuned the set of configuration as needed. In the end we found quite the same configuration as before very often. The advantage is: now we know WHY the configuration is like it is.
Of course some requirements changed and we dropped that configuration. So the new RT is much better than before.
Our learned lesson: We didn’t know the reason of some bizarrre configuration until we changed or deleted it and found user complaining about. We are very glad we didn’t do it all together.
The process of review and change the configuration based on the actual requirements is ongoing.
A special challenge at all is to migrate to the nice new features of RT that require an other configuration as before. The old configuration is valid most times but can be replaced with new and better style. One has to migrate each part.
I think that’s the rub. The old tickets are the most important to some of our staff. And yet most tables are touched by tickets. So the bringing in of those ticket-related tables “taints” the new config in undesirable ways. While leaving those tables behind renders some functionality around the old tickets diminished.
Thank you for your post. I’m considering the upgrade-in-place (though via DB transfer as a whole, as recommended) and then the gradual re-configuration to be more like the default. It may, in the end, make everyone (else) happier. Even though I’m noticing some things missing in the upgraded test instance that present on the new/model/test rt5 instance that may be difficult to replicate (conditions, actions, and dashboard doohickeys, etc.).
The part about “. . .you won’t get rid of this configuration you don’t want any more” seems like the crux of the matter for us. And, as you say, you may find later that you shouldn’t have gotten rid of it in the first place!
In some systems, due to plugins, customization, etc. that differ too much between versions, I try not to migrate data (if I’m allowed). New server → new rules.
The old one remains as a archive system with full functionality in a thinner server… some years later nobody notice that I’ve stopped it during Christmas break
The “default configuration” may not be the thing you want. For a simple example by default only priviledged users are allowed to create tickets. If you want e.g. customers to create tickets via mail you have to set the ACL “CreateTicket” to everyone globally or by queue. There are many little things like this.
Dashboards, Conditions, actions and so on represent the workflows implemented to the queues. This is the worthy part of the configuration if it provides a well customer experience to Requestors.
The missing parts you mentioned may fit to your needs or may not. If you need them it is not very hard to rebuild. The question is, do you need them? If there is an unresolved requirement you can work on solutions in a vanilla RT and transfer the configuration.
So it is one task to use the up to date system.
It is a second task to to use nice and new features, maybe replacing some configuration to get easier administration in the future.
The third task is to resolve new or unresolved requirements or improve existing solutions.
Of course starting with a whole new system and close the old one after time is a solution, too! Like @sollericos mentioned. Depends on the customizations and configurations needed. We’ve about 70 queues with ACL, SelfService, workflows and automations. It is no option to rebuild just for an upgrade.
It is your decision based on the given comlexity of the running installation =)
