Self-hosted Jira Service Management alternative for EU data sovereignty

Why a self-hosted Jira Service Management alternative for EU data sovereignty is a compliance decision

A self-hosted Zammad or GLPI instance on EU infrastructure can keep ticket data under your organization's control, but only once you decide which data and which staff access must stay in the EU. That decision starts with a gap in Atlassian's residency model. Region pinning for Jira Service Management Cloud covers product data on the Standard, Premium and Enterprise plans, while user account data falls outside that scope. For a service desk lead, the question is therefore both where tickets are stored and where requester and agent identities are held and processed, because account records are personal data under the GDPR. Ask Atlassian in writing which of your data categories the region setting covers and where the account directory is stored.

The gap matters for transfer analysis. The EDPB's Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support, is a transfer, and so is storage in a cloud outside the EEA. Article 44 of the GDPR applies to every such transfer, including onward transfers, and infringements carry fines of up to EUR 20 million or 4% of worldwide annual turnover. Support staff or vendor engineers outside the EU who can view tickets or accounts therefore belong in your data map. The U.S. CLOUD Act also reaches providers' data regardless of where it is located, so an EU region alone does not settle the exposure. The EU-US Data Privacy Framework adequacy decision is under appeal, so treat it as a point to monitor rather than a settled basis.

Atlassian's Data Center read-only date of March 28, 2029 is context for this review, not a compliance trigger by itself. What matters now is whether your NIS2 obligations apply to your organization, which depends on your sector and on how your national authority transposed the directive, so confirm that with counsel. Practical steps include mapping every location and role that touches tickets and accounts, deciding whether authentication stays in-house through LDAP or an identity provider over SAML or OpenID Connect, and writing down which hosting location and access model you chose and why. Those records are the evidence an auditor or regulator will ask for.

What GDPR and NIS2 require of where service desk data sits

Service desk records often contain personal data about employees and customers, so where they are stored, who can reach them and from which country they are administered all matter. The cards below set out the GDPR points that shape a self-hosted decision, and the NIS2 questions that counsel must answer for your organization.

Every third-country transfer counts

GDPR Article 44 requires that every transfer of personal data to a third country, including onward transfers, meets the conditions in Chapter V. For a service desk, this covers ticket stores, backups, log files and mail relays that leave the EEA, not only the primary database. Map each copy of the data, including the hosting provider's subprocessors, before you decide where Zammad or GLPI will run.

Remote administration is a transfer

EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. An administrator in another country troubleshooting a GLPI database therefore triggers the same analysis as a copy stored there. Confirm where your operators, managed-service staff and vendor support sit, and restrict remote sessions to approved locations.

Extraterritorial reach of US law

18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether it sits inside or outside the United States. An EU data center run by a provider that is subject to this law can still be reached. Ask hosting and support providers whether they are in scope, and document that assessment before signing.

Limits on third-country disclosure orders

GDPR Article 48 allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. A foreign order received by a provider is therefore not enough on its own. Ask providers how they handle such requests, whether they notify customers, and which contract clauses govern them.

Penalty ceiling for transfer breaches

Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, under Article 83(5)(c). Transfer failures are therefore a board-level risk, not a documentation detail. Record the transfer map, the basis for each transfer and the remote access rules in the same register as your processing records.

NIS2 duties to confirm with counsel

No NIS2 requirement has been verified for this page, so do not treat any statement here as an obligation. Ask counsel whether your organization is in scope as an essential or important entity, which security and incident reporting duties apply to the service desk, and whether supplier and hosting arrangements must be reviewed. Confirm the answers before choosing a hosting model.

How Zammad and GLPI each meet the residency constraint

