Migrate from OTRS to Znuny: what the move involves and who does it
Znuny is a GPL v3 continuation of OTRS Community Edition 6.0.30, so an existing Community Edition 6 installation can usually move to it in place. The move is an upgrade path plus a data and integration project, not a simple export. Whether the trigger is a renewal, a licensing change or an unpatched Community Edition 6 install, the work starts with an inventory of what the instance actually does. The upgrade path is stepwise: Znuny 6.5 accepts updates only from 6.4, so older installations need intermediate steps first. Confirm your exact version and the required sequence in the Znuny documentation before you plan dates.
Internal platform or IT teams usually own this work, often with an outside implementation partner for the upgrade sequence, custom code review and database decisions. Your team needs Linux and Perl administration skills, Apache and mod_perl2 configuration knowledge and a database administrator for the engine you choose. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, and that choice affects backups, replication and the skills you must keep in house. Add-on packages and custom code are the main unknowns. Each one needs a compatibility check against the target version, and some will need rewriting or removal.
Effort is driven mainly by the number of add-ons, custom templates and scripts, integrations with email, directory services and monitoring, and the volume of ticket history you keep. Run the full upgrade sequence on a copy of production first, using a restored database and attachments, and time each step so you know the real cutover window. Keep a verified backup before every step so you can roll back. Ask any outside partner for a written scope that lists the steps, environments, test cases and the person who signs off on cutover. Then check that plan against your renewal or licensing deadline before you commit to a date.
Which OTRS capabilities move cleanly to Znuny and which need rework
This table maps the main OTRS building blocks to their Znuny counterparts and marks each as clean, needs rework or gap. Use it to scope a migration: rows marked clean still need a test on a copy, and any add-on or custom Perl code should be checked against the Znuny documentation for your release line. Znuny describes itself as a ticketing system for customer service, help desk and IT service management, so most core ticket features carry over.
| Capability | Znuny position | What to confirm or rework |
|---|---|---|
| Ticket queues, states and priorities | Clean: core ticket model is shared with the OTRS Community Edition 6 lineage | Confirm custom states and priority mappings still match agent workflows after the stepwise update |
| Agent interface | Clean: same agent workflow in the Znuny interface | Review any customized templates, themes or screen configurations, which may need adjustment |
| Customer interface | Needs rework: customer-facing templates and portal settings may differ | Test customer login, notifications and portal pages on a copy before cutover |
| ITSM modules (incident, change, service) | Needs rework: confirm module availability and configuration for your release line | Check change and service configuration, CMDB links and SLA definitions against the Znuny documentation |
| Add-on packages | Needs rework: compatibility varies by package and release | Ask each add-on vendor or maintainer for Znuny support; remove or replace packages that do not install on the target version |
| Custom Perl code | Needs rework: modules and API calls may change between versions | Run a code review against the Perl API documentation and fix deprecated calls during the copy test |
| Reporting and statistics | Needs rework: stats definitions and exports depend on the schema and installed modules | Re-create key reports on the copy and compare counts against the source system |
| Database platform | Clean: MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later are supported | Confirm the database version and character set settings before importing data |
Migration sequence: inventory, stepwise upgrade, pilot, parallel run and cutover
This sequence moves an OTRS installation to Znuny in verifiable stages, so each stage produces evidence that the next one can rely on before any live tickets move.
Inventory versions, add-ons, custom code and database
Start by recording the exact OTRS version, the database engine and version, the web and Perl stack, every installed add-on package, all custom modules, scheduled jobs, external interfaces and mail connectors. Your OTRS administrators and any integration developers should own this list, and a Znuny-experienced engineer should review it for items that will need replacement or testing. The output is a signed-off inventory document that maps each component to a keep, adapt or retire decision. The step is done when every production dependency appears in the list and someone other than the author has reviewed it.
Plan the stepwise update path to Znuny LTS 6.5
Znuny 6.5 accepts updates only from 6.4, so an installation on an older OTRS release must first be brought to 6.4 through the intermediate versions required by the upgrade documentation. Confirm each hop against the Znuny documentation and the release notes on the Znuny releases page, and record the database and configuration changes each hop introduces. The output is a written upgrade plan with an ordered list of versions, the backup point before each hop and the rollback method. The step is done when the plan has been checked against the current documentation for your exact starting version.
Rebuild the target server and database
Provision the Linux server, Perl runtime, Apache with mod_perl2 and a supported database from the Znuny requirements, which include MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later or Oracle 19c or later. Decide the database engine now, because switching later adds a second migration. Ask your DBA to confirm backup tooling, replication and restore procedures on the chosen engine. The output is a clean target environment with a documented build, tested backup and restore, and a checked connection from the application to the database. The step is done when a test restore has been completed on the new database host.
Run the pilot on a copy of production
Restore a recent copy of the production database and file storage into the test environment, then run the stepwise upgrade on that copy exactly as it will run in production. Re-create or port add-ons and custom code, and log every error, warning and manual fix. Have agents test real workflows such as queues, state changes, SLA escalations, email in and out, and any external interface. The output is a pilot report listing defects, fixes, timings observed in the test and open decisions for the cutover runbook. The step is done when a full pilot run completes without unresolved blockers and the business owner accepts the test results.
Operate a parallel run before cutover
Keep the upgraded Znuny instance running alongside OTRS for a defined validation period, with a documented process for which system is authoritative. Compare ticket counts, queue assignments, attachments, notifications and integration traffic between the two systems, and resolve differences before they affect customers. Confirm that the process owners agree on the authoritative system at every point in the period. The output is a parallel-run log with reconciled discrepancies and a signed go decision. The step is done when the comparison shows no open differences that matter to operations.
Execute the cutover runbook
Freeze changes in OTRS, take a final full backup, run the last data sync or migration, repoint mail, DNS and integrations to Znuny, and run the post-cutover checks written in the runbook. Keep the rollback steps ready until the go-live checks pass, and name the person who can authorize a rollback. The output is a completed cutover record with timestamps, check results and the list of any accepted exceptions. The step is done when agents can work in Znuny, inbound mail and integrations are confirmed, and the record is signed off.
Decommission the old OTRS system
After a stable period that your change board defines, retire the OTRS servers, remove mail routes and integration credentials that point to them, and archive a read-only backup under your records policy. Check with your compliance or legal team how long OTRS data must be retained and where. If you hold a commercial OTRS subscription, follow the vendor's terms to end it. The output is a decommissioning record and a confirmed archive location. The step is done when no service still points to the old system and the retained archive has been verified.
Which data and integrations to move, and which to rebuild
An OTRS to Znuny move carries over more than the ticket table. Each category below needs a decision: migrate as data, re-create by hand, or retire. Inventory them before choosing an update path, because the answers drive the test plan on the copy.
Tickets and articles
Tickets, their articles and attachments are the bulk of the database and the record your auditors will ask about. Because the Znuny update path runs through the existing schema, most of this data stays in place rather than being exported. Check ticket counts, article sizes and attachment storage location (database or filesystem) on your copy, since these set the upgrade duration and backup size. Confirm that attachments and article bodies match after each intermediate step.
Customers, agents and roles
Customer users, customer companies, agents, groups and roles define who can see and act on each queue. Compare these lists on the test copy after the update, not just their count. Agent accounts tied to departed staff should be disabled or removed before cutover. Confirm with Znuny documentation how customer and agent records are handled in your installed version, since authentication source affects what can be changed in the database.
Queues, states and configuration
Queues, priorities, states, types, SLAs, services and dynamic fields carry your process model. Document each one in a table before the move, then compare it on the copy. Custom states or dynamic fields added by administrators often break after an update if the target version expects different names, so review each one. Export your system configuration from the admin interface and keep it under version control where practical.
Email channels and PostMaster filters
Incoming mail usually reaches OTRS through a mailbox, a pipe or a POP3 or IMAP fetch, and then passes through PostMaster filters that set queues and states. Recreate the mailbox connection on the new server and test it with real sample messages, including replies that carry ticket numbers in subjects. Make sure only one system polls a mailbox during the parallel test, or tickets will be duplicated.
LDAP, SSO and authentication
Agent and customer logins may depend on LDAP directories, an SSO proxy or local passwords. Each source must be rebuilt on the Znuny server, with the same attribute mapping and group filters. Confirm that the directory connection works with the Znuny version you deploy, and test a disabled account to confirm it stops accessing tickets. Document the service account used for directory binds.
Callers, integrations and add-ons
Scripts, monitoring checks, web services and other systems that create or update tickets call OTRS through its web service interface or its command line tools. Inventory every caller, identify the web service and operation it uses, and confirm each one against Znuny's documentation before cutover. Add-on packages and custom Perl modules need a compatibility check of their own, since each one may be built for a particular OTRS line. Plan to rebuild or retire anything you cannot confirm.
How the migration differs for Community Edition 6 and commercial OTRS starting points
Community Edition 6 installations usually carry the oldest code base and the most local changes. Znuny continues the Community Edition line from version 6.0.30, so the starting point is close to its origin, but years of add-ons and patches make the update path harder to predict. Plan for each documented step to run in order, with a check after every step.
- Add-on compatibility: Check each installed package against the Znuny release you are moving to. Packages without a maintained Znuny build may need replacing or removing before the update.
- Custom code: Local Perl modules, template overrides and edited core files cause most upgrade failures. Record every modification, then decide whether it stays, moves into a supported extension point or goes.
- Stepwise version path: Znuny 6.5 accepts updates only from 6.4, so an installation on an earlier 6.x release needs an intermediate upgrade first. Confirm the exact steps in the Znuny documentation before scheduling work.
- Data work: Schema changes, attachments and article storage must be verified on a restored copy of production, not just checked for a successful script exit.
Before touching production, confirm the package list, the modified file list and the release notes for each step with your own test results in hand.
Commercial OTRS customers usually run licensed add-ons, and some use vendor-managed hosting. The starting point is therefore defined by a contract as much as by code. Before the first update step, you need to know which packages, data and support obligations the vendor controls and which ones you control.
- Licensed add-ons: Proprietary packages may have no open-source equivalent or no Znuny-compatible build. Inventory each one and ask the vendor whether source code, a data export or a replacement path is available.
- Vendor-managed hosting: Ask for database and file system access, complete backups and a written export procedure. Confirm who performs the copy, in what format and within what window.
- Support boundaries: Vendor support usually ends at cutover, so agree in writing on the evidence the vendor will provide that the data copy is complete and consistent.
- Integrations: Commercial installations often connect to directory services, mail relays and monitoring. Document each interface, then test it against the copy.
Ask the vendor in writing which components, data and support obligations apply under your current agreement before you schedule any migration work.
A small installation holds a limited number of queues, agents and tickets, so the data work is mostly about configuration accuracy rather than volume. Restoring a copy takes little time, which makes it practical to rehearse the full update path several times. The main risk is assuming that a small system needs no formal testing.
- Repeated rehearsals: Run the complete stepwise update on a copy at least once from start to finish, then repeat it after each fix so the final run is the one you trust.
- Queues, roles and states: Compare queue definitions, agent roles, ticket states and notification settings before and after each step. Small systems often hide these errors until agents report them.
- Attachment checks: Confirm that attachments open correctly from a sample of tickets across each queue, including older tickets.
- Short cutover window: Because the data set is small, a brief freeze of ticket creation is often enough, but confirm the final delta sync with the people who receive email.
Schedule a sign-off in which a named agent group checks their daily tasks on the copy before cutover.
A large installation holds years of tickets, articles and attachments, so the database and storage decisions drive the schedule. Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Choose one that your team can operate, back up and restore within the time your service agreements allow.
- Database choice: Confirm the version support in the Znuny README for your chosen engine, then measure restore time on a full-size copy.
- Full-size rehearsals: Run every update step against a copy of the full database and attachment store, not a trimmed sample, because index and migration behavior changes with volume.
- Storage capacity: Size the attachment and article storage with headroom for the copy, the migration and the rollback point.
- Archive strategy: Decide which closed tickets to archive before the migration, and document how agents will reach them afterward.
- Performance checks: Measure search, queue views and reporting on the copy before cutover, since slow pages are the first sign of a missed index.
Before cutover, agree on a rollback point and a tested restore procedure, and confirm both with the database administrator and the service owner.
What drives migration cost and duration, and how to keep each down
This table lists the components that move the cost and calendar of an OTRS to Znuny migration, who is paid for each, and whether it is one-time or recurring. Read it as a checklist to scope a fixed-price quote and to size internal effort before you agree a date.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of update steps | Znuny 6.5 accepts updates only from 6.4, so an older OTRS or Community Edition 6 install must pass through intermediate versions, each with its own database and configuration checks. | Confirm your exact starting version first, then script each step and test the chain on a copy before any production run. |
| Add-on packages | Each OTRS add-on must be checked for a Znuny-compatible build or replacement, and some may need reinstallation or rework after each version step. | Inventory every installed package and its source, then retire unused ones before migration rather than porting them. |
| Volume of custom Perl code | Custom modules, overrides and scripts depend on OTRS internals, and Perl changes between versions are the most common source of rework. | Count lines and modules touched by customization, prioritize those that still matter, and document the purpose of each one. |
| Database choice | Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later. Moving engines during the upgrade adds a conversion step on top of the version path. | Where possible, keep your current supported engine and version, and make any engine change a separate, tested project. |
| Testing on a copy | Upgrade errors surface in restored data, scheduled jobs and integrations, so skipping a full rehearsal shifts cost into the production window. | Restore a recent production backup to an isolated environment, run every update step there, and keep the timing and errors as your cutover baseline. |
| Integration count | Each connected system (directory, email, monitoring, asset or billing tools) needs its interfaces retested after the change. | List every interface with its owner and test case, and agree which ones are in scope for the first cutover. |
| People availability | Named staff from ITSM, database, mail and security teams must be available for each rehearsal and for the cutover, and delays in one group stall the rest. | Book reviewers and approvers before the plan starts and name a single owner for the schedule and the rollback decision. |
| One-time costs | Assessment, scripting of update steps, customization rework, rehearsals and cutover support are paid once, usually as project effort or a fixed-scope fee. | Ask for each phase as a separate line with deliverables, so you can see which work recurs and which is finished. |
| Recurring costs | Znuny has no license fee, but Linux servers, database licensing or support where applicable, backups, monitoring and staff time to operate and patch continue after go-live. | Size the server and database tiers from measured load, and confirm whether any database support contract applies to your chosen engine. |
| Optional Znuny GmbH services | Professional services and support from Znuny GmbH are optional and recur only if you buy a support contract or retainer. | Decide which tasks your team can own, and buy external help only for the steps that need it. |
| What to ask for in a written quote | A quote should show the starting version, the update path, a package and customization inventory, the database target, the rehearsal count and the cutover plan. | Request assumptions in writing, including what happens if the copy test fails, and whether recurring support is included or priced separately. |
What usually goes wrong in an OTRS to Znuny move and how to prevent it
Most failed OTRS to Znuny projects fail on sequencing, not on Znuny itself. The risks below sit in the update path, the extensions, the custom code, the database, the live systems and the cutover plan, and each one has a check that can be done before production is touched.
Skipping an upgrade step
Znuny 6.5 accepts updates only from 6.4, so a team starting on an older OTRS release cannot jump straight to it. Teams that try to shortcut the path usually discover the failure during the production window. Map the installed version against the stepwise path in the Znuny documentation, write down every intermediate release, and rehearse each step on a copy of the production database before scheduling the cutover.
Add-ons that break after update
Third-party packages and add-ons are often the first component to fail after a version change, and they are rarely listed in the project plan. Build an inventory of every installed package, confirm with each vendor or the package maintainer whether a Znuny-compatible release exists, and remove packages nobody uses. Then test each remaining add-on on the copy, including its agent screens and scheduled tasks.
Custom code relying on removed behavior
Custom modules, overridden Perl files and scripts that call internal APIs may depend on behavior that changed between OTRS and Znuny or across Znuny releases. These faults can stay hidden until a specific ticket workflow runs. Review every local override against the Znuny developer documentation, flag any call to an API that no longer exists, and add test cases for the workflows that depend on that code.
Database mismatches
Znuny supports MySQL 8.0 or later, MariaDB 10.3 or later, PostgreSQL 12.0 or later and Oracle 19c or later, and the database engine and version must match the target configuration. Moving between engines during the migration adds a second project on top of the first. Confirm the database platform and version before the project starts, keep the character set and collation consistent, and verify row counts and attachment storage after each restore.
Unpatched systems during the project
A migration can run for months while the old help desk stays in production and continues to take customer and internal tickets. If that system is an unsupported OTRS Community Edition 6 installation, it has no security fixes for the duration. Document which version is live, apply available hardening such as restricted network access and current operating system patches, and set a decision date for the cutover so the exposure does not extend indefinitely.
Cutover without a rollback path
A cutover that changes the live ticket system without a tested way back leaves the team with no option if agents find data loss or broken workflows on day one. Before the switch, take a full database and file backup, record the exact steps to restore the old system, and agree in writing who can authorize a rollback and by what time. Run one restore drill on the copy so the rollback is known to work.
Questions buyers ask before moving from OTRS to Znuny
How much effort and cost should I expect when moving from OTRS to Znuny?
The software itself carries no license fee under GPL v3, so the cost sits in people, servers, the database and any outside help. The main drivers are the number of stepwise updates from your current OTRS version to Znuny 6.5, the number of add-on packages and custom modules you run, the size of your ticket history, and how many integrations depend on the system. Ongoing costs include Linux servers, database licensing if you choose a commercial engine, and staff time for patching. Ask any partner for a quote that separates one-time migration work, test environment setup, cutover and recurring support, and ask what each line assumes about your OTRS version and add-on list.
How long does an OTRS to Znuny migration take?
The duration depends mainly on how far your installation sits from Znuny 6.5. Znuny 6.5 accepts updates only from 6.4, so an older OTRS installation must pass through the intermediate steps in order, and each step needs its own test cycle. Other factors include the size of the database, the number of custom and third-party packages that must be checked against each version, and how many interfaces connect to the help desk. No fixed timeline is supplied for this work. Ask for a schedule that lists each upgrade step, the test window on a copy of production, and the cutover window agreed with your service owners.
What does my team need to provide for the migration?
Expect to supply a clear inventory and access to the people who know the system. Typical inputs are the current OTRS version and patch level, a list of installed add-ons and custom code, the database engine and version, the ticket volume and attachment storage size, and the list of integrations such as email, LDAP or directory sync, and monitoring. You will also need a staging environment that mirrors production, a named owner for ticket queues, roles and SLAs, and someone who can approve test results. Confirm these inputs with the vendor or partner before work starts, because missing details usually surface as scope changes.
Can an internal team migrate OTRS to Znuny without outside help?
Yes, a capable internal team can perform the migration, provided it has Linux administration skills, experience with Perl-based applications, and database administration experience for the engine you choose. Znuny's documentation portal covers the current feature version and the latest LTS version, which helps with planning, and the README lists supported platforms, Perl and Apache requirements, and database versions. The risk is capacity and continuity: the work requires repeated test cycles across each update step, and the team must be able to run the system afterward. Decide early whether you have the time and the second person needed to cover patching and incidents.
What happens to add-ons and custom code during the move?
Add-ons and custom code are the most common source of delay, because each one must be checked against every Znuny version in your upgrade path. Some packages may have a Znuny-compatible release, some may need changes, and some may no longer be maintained and need replacement or removal. Custom code that touches core files or the database schema needs a review before testing begins. Build a register of every package and modification, record its version and owner, and confirm compatibility with the Znuny release you plan to run. Ask whoever performs the work to document each decision, since auditors and future maintainers will ask about it.
Do I need Znuny GmbH services for the migration?
Znuny GmbH services are optional. The project is open source and its documentation is public, so many organizations complete the move with internal staff or an independent implementation partner. Znuny GmbH, based in Berlin, offers professional services, which may suit teams that want the maintainers involved in complex add-on or database decisions. Whether you need them depends on the size of your custom code, your internal skills and your tolerance for risk during cutover. Ask any provider to state in writing what it will deliver, which Znuny versions it covers, and who supports the system after go-live.
Should I test the migration on a copy before the production cutover?
Yes. Test every update step on a copy of production before you touch the live system, because each step can break add-ons, templates or database changes that users would notice immediately. A copy lets you measure how long each step takes, check ticket and attachment integrity, verify email and integration flows, and rehearse rollback. Keep the copy's data current enough to be representative, and document the results so you can repeat the sequence on cutover day. Ask your partner or internal team to define pass or fail criteria before the first test run.
How DeployOpen scopes, runs and supports an OTRS to Znuny migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an OTRS to Znuny migration, we work from a written, fixed scope and run every step on a copy of your system before anything touches production.
How we scope
- Inventory your current OTRS version, add-on packages, custom code and database engine before agreeing any scope.
- Confirm the stepwise update path from your current release to Znuny, with each intermediate step written into the plan.
- Agree in writing which add-ons, custom modules and integrations are migrated, rebuilt or retired.
- Ask for the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.
How we build
- Stand up a test copy of the OTRS system on infrastructure you control, including a restored database.
- Run each update step on the copy, then test agents, customer interfaces, email channels and reports.
- Verify add-on compatibility and port custom code against the Znuny developer documentation.
- Document the database choice, server configuration and backup routine as the build proceeds.
How we hand over
- Deliver the runbook for the production cutover, including rollback steps and the final data check.
- Provide documentation of the configuration, customizations and known gaps against the original system.
- Walk your administrators through daily operation, updates and backup restores on your own servers.
- Record the test results from the copy so your team and any auditor can trace what was verified.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover applying future Znuny release updates to a tested copy before production.
- Confirm response expectations and service levels in the retainer terms, since none are set here.
- Support stays inside your environment, so your data does not leave your own infrastructure.
