Migrate Mail Tickets from Zammad Instance to Zammad Instance

[salbeira]

Infos:

• Used Zammad version: 6.3.1 and 6.5.0
• Used Zammad installation type: Ansible Galaxy (?) and docker-compose
• Operating system: Debian (I guess?)
• Browser + version: Irrelevant

We are a small club using Zammad as our Mail management system and archive.
We have an old(er) Zammad instance running on a server that we want to put out of its misery. We already created a new Zammad instance on a new server, configured it and attached it to our new mail system. We THEN realised that there is no simple “Export all Tickets” “Import all Tickets” button. We do not use the ticketing system for anything other than receiving and sending mails.

Because the new Zammad instance is already in use we can not simply overwrite the new database with the old database dump. As such I want to use the Zammad API to fetch the tickets from the old instance and recreate all tickets on the new instance.

Testing and tinkering around with the API and reading the Docs I managed to copy a relevant email with all mail attachments successfully, but the ticket is still created “at the moment of creation” and is created “by me” (or the user whose API key I misuse for testing).

I would love to just recreate all tickes as they are with their history from when they were created in the old system. I read that I need to activate some “import” mode from issues dating a couple years back in order to be able to specify the creation date via the API.

Can you give me some hints what else is required to accomplish my goal?
Some other things I mentioned while tinkering around:

The tickets from the old instance come with a buttload of “ids” attached to them. The ids of the users who created them obviously do not match the ids of the users in the new system, yet I can of course also just “fetch and send” all the users beforehand via the API, yet what is the best way to connect the old user ids with the new user ids?

What are ALL the possible fields a ticket can have on creation via the API? I can only find small examples but a complete list of specifiable fields and what they do I can not find. Maybe I missed some entry in the docs?

What are all the fields I should probably REMOVE from the returned ticket JSON in order to not confuse the new system?

Any help is appreciated. Is there already a “migrator” script anywhere maybe? I can not use the “backup” script in the railsserver container because it is missing several files and the postgres database is unconfigured, yet somehow still works in the productive system. No idea what is going on there, I am simply taking over an IT system stapled together into another IT system I now staple together, there is barely any documentation in how our old system grew over time.

[salbeira]

Because almost no solutions to these problems are ever posted here:

This is my “fuck around and find out” script I jumbled together: A simple script you can tinker around yourself and just run with node without any dependencies:

https://pastebin.com/s5GqE4T3

Some issues I came across and just brute force handled:

1. If a user once was part of a privileged group (aka. “IT@club”) and created tickets as them, even though I was creating the tickets in the new system with a fully enabled admin access token, I got either a “Can not create ticket with owner former_owner_id” or a 403: Not Authenticated error.

Thats why the script just assigns those tickets and articles to user 3, which is our admin user. I tried around a lot to fix this but I couldn’t be bothered to find any real solution to this: As an Admin User Access Token I should NEVER get a “You can’t do this!” if I create a ticket in “import mode” cause I am replicating History: Of course some things do no longer make semantic sense!

2. Similarly, sometimes I got back a 422: Semantic error when someone actually used the “Mentioning” feature in a Ticket and I got a “A mentioned user has no access to this Ticket” error: Same as above: I KNOW and WHO CARES?

3. I got some “Unknown State: 5” errors which seemed to be “Merged” Tickets, so I can just ignore them, though it is weird the “Merged” State can not be assigned on creation.

4. I got some “Unknown State: 7” errors which seem to be “Closed by missed Pending Close Timeout”? At least the only user in our system who ever used that feature owned these tickets so I just threw away the 2 - 3 tickets that had this state manually.