Migrating to OTRS/Znuny from … a mess/anything. Where to start?

Moderator: crythias

Post Reply
FLux
Znuny newbie
Posts: 2
Joined: 19 Jun 2021, 09:51
Znuny Version: 6.0.32
Real Name: Zacharias Korsalka

Migrating to OTRS/Znuny from … a mess/anything. Where to start?

Post by FLux »

I dwell in the sphere of non-profit-organisations and I have been working on (procederes for) compiling and distilling data in what you could call “tickets” (and lists of users etc.), with the goal to get all this into an actual ticket-system to replace the various home-made solutions they use currently, which are – there is no sugar-coating it – a complete mess.

OTRS/Znuny is now “it”, and the best way, of course, would be to pay some professionals to do the migration, but this cannot be done, so … what is the best vector(s) of attack to migrate a mess of data to OTRS/Znuny myself? The situation presents itself as follows:

0) I successfully installed OTRS/Znuny on a Debian machine, from the system's repositories, for testing.
1) I have lists of users, agents, tickets complete with entries (“articles”) and timestamps and everything as Python-data (can also be made available as JSON within a heartbeat, of course), compiled from various sources and home-brew-systems via scripts, which was a lot of work, but now I have something I can use with ease. This data will only need to be imported once once the switch is to be made.
1.1) To just leave all that data alone and start with a blank slate is not an option, the “old” data has to be imported, with the proper timestamps and everything.
2) Users (“customer-users” in OTRS-lingo) will be sent to the machine running OTRS as spreadsheet-documents from time to time (as I said: a mess…), data which can be handled by scripts without problems, however, this also means I will need a mechanism to update customer-users via a script. There is unfortunately no other way. (Did I mention the whole thing is a mess?)
2.1) Customer-users have a “project” assigned to them (think of it as a department or a cost-unit) which can change on a daily basis, which is of course also a part of the data that has to be updated via scripts.
3) Tickets and articles of tickets must preserve the project a customer-user belonged to at the time the ticket/article was created, so if “Jane Doe” belonged to project Alpha on the 1. of January, and got reassigned to project Beta on the 2., any article or ticket from the 1. must show the information that she belonged to project Alpha at the time of the call.

And here I sit like a hungry child in front of a baked elephant (OTRS), so the whole thing is a little overwhelming, but I need to start somewhere chewing through it, so here are my questions:

• What is the right general way to get data into the ticket-system? Personally, I have gone through OTRS-6' database schema, and writing into the database directly is something that does not scare me to death. However, I have read that one should never ever write into the databases – what now? What is the correct way for a script way to get data into this system? I found things like otrs.Console.pl, but it is rather limited.
• How do I handle the requirement to preserve project-information at the time of the creation of the respective ticket/article? I read that I need to create a dynamic field for the customer-user, and then one for articles and tickets and write a plugin that just copies the respective data at the respective event.

Sorry this being so long, and I really wish certain people would have used OTRS-CE from the get go, but I hope to one day create a tutorial how to migrate to OTRS/Znuny from … well, from basically anything, in the hope that it dramatically lowers the bar for just dumping your old home-brew stuff in favour of something built by professionals and widen the customer base of the community edition even more.

Best regards, … a … useful idiot, I suppose?
skullz
Znuny superhero
Posts: 618
Joined: 24 Feb 2012, 03:58
Znuny Version: LTS and Features
Real Name: Mo Azfar
Location: Kuala Lumpur, MY
Contact:

Re: Migrating to OTRS/Znuny from … a mess/anything. Where to start?

Post by skullz »

FLux wrote: 19 Jun 2021, 13:28
1) I have lists of users, agents, tickets complete with entries (“articles”) and timestamps and everything as Python-data (can also be made available as JSON within a heartbeat, of course), compiled from various sources and home-brew-systems via scripts, which was a lot of work, but now I have something I can use with ease. This data will only need to be imported once once the switch is to be made.