Zammad is the option to evaluate first when the service desk mainly handles requests from customers or external users arriving by email, chat, forms or phone. It is licensed under the GNU Affero General Public License version 3, and its source code is owned by the Zammad Foundation, which is independent of Zammad GmbH. Because the software is self-hosted, the residency question becomes one of where you deploy it and who operates the hosting. The application stores its content in PostgreSQL 15 or newer, uses Redis 7 or newer for realtime websocket communication, and supports Nginx or Apache as a reverse proxy. Zammad documents installation with packages, Docker Compose and a Kubernetes Helm chart.

Licensing: AGPLv3 allows you to run, modify and host the software without a license fee, so the residency decision does not depend on a vendor contract.
Data stores: PostgreSQL 15 or newer holds the ticket data, so backups and replicas must stay in the same approved region.
Search and caching: Elasticsearch is optional but strongly recommended for search, reporting and attachment content, and Memcached is needed for multi-instance deployments such as containers or cluster nodes.
Deployment: Docker Compose suits smaller installations, and the Helm chart needs your own Kubernetes platform team, since Zammad support covers only the application on Kubernetes.
EU hosting option: Zammad GmbH sells hosted plans run in German data centers. Confirm the exact data location, sub-processors and support access in the contract before treating this as a residency answer.

Before you rely on either deployment, confirm in writing where every data store, backup and log copy sits and who can access them.

Deploying Zammad or GLPI in an EU data center under this constraint

This sequence takes an EU service desk from hosting choice to a verified deployment, with access, backup and update controls that keep personal data and configuration under the organization's own authority.

Choose the EU hosting location and provider
Decide whether the platform runs in your own data center or in an EU provider's facility, and record the country, operator and legal entity that controls the physical and virtual infrastructure. Ask each provider to confirm in writing that storage, backups, snapshots and logs stay in the EEA, including replicas and disaster recovery sites. Confirm whether the provider is subject to third-country law with extraterritorial reach, since that exposure belongs in your transfer assessment. The step is done when you hold a signed data location statement and a list of every system that will hold ticket content, attachments and user records.
Confirm where support staff and vendors access data
List every party that can see ticket content from outside the EEA, including your own administrators working remotely, the hosting provider's operations staff, and any vendor support engineer who connects to a live instance. Remote access from a third country counts as a transfer under EDPB Guidelines 05/2021, even when the person only views data on screen. Agree access paths in advance, such as named EU-based administrators, time-limited vendor sessions approved by your team, and logged jump hosts. The step is done when the access register is signed off by your data protection lead and security owner.
Build the stack with a reverse proxy and TLS
Install Zammad with its documented Docker Compose or Kubernetes Helm method, or install GLPI on a supported PHP and database stack. Zammad needs PostgreSQL 15 or newer and Redis 7 or newer, with Nginx or Apache as the reverse proxy. GLPI needs PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later on the current line, and its document root must point to the public directory with URL rewriting to index.php. Terminate TLS at the reverse proxy with certificates from your own certificate authority or a trusted EU issuer. On Kubernetes, the Zammad project supports only the application, so cluster-level issues stay with your platform team. The step is done when the application loads over HTTPS and the database and cache connections are confirmed.
Configure SAML or OpenID Connect against your identity provider
Connect sign-in to your own identity provider so user accounts and credentials stay under your directory. Zammad supports SAML and OpenID Connect among other providers, so register the application in your identity provider and map the attributes Zammad needs for roles and groups. For GLPI, configure LDAP or IMAP authentication, tried in the order of internal database, LDAP, IMAP and other external methods, and disable local fallback accounts for everyday users once SSO is proven. Keep one break-glass administrator account under documented control. The step is done when a test user signs in through the identity provider and an unassigned user is refused.
Set up backups that include glpi.key and glpicrypt.key
Schedule encrypted backups in the EU location for the database, attachments and application configuration. For GLPI, include the config directory with glpi.key and glpicrypt.key, because the update procedure requires them and encrypted data cannot be recovered without the matching keys. Store backups separately from the live system and restrict restore rights to named administrators. Note that the Jira Cloud backup exclusions do not apply here, but you must define your own scope for automation rules, plugins and custom fields. The step is done when you have completed one restore into a test environment and confirmed that tickets, attachments and logins work.
Apply the GLPI update procedure
Before each GLPI upgrade, back up the database, the files and the config directory, then replace the application files and run the update console command, which the installation documentation gives as php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected, so review each plugin and reactivate it deliberately after major updates. Test the upgrade in a staging copy first, and record the version and date. The step is done when the target version reports as active, plugins you need are re-enabled, and a smoke test of ticket creation and login passes.
Plan the Zammad migrator constraints into the cutover
If you are importing from a source that Zammad's built-in migrator supports, such as Zendesk, Freshdesk, Kayako or OTRS, plan for its limits. Migrations are all or nothing, work only on a new instance, accept one source system per migration, and do not support differential runs. Zendesk migration needs a full administrator to create an API token, and user passwords are not migrated. Any other source needs the Zammad API or custom development. The step is done when a cutover plan states the freeze window, the rollback path and who verifies imported counts.
Verify logs and access before go-live
Enable application, proxy and database logs, send them to a central store in the EU, and set retention in line with your policy. Confirm that failed logins, administrative actions and access by vendors are captured and that someone reviews them on a fixed schedule. Test that the access register from the earlier step matches actual accounts and that remote sessions are recorded. Ask your compliance lead to confirm which evidence will support your GDPR records and NIS2 incident handling, since this page does not establish either. The step is done when a test incident appears in the logs and the signed access register matches live accounts.

