Import tickets from multiple OTRS instances

Technical assistance
1

Hello together,

as of now, we have two OTRS 6 instances in our company. Now we want to merge both in one Zammad instance.

I tried to perform Import::OTRS.start for the first (larger) instance, then changed the endpoint url and the API key to that of the other instance and did the same. But after that, the groups and users are completely messed up (some groups from the first instance disappeared, instead the tickets from there were moved to groups from the second instance), although the group names in the second OTRS instance are completely different than in the first instance.

I already set only Ticket, TicketAttachments, Customer, CustomerUser, StateType and State as available objects in ZammadMigrator::Objects in the second instance but it still imports everything (tickets, users, groups)

Is there another easy way to import the tickets of a second OTRS instance in Zammad?

2

Sorry I thought the limitations are clear enough. I just added an addition to the migration landing page:

Migrations are only possible from one sources.
Several migration sources on one instance are not supported.

Also you may want to have a look at otrs migration specific limits again:
https://docs.zammad.org/en/latest/migration/otrs.html#limitations

Two different OTRS instances do not match each others content.
That’s technically correct but also means you’re nukeing your data very effentiately.

You’ll have to decide for one migration sources.

3

Sad to hear that it’s not possible… Are there other ways like CSV import/export?

4

You can use the Zammad-API to pump data into it if you please:
https://docs.zammad.org/en/latest/api/intro.html

In my perosnal opinion CSV and tickets and their content don’t make too much sense on a technical level.
I feel so personally especially in terms of escaping characters as you’d usually have HTML based content in your articles which may create a lot of issues in CSV.

5

We decided just to import the larger instance and move the open tickets from the smaller instance manually (around 100) by just forwarding them to the support e-mail address so that a new Zammad ticket will be created. Then we will set the customer and assigned agent manually.

As everything got messed up I started from scratch by re-installing the entire Debian VM a few days after I created this thread. After that, I imported all the tickets from the larger instance with everything finishing successful. Then I changed the settings like LDAP according to our environment and created multiple overviews (which was a lot of work), as Zammad does not migrate the OTRS queues or at least it is not possible to only list a ticket of a specific sub-group. I solved that by creating multiple overviews with just the open tickets from a specific group.

Two weeks later, after all the work was completed, i wanted to perform a final differential import of the tickets from the last two weeks so that we finally move from OTRS to Zammad on Monday. But I failed.

I used this commands (i masked our true fqdn for data security reasons)

Setting.set(‘import_otrs_endpoint’, ‘https://fqdn/otrs/public.pl?Action=ZammadMigrator’)
Setting.set(‘import_otrs_endpoint_key’, ‘JB3HsnHJQDDszbOmlwuWiOg0qnB9C8spKJej6vaD’)
Setting.set(‘import_mode’, true)
Setting.set(‘system_init_done’, false)
Import::OTRS.diff_worker

After that, i got the following messages:

irb(main):002:0> Import::OTRS.diff_worker
thread#-: Start diff…
thread#-: loading State…
thread#-: POST: https://fqdn/otrs/public.pl?Action=ZammadMigrator
thread#-: PARAMS: {:Subaction=>“Export”, :Object=>“State”, :Limit=>“”, :Offset=>“”, :Diff=>0, :Action=>“ZammadMigrator”, :Key=>“JB3HsnHJQDDszbOmlwuWiOg0qnB9C8spKJej6vaD”}
thread#-: ERROR: #<Net::HTTPFatalError: 503 “Service Unavailable”>
thread#-: POST: https://fqdn/otrs/public.pl?Action=ZammadMigrator
thread#-: PARAMS: {:Subaction=>“Export”, :Object=>“State”, :Limit=>“”, :Offset=>“”, :Diff=>0, :Action=>“ZammadMigrator”, :Key=>“JB3HsnHJQDDszbOmlwuWiOg0qnB9C8spKJej6vaD”}
thread#-: ERROR: #<Net::HTTPFatalError: 503 “Service Unavailable”>
thread#-: POST: https://fqdn/otrs/public.pl?Action=ZammadMigrator
thread#-: PARAMS: {:Subaction=>“Export”, :Object=>“State”, :Limit=>“”, :Offset=>“”, :Diff=>0, :Action=>“ZammadMigrator”, :Key=>“JB3HsnHJQDDszbOmlwuWiOg0qnB9C8spKJej6vaD”}
thread#-: ERROR: #<Net::HTTPFatalError: 503 “Service Unavailable”>
Traceback (most recent call last):
11: from (irb):1
10: from (irb):2:in rescue in irb_binding' 9: from lib/import/otrs/diff.rb:11:in diff_worker’
8: from lib/import/otrs/diff.rb:36:in diff' 7: from lib/import/otrs.rb:148:in updateable_objects’
6: from lib/import/otrs.rb:58:in import' 5: from lib/import/otrs.rb:129:in import_action’
4: from lib/import/otrs/requester.rb:37:in load' 3: from lib/import/otrs/requester.rb:82:in request_result’
2: from lib/import/otrs/requester.rb:95:in request_json' 1: from lib/import/otrs/requester.rb:135:in post’
RuntimeError (Zammad Migrator returned an error)

When I type in https://fqdn/otrs/public.pl?Action=ZammadMigrator;Key=JB3HsnHJQDDszbOmlwuWiOg0qnB9C8spKJej6vaD in the browser I can reach it without problems

{“Success”:1,“Notice”:“zammad migrator 1.0”}

I can ping the OTRS FQDN from the Zammad VM too and get a response. So there are no connection issues.

Any advice?

6

Look into your OTRS systems log files and check why there’s an HTTP/503 returned?
If I’d had to guess: You changed data that is being migrated and thus created a fuck up.

7

No i changed exactly nothing.

There’s no 503 entry in the OTRS syslog.

8

HTTP/503 originates from your webserver.

9

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.