Which open-source option replaces Jira Service Management for your team
For agent ticketing, Zammad is the open-source option to evaluate first, and for ITIL processes plus asset and configuration work, GLPI is the better fit. Most teams leaving Jira Service Management need one of these two, and some will run both, with Zammad handling requests from people and GLPI holding the inventory and change records behind them. The decision usually starts with a renewal date, a hosting requirement or a concern about lock-in, and the timeline is set by Atlassian's own dates. Atlassian ended support for all server products, including Jira Service Management Server, on February 15, 2024. It stopped selling new Data Center subscriptions to new customers on March 30, 2026, and on March 28, 2029 Data Center licenses expire and become read-only. Atlassian's stated path forward is Cloud, so an exit plan is a choice rather than a forced move, but teams with a Data Center contract should confirm their own license term and the last purchase date that applies to them.
Before choosing, map your current Jira Service Management workflows to the two candidates. Zammad covers ticket queues, SLAs, email channels and agent collaboration, so a team whose work is mainly request handling will find the most familiar model there. GLPI covers incident, problem, change and service level management, along with inventory, configuration items and contracts, so an IT operations team that depends on its asset data will need GLPI for that part. Check which Jira Service Management automation rules, approval flows and Assets objects you rely on, because the cloud backup does not carry automation rules, third-party apps or Assets, and those will have to be rebuilt or replaced. Confirm with each vendor which of your integrations, such as chat, monitoring or source control connectors, are supported in the version you plan to run.
Treat the decision as an inventory exercise with a written comparison. List your queues, approval paths, custom fields, integrations and reporting needs, then mark each one as carried over, rebuilt or dropped for both Zammad and GLPI. Ask an implementation partner to size the work from that list instead of from the product overview, and request a written scope that names which data sets will be migrated, which will be archived and who signs off on the cutover. Plan the migration around your renewal dates and keep the existing instance readable until the new one has been validated, since a read-only Data Center license leaves little room for rollback.
Zammad and GLPI: what each option is and when it fits
Zammad covers the ticket queue where agents answer requests, and GLPI covers the ITIL process records and asset inventory behind them. The cards below describe what each product is, the license and support model around it, and the trade-off a team should weigh before choosing one or both.
Zammad for agent ticketing
Zammad is licensed under the GNU AGPLv3, and its source code is owned by the Zammad Foundation, which is independent of Zammad GmbH. The GmbH develops the product with the community and sells hosted plans in German data centers, along with support contracts for self-hosted installs named Business, Enterprise and Corporation. A self-hosting team carries the operations itself, or buys one of those tiers. Check whether the support tier matches your response-time needs, and confirm the hosting and upgrade responsibilities in writing before you commit.
GLPI for ITIL and assets
GLPI is free asset and IT management software under GPL-3.0. Its scope covers ITIL incident, problem, change and service level management, asset inventory, configuration management, a knowledge base and contract management. It fits teams whose Jira Service Management use centers on IT operations records and inventory rather than customer-facing queues. The trade-off is that its ticket interface and workflow design differ from Jira's, so expect a rebuild of forms, approvals and SLA rules, and test them with real change requests before cutover.
Teclib' edition and GLPI Network
Teclib' edits and maintains GLPI, and it also runs GLPI Network, a hosted cloud offering with a free 45-day trial. Choosing the hosted route moves infrastructure and upgrades to the vendor, while staying on self-hosted GLPI keeps data inside your own network. Ask Teclib' which support, hosting and upgrade terms apply to each option, and confirm how the hosted service handles data location before you assume it suits a regulated environment.
Combined Zammad and GLPI setup
A common pattern runs Zammad for the requester-facing queue and GLPI for ITIL records, assets and the configuration database. Requests arrive in Zammad, and the team links them to GLPI tickets, changes and asset records when the work needs process control. The cost is two systems to patch, back up, monitor and give accounts to, plus an integration that someone owns. Decide early which system is the record of truth for each ticket type, or reports will disagree.
Zammad only for simpler ticketing
Where Jira Service Management is mainly a request queue with a knowledge base and light approvals, Zammad alone can cover the ticket lifecycle with one system to operate. It is the simpler option, but it does not provide GLPI's ITIL change and problem records or its asset and configuration inventory. Confirm which Jira workflows, approvals and reports your audit or change board relies on, because those are the features most likely to need a second tool.
Which Jira Service Management capabilities each open-source option covers
This table maps the main Jira Service Management capabilities to Zammad for agent ticketing and GLPI for ITIL and assets. Treat each note as a starting position to test in a pilot, since automation rules, third-party apps and Jira Assets are items to confirm rather than assume parity, and a Jira Cloud backup does not carry them over.
| Capability | Zammad | GLPI |
|---|---|---|
| Ticket queues and agent workflow | Strongest fit for agent ticket queues, shared inboxes and channel intake. Confirm routing logic against your queues. | Covers incident and request handling with assignment and approvals. Confirm it suits high-volume agent queues. |
| Customer portal | Web portal for customers to submit and track tickets. Confirm access rules and branding in a pilot. | Self-service portal aimed mainly at internal users. Confirm whether external customers need access. |
| SLAs and escalation | SLA and escalation rules on tickets. Confirm business calendars and breach handling against your current policies. | Service level management is in the ITIL scope. Confirm calendars, targets and escalation paths. |
| ITIL problem and change | No dedicated problem or change modules. Plan to model these as ticket states or link to a companion tool. | Problem and change management are in the ITIL scope. Confirm approval chains and change calendars. |
| Asset management and Jira Assets | No asset inventory. Link tickets to an external CMDB or to GLPI. | Asset inventory and configuration management are the closest counterpart to Jira Assets. Confirm the object model and import path. |
| Knowledge base | Knowledge base functions are available. Confirm article structure, permissions and public access. | Knowledge base is included with the ITIL modules. Confirm how existing Jira articles will be imported and linked. |
| Automation rules | Triggers and schedulers replace Jira automation. Rules must be rebuilt and tested, since a Jira Cloud backup excludes them. | Rules engine covers ticket and asset processing. Rules must be rebuilt and tested, as they are excluded from a Jira Cloud backup. |
| Third-party apps | No Atlassian Marketplace equivalent. List every installed app and confirm which functions you still need. | Plugin ecosystem available. Confirm each plugin's maintenance status, license and fit for each function. |
What a Jira Cloud backup carries over and what it leaves behind
A Jira Cloud backup from the backup manager carries the core project record: work items, comments, users and groups, and project configuration. That covers the tickets your agents work from and the history attached to them, which is the part most teams need to keep if they move ticket data into a new system. The backup does not carry automation rules, third-party apps or Assets. Those are the items most likely to break a service desk after a move, because routing, SLA logic and asset links often live there rather than in the tickets themselves. Before you rely on a backup as your exit path, build an inventory of everything the backup excludes. Export automation rules and their logic by hand, list every installed marketplace app and the data it stores, and export Assets data separately so asset-to-ticket relationships can be rebuilt in the target platform. Record which users and groups map to which queues and roles, since the backup carries them but the target system will need its own role model. Confirm the exact behavior of the backup manager on your own instance, including which project types and attachments are covered, by testing a restore or reviewing a sample backup file before the decommissioning date is set.
Attachments change the schedule. When you include attachments in a cloud backup, Atlassian requires 48 hours between backups, so plan the final cutover export with that interval in mind and start the process early enough that you are not waiting on a second run. Check the current interval and any size limits in Atlassian's export documentation for your site, because these settings can change and your own administrator view is the authoritative source. Treat the backup as one input to the migration, not the migration itself. Map backup fields to the target platform's ticket model, decide how historical tickets will be stored (imported, archived or referenced), and assign an owner for each excluded item. Run a reconciliation at cutover by comparing ticket counts, open items and recent comments between the source and target, then keep the Jira Cloud site read-only for a defined period so anything missed can still be retrieved.
How the multi-year cost of self-hosting compares with a Jira subscription
This table lists each cost component on the Jira side and the self-hosted side, marks whether it is one-time or recurring, and names what drives it up. Use it to build a like-for-like model over your planning horizon, and ask vendors and partners for quotes that break out the same components. No prices are shown because none were supplied for this comparison.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Atlassian subscription or Data Center license | Atlassian (or a reseller) | Recurring | User count, product tier and add-ons; Data Center sales to new customers end on March 30, 2026, per Atlassian's announcement, so confirm which license type is still available to you |
| Data Center end-of-life planning | Internal team or partner | One-time | Date of the read-only transition on March 28, 2029; a longer runway lets you migrate in stages instead of under deadline |
| Self-hosted infrastructure | Your cloud provider or data center vendor | Recurring | Hosting model, user count, data volume and high availability requirements; confirm sizing with the platform vendor before you budget |
| Software licensing | None for GLPI or Zammad core (open source) | Recurring if you buy support | Choice of support tier; confirm licensing terms for any add-on or plugin you need |
| Implementation and configuration | Internal staff or an implementation partner | One-time | Number of workflows, approval chains, integrations and custom fields; request a fixed-scope written plan |
| Data migration | Internal staff or an implementation partner | One-time | Volume of work items, attachments and project configuration; Jira Cloud backups exclude automation rules, third-party apps and Assets, which must be rebuilt |
| Vendor support contract | Zammad GmbH or GLPI's editor network | Recurring (optional) | Support tier, response expectations and hours; ask each vendor for the scope of each tier in writing |
| Internal administrator skills | Internal payroll or contractor | Recurring | Team size, on-call expectations and how many integrations you maintain; often the largest ongoing line in self-hosting |
| Training and change management | Internal staff or training provider | One-time, with periodic refreshers | Number of agents, administrators and requesters, plus process changes from moving off Jira workflows |
How to move tickets, users and configuration off Jira Service Management
This sequence moves ticket history, users and service configuration from Jira Service Management into a self-hosted Zammad or GLPI environment in controlled stages, so each cutover is tested before Jira is switched off and its records are archived.
Inventory workflows, integrations and excluded items
The Jira administrator and the service owners list every request type, queue, SLA, approval flow, automation rule, marketplace app and integration that feeds or reads from Jira Service Management. Atlassian's Jira Cloud backup excludes automation rules, third-party apps and Assets, so those items need their own record and a decision on whether they are rebuilt, replaced or retired. The output is a signed inventory that names every excluded item and its owner. Confirm the export scope with Atlassian support before you rely on any single export method.
Export tickets and configuration from Jira
Run a full Jira Cloud backup or data export, including attachments if your retention policy requires them, and store the files in an encrypted archive location with a documented checksum. Atlassian requires 48 hours between backups when attachments are included, so plan the export window around that limit. Export Assets, automation rules and app configuration separately, using the tool or vendor method that each one supports. The check that closes this step is a restore test of the archive into a scratch location, confirming that work items, comments, users and groups, and project configuration are readable.
Map issue types, statuses, queues and SLAs
Build a mapping table that links each Jira issue type and status to a Zammad ticket state and group, or to a GLPI incident, problem or change type with its status and SLA. Record where Jira custom fields have no direct equivalent and decide whether to store them as ticket attributes, notes or GLPI asset fields. Agree the mapping with the service owners before any data moves. The output is an approved mapping document with one row per source field, plus a list of fields that will be archived only.
Build Zammad and GLPI in a pilot instance
Deploy Zammad for agent ticketing and GLPI for ITIL processes and asset records in a pilot environment inside your own infrastructure, using the open-source releases and your chosen database and storage design. Configure groups, roles, SLAs and notification templates from the mapping document. Confirm the integration needs with each vendor or the project team, because Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, not Jira. The check is that a test ticket can move through every mapped state and trigger the expected notifications.
Import a sample through a mapped script
Because no built-in Jira migrator is listed for Zammad or GLPI, write or commission a mapped import that reads the Jira export and creates tickets, users and comments through each platform's API or import interface. Start with a small sample that includes closed tickets, open tickets with attachments, and tickets with unusual statuses. Compare record counts, timestamps, author names and attachment checksums against the source archive. Users need a decision on passwords, since they must be recreated or invited rather than copied. The output is a reconciliation report signed off by the service owner.
Run both systems in parallel
Keep Jira Service Management live for existing requests while new requests go to the pilot, and route selected teams to the new tools for a defined trial period agreed in your change plan. Track duplicate tickets, missed notifications, SLA breaches and user feedback in a shared log. Re-run the mapped import for records created during the trial so that the target holds the latest data. The check that closes this step is a clean log with no open issues in severity-one categories.
Cut over to the new platforms
Freeze new requests in Jira, run the final incremental import, and reconcile counts and attachments against a fresh export. Update email addresses, forms, integrations and monitoring to point to Zammad and GLPI, then announce the switch to requesters and agents. Keep a rollback path documented until the reconciliation is accepted by the service owner. The output is a signed cutover record with the time of the freeze, the final export checksum and the names of the people who approved the switch.
Decommission Jira and retain archives
After the agreed stabilization period, disable Jira Service Management users and integrations, and retain the verified archive and reconciliation reports according to your records retention schedule. Note that Atlassian's Data Center licenses become read-only on March 28, 2029, so any Data Center estate needs its own exit date recorded. Remove the vendor subscription only after the retention copy has been restore-tested. The final check is a written decommission record that names where each archive is stored and who can access it.
Keeping ticket data in your own infrastructure
Self-hosting puts the ticket history, requester details, attachments and asset records for your Jira Service Management replacement inside infrastructure you control. With Zammad or GLPI installed in your own cloud accounts, data center or air-gapped network, the application database, file storage and backups stay under your access controls, logging and retention rules. That matters when ticket content includes employee personal data, customer identifiers or security incident details that your data protection and sector rules govern. Decide early which network zone hosts the application, the database and the backup copies, and confirm that the backup target sits under the same residency terms as the primary data.
Hosted options change who holds the data, so read the residency terms instead of assuming them. Zammad GmbH's hosted plans run in German data centers, which may suit an EU residency requirement, but the contract, sub-processors and support access model still need review. GLPI Network is the hosted offering from Teclib', the company that edits and maintains GLPI, and it includes a free 45-day trial. A trial is a useful way to test workflows, but it is not a decision about where production asset data will live. Ask each vendor in writing where data is stored, where backups are kept, who can access the environment for support, and how deletion works at contract end.
Before you sign anything, write down the data classes your replacement will hold and map each one to a location and an owner. Confirm with the vendor whether a hosted plan can be moved, what export formats exist if you leave, and whether a self-hosted deployment can be later connected to a hosted one. Your own security team should also confirm how administrator access, encryption at rest and log retention are handled in each option. These answers, not the product name, determine whether ticket data stays within the boundary your auditors and regulators expect.
What you give up when leaving Jira Service Management and how teams work around it
Moving off Jira Service Management rarely fails on ticket storage. It fails on the things around the tickets: add-ons, linked asset data, documentation links, automation logic and the vendor-operated service behind them. Each card below names one likely loss, the workaround teams usually choose, and what to confirm in your own environment before you commit.
Marketplace app functionality
Many Jira Service Management sites depend on Atlassian Marketplace apps for approvals, reporting, form logic or integrations. Those apps do not move with a Jira Cloud backup, and most have no direct equivalent in Zammad or GLPI. The usual workaround is to list every installed app, classify it as core, replaceable or unnecessary, and rebuild only the core ones with native features, plugins or small integrations. Confirm each app's data model with its vendor, since some store data that never appears in a standard export.
Jira Assets relationships
Jira Assets links configuration items, owners and services to tickets. Atlassian's cloud backup excludes Assets, so those relationships must be exported separately or rebuilt. GLPI covers asset inventory and configuration management natively, which makes it the more likely home for this data. Ask your team to document which asset types link to which tickets, then map each type to a GLPI item class before any data moves.
Confluence-linked knowledge
Service desk articles often link to Confluence pages, and those links break once Jira is gone. The usual approach is to decide which pages remain the source of truth, export or copy the rest into the new knowledge base, and rewrite links in ticket templates. Check whether your Confluence content is licensed for export and whether attachments and page history matter for your audit trail.
Automation rule parity
Jira automation rules route tickets, set fields, trigger notifications and call external systems. The Jira Cloud backup does not include automation rules, so every rule must be recreated. Teams usually inventory rules by trigger, sort them by business owner, and rebuild the high-value ones as Zammad triggers, schedules or GLPI rules. Test each rule against sample tickets, because SLA timing and escalation paths rarely behave identically across platforms.
Vendor-managed upgrades and hosting
Atlassian runs Jira Cloud, applies upgrades and operates the infrastructure. Self-hosting moves patching, backups, database maintenance and certificate renewal to your team or an implementation partner. Decide who owns each task on a written runbook, set a patch cadence your security team accepts, and confirm backup and restore tests on a schedule. Your own change and capacity records should show the effort before cutover.
Vendor-backed uptime commitments
A commercial subscription typically comes with a vendor's service commitment and support path. Self-hosted Zammad and GLPI have no default uptime commitment, so availability depends on your design, monitoring and staffing. Zammad GmbH sells support contracts for self-hosted installations, and the Business, Enterprise and Corporation tiers differ in scope. Ask each support provider for its response terms in writing, and confirm them against your own incident severity model.
Which option fits your Jira Service Management situation
This tab fits an internal IT service desk that needs incident, problem and change records tied to an asset inventory and configuration data. GLPI is free asset and IT management software under GPL-3.0, covering ITIL incident, problem, change and service level management, along with asset inventory, configuration management, a knowledge base and contract management. Teams in this situation usually care most about how their asset data and change approvals map across.
- ITIL coverage: Confirm which incident, problem and change workflows your team runs today and whether GLPI's built-in process matches them without custom development.
- Asset and configuration data: Check how Jira Service Management assets and linked configuration items will be rebuilt, since Jira Cloud backups do not include Assets.
- Automation: Jira automation rules and third-party apps are excluded from Jira Cloud backups, so list every workflow that depends on them.
- Maintenance: GLPI is edited and maintained by Teclib', which also offers a hosted service, so compare self-hosting effort against that option.
- Trade-off: The configuration work is front-loaded. Expect more setup of catalogs, rules and asset types than a ticket-only tool requires.
Ask your team to list the five workflows that generate the most tickets, then test each one in a non-production GLPI instance before you commit.
This tab fits teams whose main volume is email and channel-based tickets from agents and customers, with less need for a configuration database. Zammad is licensed under GNU AGPLv3 and its source code is owned by the Zammad Foundation, independent of Zammad GmbH, which develops it with the community. It is a ticket-first platform, so the work centers on queues, agent workflows and customer communication.
- Ticket workflow: Confirm that shared inboxes, SLAs and macros cover how your agents actually work, and test them with real sample tickets.
- Licensing model: The source is open, and Zammad GmbH sells hosted plans in German data centers plus support contracts for self-hosted installations named Business, Enterprise and Corporation.
- Asset depth: Zammad does not replace an asset or CMDB system. If you need those records, pair it with another tool or choose the GLPI tab.
- Migration path: Zammad's built-in migrator covers Freshdesk, Kayako, OTRS and Zendesk, but not Jira Service Management, so plan a custom export and import for Jira data.
- Trade-off: Support and hardening move to your team or a support contract, and reporting depth should be validated against your current dashboards.
Confirm with your team whether the migration of open tickets is required or whether a clean cutover with archived history is acceptable.
This tab fits organizations that run both internal IT service management and external or agent-facing ticketing, and want to avoid losing either workflow. Running GLPI for ITIL records and assets alongside Zammad for ticket handling splits the work between two tools, each licensed under an open-source license. The integration between them is the main design question.
- Clear ownership: Decide which tool is the system of record for incidents, changes and assets, so the same ticket is not maintained in both places.
- Integration work: Define how requests move between the two platforms, whether by API, email or a manual process, and budget that as build effort.
- Operations: Two platforms mean two upgrade cycles, two backup routines and two sets of access controls to document.
- Reporting: Confirm how combined service level and volume reports will be produced, since neither tool replaces the other's data.
- Trade-off: Two systems give more capability but more to operate, so this fits teams with the staff to run both.
Write a one-page ownership map that names the system of record for each record type before you request a quote from any implementation partner.
This tab fits organizations that must keep ticket, asset and personal data within a specific country, region, cloud account or private network. Self-hosting both GLPI and Zammad places the data in infrastructure you choose, rather than in a multi-tenant vendor service. The residency question depends on where the servers run, not only on the software license.
- Hosting location: Decide whether the platform will run in your own data center, a private cloud account in an approved region, or an air-gapped network, and document it.
- Hosted options: If you consider a vendor-hosted plan, confirm where the data is stored. Zammad GmbH states that its hosted plans run in German data centers.
- Backups and copies: Backups, search indexes, attachments and email logs are often stored in other locations, so include them in the residency review.
- Staff access: Identify who can access the database and file storage, and whether support engineers from any vendor can reach production data.
- Trade-off: Self-hosting moves hosting, patching and monitoring responsibility to your team, which adds recurring operating effort.
Ask your data protection or compliance lead to map every data store and access path, then share that map with any implementation partner before scoping work.
This tab fits teams whose main driver is a renewal date, a licensing change or concern about being locked into one vendor's data format. Atlassian stopped selling new server licenses on February 2, 2021 and ended support for server products on February 15, 2024. It also 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. Those dates set the planning horizon.
- Export before you decide: Jira Cloud's backup manager includes work items, comments, users, groups and project configuration, but excludes automation rules, third-party apps and Assets. Test an export early to see what is missing.
- Attachments: With attachments included, Atlassian requires 48 hours between backups, which affects how you schedule a final export.
- Open formats: Confirm that the target platform can import the exported data, and check which fields map directly and which need transformation.
- Parallel running: Plan whether the old and new systems run side by side for a period, and how that period is paid for.
- Trade-off: A clean cutover is simpler but leaves less room to recover missed data.
Ask Atlassian and your implementation partner to confirm the Data Center end-of-life dates that apply to your contract before setting a migration deadline.
Questions buyers ask before moving off Jira Service Management
How much effort does moving off Jira Service Management take?
Effort depends mostly on how much configuration your Jira Service Management instance carries: workflows, custom fields, request types, queues, SLAs, approvals, automation rules, integrations and Assets. Each of these needs to be mapped, rebuilt or retired on the target platform. Ticket volume matters less than complexity, because a simple queue with a large history migrates more easily than a heavily customized workflow with few tickets. The outer deadline is set by Atlassian's timeline: Data Center licenses expire and become read-only on March 28, 2029, so the plan should leave room for parallel running, testing and cutover. Ask any partner for a written scope that counts your queues, workflows, automation rules, integrations, Assets object types and active users before agreeing on a timeline. Read Atlassian's Ascend announcement for the official dates.
Can our team run Zammad and GLPI without an outside partner?
Yes, many teams do, provided they have the skills to operate the platforms themselves. Zammad and GLPI are both open-source and self-hosted, so your team owns the servers, databases, backups, upgrades, access control and security patching. Zammad is licensed under AGPLv3 and GLPI under GPL-3.0, which means the software itself carries no license fee. The real questions are whether you have Linux, database and web application operations skills, a tested backup and restore routine, a patching schedule, and staff who can handle configuration changes after go-live. If any of these gaps exist, you can buy support or an implementation engagement for specific parts of the work. Confirm the support tiers and response terms directly with Zammad GmbH and Teclib' before you decide which model fits.
What do we need from our internal staff during a migration?
Internal staff provide the business decisions that no tool or partner can make for you. Plan for the following roles to be named and available during the project:
- Process owners for incident, request, change and problem management, who confirm which workflows survive the move.
- A Jira administrator who can run exports, explain the current configuration and sign off on the mapping.
- Data owners who decide which closed tickets, attachments and users must be kept and for how long.
- Approvers and test users from service desk, IT operations and the business who run realistic test cases before cutover.
- Infrastructure staff who provide hosting, network access, identity integration and backup targets.
Agree these time commitments in writing before the project starts, so that the migration does not depend on people who are already busy with daily support.
Are Jira Cloud backups enough to migrate our service desk data?
On their own, Jira Cloud backups are usually not enough. Atlassian's backup manager for cloud includes work items, comments, users and groups, and project configuration. It excludes automation rules, third-party apps and Assets, so those must be exported, documented and rebuilt through other means. If you include attachments, Atlassian requires 48 hours between backups, which affects how you plan the final delta before cutover. A backup is also a restore point rather than a migration format, so you still need a mapping from Jira fields, statuses and request types to the target platform. Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, and the Jira import path must be confirmed with Zammad before you assume it exists. Review Atlassian's export documentation and test a restore in a separate environment first.
How do we buy support for Zammad and GLPI?
Support is bought from the company that develops each product, and the options differ. Zammad GmbH sells hosted plans run in German data centers and support contracts for self-hosted installations, named Business, Enterprise and Corporation. Compare the response terms, included services and contract length in the current price sheet before you sign. GLPI is edited and maintained by Teclib', which also runs GLPI Network as a hosted cloud offering with a free 45-day trial. Because GLPI is free software, the license cost is zero, but you may still pay for hosting, support, integration and training. Ask each vendor for a written quote that lists what is included, who answers incidents, and what happens to support if you upgrade or customize the platform. You can also buy implementation help from a separate partner, so keep product support and project work in separate line items.
How should we handle automation rules and Assets after leaving Jira?
Treat automation rules and Assets as separate work packages, because the standard Jira Cloud backup does not carry them. Start by exporting or documenting each automation rule with its trigger, conditions, actions and owner, then sort them into three groups: rules to rebuild, rules to replace with native features on the target platform, and rules to retire. For Assets, document the object types, attributes, relationships and the people who maintain them. GLPI already covers asset inventory, configuration management and contract management, so Assets data often maps there, but the exact model needs a workshop with your configuration owners. Zammad's migrator is all or nothing, works only on a new instance and accepts one source system per migration, so plan these rebuilds as post-migration tasks. Confirm each mapping in a test instance before production cutover.
What does a fixed-scope DeployOpen engagement cover?
A DeployOpen fixed-scope engagement covers planning, implementing, customizing, integrating, hardening, backing up, upgrading, documenting and supporting self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Scope, deliverables and timelines are agreed in writing before work starts, so you can see what is included and what is excluded. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers after the initial project. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. DeployOpen is not an official partner or reseller of Zammad, GLPI or Atlassian, so confirm any vendor-specific terms directly with each vendor.
How DeployOpen scopes, migrates and supports the replacement
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is the client's cloud accounts, data centers or air-gapped networks. For a Jira Service Management replacement, that means the target stack (for example Zammad for agent ticketing, GLPI for ITIL and assets, or both), the hosting layer, identity integration, backup and restore paths, and the cutover plan are all designed and run in the environment the client controls. DeployOpen does not issue audit reports, attestations or certifications. Where a compliance assessment is involved, DeployOpen prepares the systems, controls and evidence, and an independent auditor or certification body performs the assessment.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this migration, the written scope should name which Jira Cloud data is in play (work items, comments, users and groups, and project configuration are included in Atlassian's cloud backup, while automation rules, third-party apps and Assets are excluded), which target platform receives each data set, and which pieces must be rebuilt by hand. A quote follows from that written scope, so the more precisely the current Jira Service Management workflows, integrations and reports are inventoried up front, the more accurately the quote reflects the work. Ask for the quote to break out discovery, data mapping, migration rehearsal, cutover, documentation and hand-over as separate line items so each can be accepted or deferred.
Ongoing operation is available as a retainer covering support, upgrades and continuous testing after cutover. Ask in the scope conversation who applies platform upgrades, how security patches reach a self-hosted Zammad or GLPI instance, and what happens to the backup schedule once Jira Cloud is retired. Confirm the current version and release notes with each vendor before planning upgrades, since GLPI and Zammad publish releases on their own schedules.