Keeping the exit path open under the Data Act

The EU Data Act gives customers of data processing services a right to switch to another provider or to on-premises ICT infrastructure, and that right matters for a service desk whose records sit in a vendor's cloud. The Data Act has applied since 12 September 2025. Under its switching provisions (Articles 25, 29 and 50 of Regulation (EU) 2023/2854), the switching notice period can run to a maximum of two months, the transition period is 30 days, and switching charges are banned from 12 January 2027. Before you rely on these terms, ask your Atlassian account team in writing which contractual switching terms apply to your subscription, and confirm how they map onto the notice and transition periods in the regulation. The Data Act text on EUR-Lex is the primary reference for your legal team.

A switching right does not move data by itself. Jira Cloud's backup manager covers work items, comments, users and groups, and project configuration, but it excludes automation rules, third-party apps and Assets. A customer who relies only on that backup would leave with tickets but without the logic that routes them, the apps that extend them, or the configuration items that give requests their context. Build an inventory of automation rules, installed apps and Assets object schemas now, and export each one separately while the subscription is active. Keep the exports in your own EU storage, record the checksum of each file, and test a restore into a non-production GLPI or Zammad instance so the gaps are visible before any deadline forces a move.

Plan the exit as a dated project with named owners for legal, data protection and service management. Your data protection officer should record the switch as a processing activity change, and your procurement team should check that the self-hosted target has a documented retention and deletion routine for the data it receives. Treat the Data Act right as the lever for an orderly move, not as proof that a move will be quick. Ask any implementation partner for a written scope that lists the exports, the mapping of each request type and SLA, and the acceptance tests, and confirm the timeline in that scope rather than assuming it.

Evidence to collect for a data residency review

A data residency review on a self-hosted service desk is judged on paper as much as on infrastructure. The five artifacts below connect where data sits, who can reach it from outside the EEA, what contracts bind your suppliers, and whether you can restore it. DeployOpen prepares this evidence, but auditors and regulators issue any opinion on it.

Data map of every store

List where tickets, attachments, user accounts, audit trails and logs are stored, which region or data center holds each one, and which application component writes to it. For Zammad, that means PostgreSQL, Elasticsearch, Redis and the file store. For GLPI, it means the MySQL or MariaDB database, the files directory and the config directory with its key files. Include any mail relay and identity provider that holds user records, because user account data is often the part left out of vendor residency statements.

Transfer assessments for third-country access

