Migrate from Jira Service Management to Zammad: what the move involves
Zammad has no built-in Jira Service Management migrator. Its migrators cover Freshdesk, Kayako, OTRS and Zendesk, so moving agent ticketing from Jira Service Management means exporting data from Jira, importing it through the Zammad API, and rebuilding the parts a backup does not carry. Teams usually arrive here because of the Atlassian Data Center timeline, a renewal, or a requirement to run agent ticketing on their own servers. Before scoping anything, confirm which Jira deployment you run, because the export paths differ between Cloud and Data Center. The Atlassian Cloud backup manager, for example, excludes automation rules, third-party apps and Assets, so those must be extracted and recreated separately.
The work is usually done by the internal platform or service desk team, often with an implementation partner for the API import and the Zammad hosting. The internal team owns the business decisions: which tickets, customers and attachments are migrated, how groups and roles map to Zammad groups and agent permissions, and which SLAs and triggers must exist on day one. The partner or in-house engineers typically write the import scripts against the Zammad API, run test imports on a non-production instance, and handle installation of the application, PostgreSQL, Redis and, for multi-instance deployments, Memcached. Ask any partner to show how they will handle attachments, ticket history and customer identities, since those fields are where API imports most often need rework.
Effort and risk are driven by the number of tickets, the depth of workflow customization in Jira, and how many integrations depend on the old queues. Cost has a one-time part (export scripting, import runs, rebuilding triggers and SLAs, testing and cut-over) and a recurring part (hosting, maintenance, upgrades, and any Zammad support subscription you choose). Plan for a parallel run and a rollback path, and agree the cut-over in writing with the scope. Confirm with Zammad which API endpoints and rate limits apply to your version, and check the Zammad migration documentation for the current supported import methods before you commit to a timeline.
Which Jira Service Management capabilities map to Zammad, and which need rework
This table compares the main Jira Service Management capabilities with what Zammad provides out of the box, what needs rework during migration, and where no equivalent exists. Read each row as a planning input: clean rows can move with configuration, rework rows need design and data mapping, and gap rows need a decision on whether to keep another tool or accept the change. The main takeaway is that Zammad covers agent ticketing well, but Assets and change management must be planned separately.
| Capability | Jira Service Management | Zammad fit and effort |
|---|---|---|
| Agent ticketing and customer records | Requests, customers and organizations in a service project | Clean for ticket and customer data; organizations and users need mapping during import |
| Email, chat, form and phone channels | Email, portal forms, chat and phone integrations | Needs rework: email and web form are core; chat and phone depend on channel setup and add-ons to confirm |
| SAML and OpenID Connect sign-in | Atlassian Cloud identity and SSO configuration | Clean: Zammad supports SAML and OpenID Connect third-party login; confirm the identity provider settings |
| Search | Jira Query Language and Atlassian search | Needs rework: Zammad uses Elasticsearch for faster search and attachment content search, which is optional but strongly recommended |
| Queues and SLAs | Queues, request types and SLA goals | Needs rework: rebuild groups, escalation rules and time rules by hand, since a Jira backup does not carry them |
| Automation rules | Jira automation rules and triggers | Gap in export: Jira Cloud backups exclude automation rules, so each rule must be documented and rebuilt in Zammad triggers and schedulers |
| Marketplace apps | Third-party Atlassian Marketplace apps | Gap in export: backups exclude apps; replace each app with a Zammad feature, an API integration or a custom build |
| Assets and configuration data | Jira Assets object schemas and references | Gap: Zammad has no equivalent to JSM Assets; plan a separate CMDB such as GLPI or iTop and extract Assets data on its own |
| Change management | Change requests and approvals in JSM | Gap: Zammad has no equivalent change management module; decide whether changes stay in another ITSM tool |
| Data migration path | Backup for cloud and CSV exports of work items | Needs rework: Zammad has no built-in Jira migrator, so tickets and customers move through the Zammad API under custom development |
What data can be exported from Jira and what has to be rebuilt
Jira Service Management gives you a few documented ways to get data out, and none of them produces a complete Zammad-ready package. The Jira backup covers work items and history, but automation, apps and Assets sit outside it, and the integrations around the service desk have to be rebuilt by hand in Zammad.
Jira Cloud backup manager contents
The backup manager for cloud captures work items, comments, users and groups, and project configuration. This is the core of the ticket history you will carry into Zammad through the API. Check that the projects you need are included in the backup and that your comment and user records are complete before you start mapping fields. Treat the backup as a source archive, not as an import file, because Zammad cannot read it directly.
Attachment backup timing
When you include attachments in a Jira Cloud backup, Atlassian requires 48 hours between backups. Plan the export window so the attachment set you move to Zammad is the one you validated, and schedule the final export before the cutover freeze. A ticket without its files will look complete in a report but lose evidence that agents and auditors rely on.
Automation rules are excluded
Automation rules are not part of the Jira Cloud backup. Export them by hand from the project settings, record each trigger, condition and action, and decide which ones Zammad needs as trigger, macro, or scheduler rules. Many rules that route tickets or send notifications will have no direct copy, so each one needs a written replacement and a test case.
Third-party apps and Assets are excluded
Apps installed in Jira and Assets objects are outside the backup, so their data needs a separate export. Assets requires its own CSV export, and app data depends on each vendor's tooling. Inventory every app that holds data or changes tickets before the migration, and confirm with each vendor whether data can leave the platform in a usable format.
API import for tickets and customers
Zammad has no built-in Jira migrator, so tickets, customers and history move through the Zammad API. A script reads your Jira export, maps requesters to Zammad users, groups and organizations, and creates tickets with articles for comments. Test with a sample project, check how timestamps, states and priorities translate, and confirm the rate limits and token permissions of your Zammad instance before running a full load.
Integrations to rebuild by hand
Email inboxes, SSO sign-in, chat channels and outbound webhooks do not come across with the data. Recreate each email channel and its routing, configure SAML or OpenID Connect sign-in using the providers Zammad supports, reconnect chat tools, and rebuild webhook endpoints that other systems call. Record each integration's owner and cutover step so no inbound channel goes silent after the switch.
The migration sequence from inventory to decommission
This sequence moves agent ticketing from Jira Service Management to Zammad in controlled stages, so each queue, channel and rule is mapped, tested on a pilot instance, run in parallel and retired only after the team signs off. Each step produces a written artifact that the next step depends on.
Inventory queues, request types, SLAs and automation
Work with the JSM administrator and two or three senior agents to list every queue, request type, SLA, automation rule, email address, chat channel and integration in use. Jira Cloud backups do not include automation rules, third-party apps or Assets, so these must be recorded by hand or exported through the admin screens. The output is an inventory workbook with one row per object, its owner, its current volume and a yes or no for whether agents still rely on it. Sign-off comes when the workbook is reviewed by the team lead for each queue.
Build the field and workflow mapping document
Map each Jira issue type, status, priority, custom field and request type to a Zammad object, state, priority or ticket attribute, and decide where a Jira concept has no equivalent, such as change management approvals or Assets references. Record each decision and who approved it, including what happens to closed history and attachments. The output is a mapping document that names every target field and every item marked as rebuilt manually. Sign-off comes from the service owner and the security reviewer for any field that holds personal data.
Stand up a new Zammad pilot instance
Install Zammad on infrastructure your team controls, following the package, Docker Compose or Helm installation path that matches your platform, and confirm PostgreSQL 15 or newer, Redis 7 or newer and your reverse proxy are in place. Configure SAML or OpenID Connect sign-in with your identity provider, and enable Elasticsearch and Memcached if you run multiple instances. The built-in migrators do not cover Jira and only run against a new instance, so this pilot is a clean target, not an in-place upgrade. The output is a documented build record with versions, configuration and the access model. Ask the vendor or your partner to confirm the supported version set before you start.
Import a pilot set through the Zammad API
Export the work items, comments and customer records from Jira, then write or commission an importer that calls the Zammad API to create groups, customers, tickets and articles in the order defined by the mapping document. Run the import against the pilot with one representative queue and keep the full log of created, skipped and failed records. Compare counts and sample tickets with the source, including attachments, timestamps and ticket owners. The output is an import test log with reconciliation results, and the step is complete when a second, clean run produces the same counts and the failed-record list is empty or explained.
Run a parallel period with explicit channel routing
Route new email and chat traffic for the pilot queues to Zammad while the existing JSM queues keep running for everything else. Publish a short routing guide that tells requesters and agents which channel reaches which system, and confirm that replies from each system go back to the right requester. Track duplicate tickets, misrouted messages and agent questions in a shared log for the agreed period. The output is a parallel run report listing each defect, its fix and its status. The step closes when the team agrees that open defects have no effect on customers.
Rebuild automation, SLAs and reporting in Zammad
Recreate each automation rule from the inventory as a Zammad trigger, scheduler or macro, and configure SLA and escalation rules to match the targets the service owner approved. Rebuild the dashboards and reports that managers used in Jira, using the Zammad reporting features with the data you imported. Test each rule with a scripted set of sample tickets and record the expected and actual outcome. The output is a rule test matrix signed by the service owner, showing every automation has a passing test or an approved manual replacement.
Execute the cutover with a signed checklist
Schedule the cutover window with the agents and requesters affected, move the email and chat inboxes to Zammad, switch the public forms and portal links, and freeze new work in JSM for the migrated queues. Run the final delta import of records created after the first import, and confirm that inbound mail reaches Zammad and outbound mail is sent from the approved address. The output is a cutover checklist with each item marked complete, the time it was completed and the name of the person who signed it. Keep the rollback steps on the same page so the decision owner can reverse a step if a critical check fails.
Decommission Jira and retain a read-only export
After the agreed stabilization period, make the JSM projects read-only, remove the integrations and mailboxes that pointed to them, and revoke the API tokens and service accounts. Before any licence or subscription ends, take a final export of tickets, comments, attachments, users, configuration and the automation inventory, and store it in a location with the same access controls as the source data. Confirm with your legal and records team how long the archive must be kept. The output is a decommission record listing every removed integration, the archive location and its checksum, and the signed closure from the service owner.
How the Zammad side is built: hosting, database and search
Zammad is a set of components you operate yourself, and the first decision is which pieces your team already runs well. The content database is PostgreSQL 15 or newer, which holds tickets, customers, articles and configuration. Redis 7 or newer handles realtime websocket communication, so agents see updates without reloading, and Nginx or Apache sits in front as the reverse proxy. Confirm that your PostgreSQL and Redis versions meet the current software requirements page before you size hosts, because the minimums can change between Zammad releases, and check the Zammad release notes for the version you plan to install.
Search is the component most often underestimated. Elasticsearch is optional, but the Zammad documentation strongly recommends it because it powers faster search, reporting and the searching of email attachment content. For a service desk that migrates years of Jira comments and attachments, plan for Elasticsearch from the start and ask the migration team how long a full reindex takes against your imported volume. Memcached is needed only when you run more than one Zammad instance, such as container replicas or cluster nodes. A single installation can use the file system cache, so a pilot on one host can skip Memcached while a production cluster cannot.
The deployment method also sets who supports what. Zammad documents installation from packages, with Docker Compose and a Kubernetes Helm chart as alternatives. On Kubernetes, Zammad support covers only the Zammad application, not cluster-level problems, so your platform team must own the cluster, storage, ingress and backups. Decide early whether your platform team or DeployOpen will operate the hosts, and write down who gets paged for a failed Elasticsearch node or a stalled Redis instance. Those ownership lines matter more to the cutover plan than the component list itself.
How the move differs by size and starting point
A small service desk with a handful of queues, modest request volume and no Assets usually has the shortest path. The data is mostly tickets, customers and a few agent groups, so the export is small and the reconciliation is quick. Most of the effort goes into rebuilding the basic channels, roles and notification rules that the team uses every day, and into testing them with a small set of agents before cutover. Illustrative case: a team with three queues and a simple email intake can often rebuild its routing in a short working session, provided the queue logic is written down before work starts.
- Queues and groups: Recreate each queue as a Zammad group and check which agents need access to which group.
- Channels: Rebuild the email addresses and any web form intake, then test inbound and outbound mail on the new instance.
- Automation: Expect few rules to rebuild, but list them anyway, because Jira Cloud backups do not include automation rules.
- Testing: Run a short pilot with a few agents and a set of realistic test tickets before any production cutover.
- Retirement: Decide early how long the old Jira instance stays readable and who signs off on archiving it.
Confirm with your team that every queue, group and notification rule has a written owner before the first import.
A large service desk with many projects, deep workflow customization and many automation rules carries most of the rework. Zammad has no built-in Jira migrator, so tickets and customers move through the API, and the mapping work (statuses, custom fields, SLA targets and triggers) is where most time is spent. Each Jira project usually needs its own mapping decision, and some projects may consolidate into fewer Zammad groups. Automation is the largest gap, because Jira Cloud backups exclude automation rules and third-party apps, so every rule must be inventoried, rewritten as a Zammad trigger, scheduler or macro, and tested.
- Field mapping: Map each custom field and status to a Zammad field or state, and decide where data without a clean match will live.
- Automation inventory: Export the rule list from Jira and document the intent of each rule before rebuilding it.
- Volume and throughput: Plan batched API imports and verify counts per batch, since a large history takes longer to load and check.
- Permissions: Rebuild role and group access carefully, because access mistakes at this scale affect many agents at once.
- Parallel running: Plan a period where both systems are read against each other, with a defined owner for reconciliation.
Ask any implementation partner for a written inventory of projects, rules and apps before agreeing on scope.
Teams whose customers reach help content through Confluence spaces add a second migration beside the ticket move. Confluence articles are not tickets, and the service desk portal links to them, so the knowledge base needs its own inventory, a target decision and a link plan. Zammad includes a knowledge base, which can absorb articles that are rewritten or reorganized, while some teams keep a separate wiki such as XWiki next to the service desk. The choice affects how much content is moved as is and how much is rewritten for the new portal.
- Article inventory: List which spaces and pages customers reach from the portal, and remove stale pages before moving anything.
- Target decision: Choose between Zammad's knowledge base and a separate wiki, and record why.
- Links: Find every ticket template, portal link and macro that points to a Confluence page, since those break at cutover.
- Deflection: Check that search and categories in the new portal still surface the articles customers used to find.
- Ownership: Name an editor for each article group so content does not drift after the move.
Confirm the target knowledge base decision before the ticket import starts, because link rewriting depends on it.
Cost components: what is one-time and what recurs
A move from Jira Service Management to self-hosted Zammad has no license fee to replace, so the budget is made of staff time, a partner's fixed scope, infrastructure and upkeep. Each card below marks whether a cost is paid once or every year, and what to ask for before signing.
Internal staff time for inventory
Your team must list what is in Jira Service Management before anything moves: projects, request types, customer fields, queues, SLA definitions and the users and groups behind them. This work is one-time, but it is often the largest internal cost because only your service owners know which rules still matter. Ask the implementation partner to state which inventory outputs they expect from you and who signs them off.
Rebuilding queues, SLAs and automation
Zammad does not import Jira automation rules, so each trigger, escalation and SLA target must be rebuilt in Zammad's own settings and tested with real ticket paths. This effort is one-time per rule set but grows with the number of projects and custom workflows. Check whether the quote counts testing and the agent sign-off as part of the fixed scope.
Implementation partner's fixed scope
A partner typically quotes a fixed scope covering the export, API import, rebuild, testing and cutover. The scope should name the number of projects, ticket volumes, integrations and channels in it, and what triggers a change request. Ask for the deliverables in writing and the acceptance criteria for each one.
Hosting, database and search
Infrastructure is the main recurring cost of the platform itself. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, and Elasticsearch is optional but strongly recommended, while multi-instance deployments need Memcached. Price each component in your own cloud or data center, including backups, storage growth and monitoring.
Optional Zammad support subscriptions
Self-hosted Zammad has no license fee, but Zammad GmbH sells support subscriptions for self-hosted installations: Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. These are recurring and optional, so decide whether your internal team or a partner covers first-line support. Confirm the current prices on the pricing page before budgeting.
Upgrades and ongoing operations
Zammad ships minor releases and security fixes on more than one line, so upgrades recur throughout the life of the platform. Budget staff time for applying updates, testing custom settings after each release and keeping the Kubernetes or Docker Compose deployment patched. Ask the partner whether a retainer covers upgrades, and how security releases are handled outside business hours.
What drives the effort and duration of the migration
This table lists the inputs that change how much work a Jira Service Management to Zammad move takes, why each one adds effort, and how to keep it contained. Read it before asking for a quote, because the same scope can take very different amounts of time depending on how much history, configuration and integration you carry across.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number of queues and SLAs | Zammad has no native Jira queue or SLA object, so each JSM queue must be mapped to a Zammad group, filter or trigger and each SLA rebuilt by hand with its response and resolution rules. | Consolidate queues before migrating and document one mapping table that agents sign off on. |
| Automation rule count | JSM automation rules are excluded from Jira Cloud backups, so every rule is recreated as a Zammad trigger, scheduler or macro and tested again. | Rebuild only rules still in use, and retire the rest during the mapping review. |
| Integrations and apps | Marketplace apps and webhooks feeding JSM have no automatic equivalent, so each one needs a replacement connector or a custom build against the Zammad API. | Inventory every app and webhook first, then keep only those that still carry business value. |
| Email inboxes and channels | Each inbox, distribution list and chat or phone channel must be reconnected in Zammad, and mail routing and SPF or DKIM changes must be coordinated with the mail team. | Cut over one inbox at a time and keep the old inbox forwarding during a short overlap period. |
| Attachment volume | Attachments are excluded from some export paths and must be pulled and re-attached through the API, which slows the run and raises storage needs on the new server. | Migrate only attachments linked to active or recent tickets, and archive older files in read-only storage. |
| History depth required | Full comment and status history for years of tickets multiplies API calls and increases the chance of errors and rate-limit pauses during import. | Import active tickets with recent history and keep older records in an archive export that staff can search. |
| SSO setup | Connecting SAML or OpenID Connect sign-in needs identity provider metadata, claim mapping and role tests for agents and customers before go-live. | Start the identity integration in parallel with data work and test with a small pilot group. |
| Elasticsearch sizing | Elasticsearch is optional but strongly recommended for faster search and attachment content search, so indexing and cluster capacity add setup and tuning work. | Confirm with your infrastructure team which search features are required and size the cluster to that scope. |
| Staff availability | Agents must validate mapped queues, test triggers and approve cutover, and their time on the project competes with live ticket work. | Name a product owner, schedule test windows around peak periods and agree acceptance criteria in writing up front. |
What usually goes wrong in a Jira to Zammad move and how to prevent it
Most failed moves from Jira Service Management to Zammad are not data loss in the ticket table. They come from the parts a Jira backup leaves out, from parallel running, and from people who were never trained on the new tool. The cards below cover each failure point with a prevention step you can check before cutover.
Automation rules lost in a backup restore
Jira Cloud's backup manager excludes automation rules, so a restored backup or a CSV export will not carry over the triage, routing and notification logic your agents rely on. Zammad has no import path for Jira automation, so each rule must be rebuilt as a Zammad trigger, scheduler or macro. Before cutover, list every active Jira automation rule, record its trigger and action, and sign off a Zammad equivalent for each one.
Missing apps and Assets links
Third-party Jira apps and Assets objects are outside the Jira Cloud backup scope, so fields, linked configuration items and app-generated data can disappear without any error message. Inventory every app in use and every field that points to an Assets object, then decide per item whether to export it, rebuild it in Zammad or GLPI, or retire it. Confirm the decision with the process owner before the export runs, not after the first complaint.
Attachment gaps in the export
Attachments are a separate concern from ticket text, and the backup must be configured to include them, with a 48-hour wait between backups when they are included. Check file counts and total size against the source before import, and sample tickets with large or nested attachments. Attachments that fail to transfer often surface weeks later, when an agent needs an approval document from a closed case.
Email routing errors during parallel run
Running Jira and Zammad side by side is where duplicate tickets and lost replies usually start, because the same mailbox can be forwarded to both systems. Assign one inbound address per queue to a single system at a time, document the forwarding rules, and test reply threading with a set of known messages. Keep a written owner for each mailbox so that a change in one system is never silently missed in the other.
Duplicate customer identities
Customers who appear under several email addresses in Jira will appear as several people in Zammad unless identities are merged before import. Agree on the matching key, usually a primary email address, and review the users with the most tickets first. Duplicate customers also break history views, so a customer who contacted you by phone and email will not see one consolidated timeline.
SLA timers that do not match
Jira service level agreements are calculated from request types, priorities and working hours, and Zammad calculates its own escalation and reaction times from its own settings. Export the SLA definitions and holiday calendars, then build Zammad equivalents and test them with tickets whose timers you can calculate by hand. Unmatched timers show up as false breaches or silent misses in the first month of reporting.
Staff skipping training
Agents who learn Zammad only from the first live ticket will fall back to email and spreadsheets, and those side channels leave no record. Schedule role-based sessions for agents, team leads and administrators, and give them a sandbox that reflects your queues. Track who has completed training before each queue moves, and make the first week's support lead responsible for answering questions.
Questions buyers ask before moving from Jira Service Management to Zammad
How much effort and cost should we expect for a move from Jira Service Management to Zammad?
The cost comes from four parts: the Zammad hosting environment, the data export and import work, the rebuild of queues, SLAs and automation, and the internal time your team spends on testing and cutover. Zammad has no license fee for self-hosted installations, so the recurring costs are infrastructure, operations and any support contract you choose. Zammad sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Ask any implementation partner for a fixed-scope quote that separates one-time migration work from recurring operations, and ask which Jira data sets are included in that scope.
How long does a migration from Jira Service Management to Zammad take?
The timeline depends on the number of projects and request types, how much history you must keep, how many automation rules and integrations need rebuilding, and how many channels (email, chat, forms, phone) you route into Zammad. Because Zammad has no built-in Jira migrator, the export and API import work is custom, so it is usually the longest phase. Confirm durations in writing with your implementation partner before work starts, and plan a parallel-run period for agents and customers. Atlassian's Data Center dates may also set a deadline, which is covered in a separate question below.
What does our team need to provide during a Zammad migration?
A migration needs named people from several groups. Expect to provide:
- A business owner who signs off queue design, SLAs and escalation paths
- Jira administrators who can run exports and explain custom fields, workflows and automation
- Identity and network staff for sign-in through SAML or OpenID Connect and for the hosting environment
- Support leads who test real tickets and approve cutover
Before scoping, inventory your Jira projects, custom fields, automation rules and attachments, since Jira Cloud backups exclude automation rules and Assets.
Can our own IT team migrate from Jira Service Management to Zammad in-house?
Yes, an experienced in-house team can do it, provided it has the skills for each part of the work: Linux and PostgreSQL operations, the Zammad installation methods (package, Docker Compose or the Kubernetes Helm chart), a script that calls the Zammad API, and enough time to rebuild automation and reporting. The main risks are incomplete exports and rules that are rebuilt by hand and then drift. Zammad's Kubernetes support covers only the application, so Kubernetes-specific issues remain your responsibility. If your team lacks one of these skills, a fixed-scope engagement can cover the gap while your staff keep ownership.
Does Zammad have a migrator for Jira Service Management?
No. Zammad's built-in migrators import from Freshdesk, Kayako, OTRS and Zendesk, and other systems are imported through the Zammad API or through custom development. Jira Service Management data therefore moves through an export from Jira and a scripted import into Zammad. Confirm during scoping how customers, organizations, tags, custom attributes and attachments will be mapped, and whether historical tickets must be kept in full or only as read-only archive records.
What happens to Assets and change management when we move to Zammad?
Zammad does not provide an equivalent to Jira Service Management Assets or its change management workflows, so those data sets need a separate destination. Assets are usually exported as CSV and moved into a CMDB such as GLPI or iTop, while change records can be kept as archived tickets or rebuilt in the target platform. Confirm with stakeholders which Assets objects, references and change approvals are still needed, because Jira Cloud backups exclude Assets and automation rules, and those gaps must be covered by their own exports.
How do Atlassian's Data Center dates affect the timing of our move?
Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026, sets March 30, 2028 as the last date for existing customers to buy licenses or expansions, and on March 28, 2029 Data Center licenses expire and become read-only. If you are on Data Center, these dates mean you can plan the move without an immediate license cutoff, but the 2028 purchase date affects any growth in agent count. Confirm your own renewal and expansion terms with Atlassian and your procurement team before setting a cutover date.
How DeployOpen scopes and runs a Jira to Zammad migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Jira Service Management to Zammad move is agreed in writing before work starts. Because Zammad has no built-in Jira migrator, the work centers on an API-based import and on rebuilding the configuration that a Jira backup does not carry.
How we scope
- Inventory the Jira projects, request types, queues, SLAs and automation rules that the Zammad design must replace.
- Agree which ticket history, customers and attachments move, and which closed records stay in an archive.
- Record the hosting target, database, Redis, Elasticsearch and reverse proxy choices in the written scope before any build starts.
How we build
- Extract tickets, users and organizations from Jira and map each field to a Zammad object, with the mapping documented.
- Import through the Zammad API in test batches, then rebuild groups, triggers, schedules and SLA escalation rules by hand.
- Test sign-in through your identity provider, email channels and notification routing against the agreed acceptance criteria.
How we hand over
- Deliver runbooks for installation, backup, upgrades and the import procedure, so your team can repeat or audit it.
- Provide a reconciliation report comparing record counts and sample tickets between Jira and Zammad at cutover.
- Walk your agents and administrators through queues, macros and reporting, and record the final configuration.
How we support
- Support after go-live is available as a retainer, covering upgrades to new Zammad releases and security patches.
- Confirm with Zammad which support subscription, if any, your team needs for vendor-backed help on the application.
- Agree in writing who handles Kubernetes or infrastructure issues, since vendor application support does not cover them.