1.1) To just leave all that data alone and start with a blank slate is not an option, the “old” data has to be imported, with the proper timestamps and everything.

2) Users (“customer-users” in OTRS-lingo) will be sent to the machine running OTRS as spreadsheet-documents from time to time (as I said: a mess…), data which can be handled by scripts without problems, however, this also means I will need a mechanism to update customer-users via a script. There is unfortunately no other way. (Did I mention the whole thing is a mess?)
a) For ticketing, you can use generic interface / webservices for this (https://doc.znuny.org/doc/manual/admin/ ... rface.html)..
or using the developer api instead (https://doc.znuny.org/doc/api/otrs/6.0/ ... et.pm.html)

b) For users (customer user), agent, do check https://opar.perl-services.de/ what available addon in there.

Additionally, do check available command (Admin::CustomerUser::Add, Admin::User::Add, etc..) via /opt/otrs/bin/otrs.Console.pl..
Write a script..read a csv contains agent/customer info..then pipe it to the otrs.Console.pl

Or better, if you have a active directory / LDAP ..

FLux wrote: 19 Jun 2021, 13:28
2.1) Customer-users have a “project” assigned to them (think of it as a department or a cost-unit) which can change on a daily basis, which is of course also a part of the data that has to be updated via scripts.
Generally, its depends on how you want to define a project..e.g: a process ticket / config item ?
FLux wrote: 19 Jun 2021, 13:28 3) Tickets and articles of tickets must preserve the project a customer-user belonged to at the time the ticket/article was created, so if “Jane Doe” belonged to project Alpha on the 1. of January, and got reassigned to project Beta on the 2., any article or ticket from the 1. must show the information that she belonged to project Alpha at the time of the call.

And here I sit like a hungry child in front of a baked elephant (OTRS), so the whole thing is a little overwhelming, but I need to start somewhere chewing through it, so here are my questions:

• What is the right general way to get data into the ticket-system? Personally, I have gone through OTRS-6' database schema, and writing into the database directly is something that does not scare me to death. However, I have read that one should never ever write into the databases – what now? What is the correct way for a script way to get data into this system? I found things like otrs.Console.pl, but it is rather limited.
• How do I handle the requirement to preserve project-information at the time of the creation of the respective ticket/article? I read that I need to create a dynamic field for the customer-user, and then one for articles and tickets and write a plugin that just copies the respective data at the respective event.

Sorry this being so long, and I really wish certain people would have used OTRS-CE from the get go, but I hope to one day create a tutorial how to migrate to OTRS/Znuny from … well, from basically anything, in the hope that it dramatically lowers the bar for just dumping your old home-brew stuff in favour of something built by professionals and widen the customer base of the community edition even more.

Best regards, … a … useful idiot, I suppose?
When writing to otrs via webservices / otrs.Console.pl, the timestamp will follow the current timestamp..
And you write, to tackle this, use the dynamic field..

The question is, is your users ready for the changes ? because definitely old data from another system wont be the same as new data.

Example: Searching for the ticket based on creation date
New ticket: use ticket create date filter
Imported Old ticket: use ticket dynamic field

Another super user here may shed some more light on this /different approach.
Im just 'text mumbling' here to get through country FMCO here..
Good luck there :)
FLux
Znuny newbie
Posts: 2
Joined: 19 Jun 2021, 09:51
Znuny Version: 6.0.32
Real Name: Zacharias Korsalka

Re: Migrating to OTRS/Znuny from … a mess/anything. Where to start?

Post by FLux »

For that reason, I decided to write into the TS' databases directly. This was not a road without bumps, given the fact that it has been … OH BLOODY HELL IT HAS BEEN DECADES! … since I last worked with SQL-databases, but given the level of modifications I need to make there is no other way. Have already learned a valuable lesson, which is, to clear the TS' cache after doing work on the database.

Code: Select all

su -c "/usr/share/otrs/bin/otrs.Console.pl Maint::Cache::Delete" -s /bin/bash otrs
The devil is in the details.
Post Reply