Record every path by which someone outside the EEA could view or retrieve personal data, including remote support sessions, follow-the-sun administration and backup replication. EDPB Guidelines 05/2021 treat even screen display for support as a transfer. Document the assessment, the transfer tool relied on and any supplementary measures, and note where a provider is subject to third-country law with extraterritorial reach.

Supplier and hosting contracts

Collect the data processing agreements with your hosting provider, support vendor and any managed service, together with the standard contractual clauses adopted under Commission Implementing Decision (EU) 2021/914 where a transfer is possible. Check sub-processor lists, the locations named for support access and the notice a provider gives before changing them. Confirm these terms with each supplier in writing, because clause wording and annexes vary.

Backup and restore records

Keep dated records of each backup, where the copies are stored, who can read them and the result of the most recent restore test. For self-hosted GLPI, the update procedure already calls for backing up the database, files and config directory, including the glpi.key and glpicrypt.key files, so keep those backups in the same evidence set. A backup copy outside the EEA counts as a storage location in your data map and needs the same assessment as the primary copy.

Administrator and access logs

Export the authentication logs, administrator actions and privileged session records for the service desk, and keep the retention period you set for them. Confirm which of these logs your platform writes natively, which need a shipping pipeline and where that pipeline sends them. Access logs show whether any non-EEA identity or support account touched personal data, so they should be reviewed against the transfer assessments above.

Questions EU service desks ask before choosing self-hosted ITSM

Does self-hosting Zammad or GLPI remove GDPR transfer exposure?

No. Self-hosting removes the vendor's cloud as a default location for your data, but a transfer under GDPR depends on where anyone accesses the data from. Under the EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, and so does storage in a cloud outside the EEA. Map every administrator, support engineer, backup location and plugin or SaaS integration that touches tickets, then check each one against Chapter V. If you engage an EU provider that is subject to third-country law, assess whether it could be compelled to hand over data, because the same guidelines treat complying with a third-country authority request as a transfer.

What effort does a self-hosted service desk actually require?

Effort falls into one-time work and recurring work. One-time work includes sizing, installing, configuring authentication, migrating records, testing and writing runbooks. Recurring work includes patching, backups, monitoring, upgrades and user administration. For Zammad, the stack includes PostgreSQL 15 or newer, Redis 7 or newer, a reverse proxy and, for search, Elasticsearch, which the requirements describe as optional but strongly recommended. GLPI requires PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later on the current main branch, and its update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key. Ask your team to name the owners for each of these layers before you commit.

What drives the total cost of self-hosting ITSM in the EU?

The main drivers are the number of agents and end users, the volume of tickets and attachments, the number of integrations, the availability target, the hosting location and the staff hours needed to run the platform. Software licensing is zero for both Zammad and GLPI, so the cost sits in infrastructure, staff time, optional vendor support, and migration work. Vendor support is optional. 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 its pricing page. Ask any provider to split a quote into one-time and recurring lines, and to state which hosting, backup and support items are included.

What does a Zammad self-hosted support contract cover?

Zammad sells support subscriptions for self-hosted installations at three levels: Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to Zammad's pricing page. The subscription is a vendor support agreement for the software, and it does not operate your server, patch your database, or hold your data. Before buying, confirm with Zammad what each tier includes in response times, channels, upgrade help and the number of contacts. Compare that with what your internal team can already handle, and with any independent implementation or retainer support you may need on top.

Can our own team run a self-hosted service desk without outside help?

Often yes, if you already run Linux servers, a relational database, a reverse proxy and regular backups. The gaps usually appear in less common areas: container orchestration, SAML or OpenID Connect integration, email channel configuration, security hardening and evidence collection for audits. Assess your team against those specific skills, identify the single person who would own each one, and plan for absence cover. Outside help can be scoped as a fixed-scope engagement for planning, implementation, hardening, backup design and documentation, followed by a retainer for upgrades and support if you want it. DeployOpen does not run your service desk for you unless the written scope says so.

