From OTRS to Zammad – 50,000 Tickets Find a New Home

The transition from OTRS to Zammad is more than just a technical upgrade for many organizations – it’s a step towards a sovereign, modern, and highly available ticketing infrastructure. In this blog post, we describe in detail how we successfully migrated 50,000 tickets from a non-highly available OTRS 6 instance to a self-hosted Zammad instance running on Kubernetes.

We cover both the technical preparations and the challenges, best practices, and specific recommendations for anyone planning a similar journey.

Why Move from OTRS to Zammad?

OTRS has been a standard in the helpdesk environment for many years, but many companies are hitting the limits with OTRS 6: lack of a modern UI, limited scaling options, and often a lack of high availability. In contrast, Zammad offers:

• Modern Architecture: Rails, Websockets, Elasticsearch
• Scalability: Well-suited for containerized environments
• Community and Open Source: Vibrant development, transparent progress
• Seamless Migration: With official migrator plugins

Especially in the context of cloud-native environments and Kubernetes, Zammad showcases its strengths. With the official Helm Chart for Zammad, an instance can be quickly deployed and operated in a resilient, highly available, and scalable manner.

Initial Situation

• Legacy System: OTRS 6, single-node, no high availability
• Target System: Zammad in Kubernetes with Helm Chart, highly available
• Data Volume: approx. 50,000 tickets

The challenge: A migration of this size cannot be performed via the Zammad web interface. The UI import function is suitable for smaller volumes, but with five-digit ticket numbers, it reaches its limits.

The solution: Migration via the OTRS migrator plugin and the Zammad Rails console.

Preparing for Import

1. Prepare OTRS

To enable OTRS to provide the necessary data for Zammad, two plugins must be installed:

• Znuny4OTRS-Repo: Download
• OTRS Migration Plugin (ZammadMigrator): Download

Instructions for installing packages in OTRS can be found here: OTRS Package Manager.

After installation, OTRS provides an API interface for the migrator, which Zammad will later retrieve.

2. Prepare Zammad

Our Zammad instance is operated in Kubernetes with the Zammad Helm Chart. To start the import, we need access to the zammad-railsserver pod:

kubectl exec -it <zammad-railsserver-pod> -- /bin/bash rails c

In the opened Rails console, we configure the import parameters:

Setting.set('import_otrs_endpoint', 'https://otrs.example.com/otrs/public.pl?Action=ZammadMigrator') Setting.set('import_otrs_endpoint_key', 'API_KEY') Setting.set('import_mode', true) Setting.set('system_init_done', false)

This signals to Zammad: “The instance is fresh, not yet initialized, and we want to import data from OTRS.”

Conducting the Import

The actual import is also started in the Rails console:

Import::OTRS.start

Zammad now connects to the OTRS API and imports step by step:

• Users
• Customers
• Tickets (including articles, attachments, history)

With 50,000 tickets, this means: The database and Elasticsearch must be adequately sized.

Resource Requirements

• Elasticsearch
  • 8 Cores
  • 32 GB RAM
  • At least 50% of the RAM for the Java Heap
• PostgreSQL
  • 4 Cores
  • 16 GB RAM
  • shared_memory: at least 4 GB

These resources are not a luxury but a prerequisite for a performant migration and stable operation thereafter.

After the Import

Once the import is complete, Zammad must be taken out of import mode:

Setting.set('import_mode', false) Setting.set('system_init_done', true) Rails.cache.clear

It is then recommended to restart the zammad-init pod:

helm upgrade <release-name> zammad/zammad

The zammad-init pod takes care of the reindexing in Elasticsearch, which can take some time with larger ticket volumes. Only after this is the full search functionality available in Zammad.

Lessons Learned

1. Planning is Everything: Especially the sizing of resources determines success or frustration during migration.
2. Clean Start instead of Dirty Import: A fresh Zammad instance is the cleanest basis for an import. Attempts to import into an already productive instance usually lead to inconsistencies.
3. Keep Monitoring in View: During the import, Elasticsearch and PostgreSQL run at full capacity. Without monitoring (CPU, RAM, Disk IO), you are blind.
4. Plan Time: Importing 50,000 tickets takes – depending on hardware and data structure – several hours. This must be factored into the migration planning.

Outlook

For many organizations, the switch to Zammad is the first step towards a fully cloud-native IT service landscape. The next logical steps can be:

• Automated Backups & Disaster Recovery for PostgreSQL and Elasticsearch
• Scaling Zammad in Kubernetes via horizontal pod autoscaling
• Integration with External Systems (e.g., LDAP, SSO, Monitoring)
• Sovereign Cloud Strategies: Operation in European infrastructures, combined with Open-Source Technologies