OTOBO & Znuny Staging System – Migration and Secure Test Environment

A staging system is the perfect environment to safely test changes to the ticket system—whether for OTOBO or Znuny. It is an exact copy of the production system where features, configurations, and data can be migrated, tested, and validated without affecting the live system.

INFO

🗾 Compatibility: The steps described in this article apply equally to OTOBO 11.x and Znuny 6.x+. Differences in configuration files are minimal and will be noted where necessary.

---

🔄 Overview: Staging System Migration Process

1. Prepare the development system
2. Set up the staging system
3. Copy production data
4. Test the staging system
5. Deploy from staging to production (optional)

---

✅ Advantages of a Staging System

• Safe testing of configuration, custom code & packages
• Automated end-to-end tests with tools like Playwright
• GDPR-compliant testing after anonymization
• Recovery tests & backup verification

---

🛠 Prerequisites

• Ubuntu 20.04+ or Debian 10+
• Docker (recommended) or manual Linux installation
• Sufficient system resources (8 GB RAM, 4 CPUs)
• Access to current production data (DB & filesystem)
• Ability to disable email sending (e.g., via a dummy SMTP)

---

🧱 Step-by-Step Guide

1. Build the Staging System

A Docker installation is recommended:

sudo apt install docker.io docker-compose
cd /opt
git clone https://github.com/RotherOSS/otobo-docker.git --branch rel-11_0
cd otobo-docker
cp .docker_compose_env_https .env
nano .env   # Set OTOBO_DB_ROOT_PASSWORD

2. Clean Up the Dev System

If you are using a dev system as a base:

# Delete tickets and attachments
bin/otobo.Console.pl Admin::Delete::Tickets --older 1d --state closed --really
rm -rf /opt/otobo/var/article/*

---

3. Copy Production Data

# Back up the database (production system)
mysqldump -u root -p otobo > /tmp/otobo_prod.sql

# Back up articles & Kernel
rsync -avz /opt/otobo/Kernel /tmp/Kernel
rsync -avz /opt/otobo/var/article /tmp/article

Import into the staging system:

# Import DB
mysql -u root -p otobo_staging < /tmp/otobo_prod.sql

# Copy filesystem
rsync -avz /tmp/Kernel /opt/otobo/Kernel
rsync -avz /tmp/article /opt/otobo/var/article

🔐 Data Privacy: Anonymize all production customer data, e.g., in the customer_user table, or remove email addresses with an SQL script.

---

4. Adjust Configuration

# Kernel/Config.pm
$Self->{'Database'}{'Name'} = 'otobo_staging';
$Self->{'Database'}{'User'} = 'otobo';
$Self->{'Database'}{'Password'} = 'STAGING_PASSWORD';

5. Disable Email Sending

In SysConfig:

• Set SendmailModule to Kernel::System::Email::DoNotSendEmail
• Alternatively: Change the SMTP server to 127.0.0.1 and port to 1

---

🔬 Testing in Staging

• Use Playwright or Cypress scripts for UI tests
• Use bin/otobo.Console.pl Maint::Test::System
• Check data integrity & UI behavior
• Disable integrations like LDAP or web services, or redirect them to test servers

---

🔐 Securing the Staging System

• Restrict access via VPN or IP whitelist
• Set up robots.txt to prevent indexing
• Optionally, implement basic auth via Nginx
• Secure with an SSL certificate (SAN or wildcard), e.g., *.staging.example.com

---

🔄 Optional: Deploying Staging to Production

Once everything has been fully tested in staging:

1. Stop the production server
2. Copy the staging database and directories to production
3. Adjust Config.pm
4. Restart the production server

---

🧪 Example Tools for Automation

• Playwright (for E2E tests)
• rsync for fast data transfer
• docker-compose for an orchestrated environment
• cron or systemd for regular backups
• Python scripts for anonymization or structure migration

---

Conclusion

An OTOBO or Znuny staging system offers maximum security when introducing changes. Through structured migration, anonymized test data, and automated tests, you can prevent downtime and ensure stable deployments.

🔁 Tip: Integrate the staging processes into your CI/CD pipeline for automated quality assurance with every change.