What should we ask for in a written quote for a migration?

Ask for a written scope that lists each system, its version, and the hosting location for every component. Require the quote to name the data sources, the migration path (Zammad's built-in migrators cover Freshdesk, Kayako, OTRS and Zendesk, while Jira Service Management needs an API-based import), and what is excluded, such as automation rules, apps and Assets. Ask for deliverables, acceptance criteria, the testing approach, a cutover plan, backup and rollback steps, the responsibilities split between your team and the provider, and the list of data processing locations and access paths for GDPR purposes. Ask for the timeline in writing, with the assumptions behind it, because no migration duration is set in this guide and it depends on scope.

How long does migrating from Jira Service Management take?

The duration depends on the number of tickets, attachments, users, queues, automation rules, apps and integrations, and on how much history you must keep. There is no fixed figure for this migration. Zammad's migration documentation notes that its migrators run all or nothing, work only on a new instance and accept one source system per migration, so plan for test runs and a cutover window. Atlassian's Data Center end-of-life dates may shape your deadline, since Data Center subscriptions stop being sold to new customers on March 30, 2026 and licenses become read-only on March 28, 2029. Ask any provider for a timeline tied to a named scope and a test plan, and confirm assumptions about data volume before you accept it.

What DeployOpen does and does not deliver for residency work

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure or inside an EU provider's data center that you contract for. For a Zammad or GLPI move, that work typically covers the database and cache tiers, the reverse proxy and TLS, the document root and URL rewriting for GLPI, backup and restore procedures, role and access design, and the written runbook your operations team keeps after handover. The residency decision itself, including which provider, which region and which subprocessors, stays with your organization and your legal counsel. DeployOpen can document the controls that result from that decision, but it cannot make a provider's contract or jurisdiction comply on your behalf.

DeployOpen also runs security testing against the deployed application, its APIs and the surrounding cloud or infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Where your obligations under GDPR or NIS2 call for an independent assessment, an auditor or certification body performs it, and you should confirm early which evidence that body expects so the engagement produces it. Ask DeployOpen to state in writing which artifacts it will hand over and which remain your responsibility to collect.

Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that scope rather than from a published price list. Ongoing support, upgrades and continuous testing are available as retainers. When you request a quote, specify the hosting location, the number of agents and requesters, the systems to integrate, and the evidence your assessor needs, because those inputs drive the effort. Confirm which items are one-time and which recur, and ask how a retainer would cover the GLPI or Zammad version upgrades that the release cycle requires.

How DeployOpen deploys Zammad or GLPI under EU residency rules

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including EU cloud accounts, data centers or air-gapped networks. For an EU service desk, that means fixing where every ticket, attachment and user record is stored before choosing between Zammad and GLPI.

How we scope

Map which personal data, ticket attachments and user accounts would sit in each hosting location and who can access them
Record the data flows for remote support and administration, since remote viewing from a third country can count as a transfer
Agree deliverables, timelines and responsibilities in writing before work starts, as engagements are fixed-scope

How we build

Deploy Zammad or GLPI in the agreed EU environment with PostgreSQL or MariaDB, Redis or Memcached and the reverse proxy set up per vendor requirements
Configure sign-in through the client's own identity provider, such as SAML or OpenID Connect for Zammad or LDAP for GLPI
Test backup, restore and update procedures, including GLPI's key files and plugin reactivation steps, before go-live

How we hand over

Deliver architecture, data location and access documentation that the client's privacy and security teams can review
Provide runbooks for updates, backups, migrations and incident handling, with the data migration checks performed against the source export
Prepare control evidence for compliance assessments; independent auditors and certification bodies issue any audit reports or certifications

How we support

Offer ongoing support, upgrades and continuous security testing as retainers after handover
Track vendor security releases for the chosen Zammad or GLPI line and plan updates in your change windows
Confirm with your legal counsel and data protection officer the transfer assessment and NIS2 obligations that apply to your organization