Freshdesk alternative for EU data residency

Which self-hosted Freshdesk alternative keeps EU support data in the EEA

If a DPO, CISO or IT lead must show where customer support tickets are stored and processed, the most direct answer is to run self-hosted Zammad or FreeScout in a data center inside the EEA, either in your own facility or with an EU infrastructure provider. Zammad GmbH's hosting in German data centers is the alternative if you want the software vendor to operate the service. The software alone does not settle the question. What decides whether personal data leaves the EEA is who operates the servers, where backups and logs are kept, and who can reach the systems from outside the EEA. Under the EDPB's *Guidelines 05/2021*, remote access from a third country, even only displaying data on a screen for support, counts as a transfer, so an operator's support staff location matters as much as the storage location.

Freshdesk's EEA region choice at signup does not remove this question, because moving regions requires a request to Freshdesk support and the reader still needs to document the processors, sub-processors and access paths behind the service. With self-hosting, the controller writes those answers itself. Start by listing every component that holds ticket content: the application server, the PostgreSQL database, Redis, any Elasticsearch index used for search and attachment content, file storage, mail relays, and backups. For each one, record the physical location, the operator, and the people or remote administrators who can open it. Ask any EU hosting provider whether its staff, its own sub-processors or its parent company can access the data from a third country, and get the answer in writing. Also check whether the provider is subject to third-country law with extraterritorial reach, since the EDPB's Example 12 says that exposure should be assessed before engaging such a processor.

Plan the migration with residency in mind as well. The Freshdesk migrator in Zammad imports into a new instance only, so build that instance in the EEA from the start rather than importing into a test system elsewhere. Keep the Freshdesk XML export, which is available on every plan, as a fallback copy stored in your EEA environment, and confirm with your DPO how long that copy may be retained. Confirm with Zammad GmbH or your provider the exact data center, backup location and support access model before you sign, because these terms, not the license, determine your transfer position.

What EU data residency requires of a help desk

Choosing an EEA region at signup does not settle every data residency question. The GDPR and EDPB guidance treat storage, remote viewing and third-country authority access as separate exposures, and each one reaches ticket bodies, attachments and the staff who answer them.

Chapter V applies to every transfer

Under Article 44, any transfer of personal data to a third country, including onward transfers, must meet the Chapter V conditions. For a help desk, the question is whether any copy of a ticket, attachment or customer record leaves the EEA, including backups, logs, search indexes and vendor-side support tooling. Map each store and each processor to a location before you sign anything.

Remote display counts as a transfer

The EDPB's Guidelines 05/2021 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 engineer in another country who troubleshoots a ticket queue or opens an attachment is therefore part of the transfer analysis, not only the storage location. Ask vendors where their support staff sit and how they reach your instance.

Cloud storage outside the EEA

The same guidance treats storage in a cloud outside the EEA as a transfer. A help desk hosted in an EU region can still send backups, object storage for attachments or log shipping to a non-EEA location, so check each component separately. Confirm the exact region for database, file storage and backup targets, and whether any managed add-on replicates data elsewhere.

Fines for Articles 44 to 49

Infringements of Articles 44 to 49 fall under the higher tier of GDPR fines: up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, under Article 83(5)(c). The exposure sits with the controller who chose the processor and the transfer path, so the contract and the architecture diagram matter as much as the vendor's marketing. Keep records showing how each transfer was assessed.

Third-country authority exposure

EDPB Guidelines 05/2021 (Example 12) explain that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be one. Before engaging such a processor, assess how likely a foreign disclosure order is and whether it could reach your data. The 18 U.S.C. 2713 provision is one example of law that applies regardless of data location, so ask vendors how they handle these requests.

Self-hosting narrows the exposure

Running Zammad or FreeScout in your own data center, or with an EU provider you contract directly, keeps ticket storage, attachments and admin access under your control. You still need to confirm where backups, email relays and any vendor support sessions terminate. Put the data flow for each component into your records of processing before go-live.

What Freshdesk's region choice settles and what it leaves open

Freshdesk lets you select an EEA data center at signup, and moving to another region means contacting Freshdesk support. The region is therefore set at onboarding and is not something an admin changes in the product. That settles where your primary ticket data is stored, provided your account was created in an EEA region. It does not settle everything else. Before you load customer data, ask your Freshdesk account team to confirm in writing which region your account is in, and whether attachments, exports and backups are held in that same region. Record the answer in your records of processing so the decision is traceable.

Storage location is only one part of a transfer. The EDPB's Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support or administration, is a transfer, and so is storage in a cloud outside the EEA. Ask Freshdesk where its support staff and engineers access your data from, which sub-processors are involved in hosting, support tooling and email delivery, and where each one is located. Ask whether any sub-processor can reach your data from outside the EEA, and how you will be notified when that list changes.

Contract terms decide whether those flows are lawful. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet the Chapter V conditions. Ask whether your data processing agreement incorporates the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914 and which module applies. If any US sub-processor is involved, ask whether it is on the Data Privacy Framework List. That adequacy finding is under appeal in Case C-703/25 P, so treat it as a supporting argument, not the only basis. Put the answers in a single written list with dates and send it to your legal and privacy teams.

Which open-source help desks fit an EU residency constraint

This table compares self-hosted Zammad, self-hosted FreeScout and Zammad GmbH's hosted plans on licence, data location, operator and trade-offs. Residency depends on where the servers sit and who can reach them, so use the rows as a checklist to confirm with each vendor or provider in writing.

Criterion	Self-hosted Zammad	Self-hosted FreeScout	Zammad GmbH hosting in Germany
Licence	GNU AGPLv3, with no license fee for self-hosted use	AGPL-3.0 core, with paid lifetime modules for knowledge base, SAML SSO and workflows	Hosted service under Zammad GmbH's commercial plans
Where data is stored	Wherever you place the servers, such as your data center or an EU provider	Wherever you place the server and database, with no vendor hosting	German data centers, as stated on the pricing page
Who operates the platform	Your team or your implementation partner	Your team or your implementation partner	Zammad GmbH, under its hosted plan terms
Core data stack	PostgreSQL 15 or newer and Redis 7 or newer for realtime updates	PHP on Laravel with MySQL, MariaDB or PostgreSQL	Managed by the provider; confirm versions in the contract
Search and scaling	Elasticsearch is optional but strongly recommended; Memcached is needed for multi-instance deployments	No Elasticsearch requirement; no minimum CPU or RAM in the README	Confirm search and capacity options in the plan
Support access to data	Under your control, so restrict and log any vendor access	Under your control, so restrict and log any vendor access	Confirm in writing who at Zammad GmbH can access production data and from where
Main trade-off	Strong fit for large teams, but needs PostgreSQL, Redis and search operations	Lightweight and low cost, but module features and scale need checking	Lowest operations load, but residency depends on contract terms, not your own servers

How hosting model changes the transfer exposure

When you run Zammad or FreeScout in a data center you control inside the EEA, the personal data stays with you as controller and your own staff hold administrative access. The main exposure shifts to the vendors and sub-processors you still use, such as email relays, backup services, monitoring tools and support tooling, because any of them that can reach the data may create a transfer. Check each one for remote access from outside the EEA, since the EDPB guidelines treat even displaying data on a screen for support as a transfer.

Data holder: Your organization stores the database, attachments and search indexes in premises or leased racks you operate.
Administrative access: Your administrators hold root and database access, and vendor engineers only see data if you grant a remote session.
Third-country law: Confirm that no service provider in the chain is subject to a US parent company that could receive a CLOUD Act request under 18 U.S.C. 2713.
Backups and offsite copies: Confirm where backup repositories and replicas sit, because a cloud backup target outside the EEA is itself a transfer.
Support access: If you buy a Zammad support contract, agree in writing how vendor staff access your instance and from where.

Ask your data protection officer to document the transfer map for every hop, including those you never intended to create.

Why an EU provider still needs a transfer check

Placing a self-hosted Zammad or FreeScout instance with an EU provider does not by itself settle the transfer question. The EDPB's Example 12 in *EDPB Guidelines 05/2021* says that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer. The exposure sits in the next step: if that processor must comply with a request from a third-country authority, that compliance would be a transfer. The controller therefore has to assess that exposure before signing. Ask counsel to establish who the provider's parent company is, where it is incorporated, which courts can compel it, and whether any of its staff or support tooling sit under a non-EEA jurisdiction. Remote access from a third country, even only to display data on a screen for support, counts as a transfer under the same guidelines, so the provider's support model belongs in the review too.

The US exposure is concrete. The CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. A US-parented provider in Germany can therefore receive such an order for data it holds. Article 48 of the GDPR limits the effect of such orders: a third-country judgment or administrative decision requiring disclosure is recognized or enforced only if it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. Schrems II (Case C-311/18) invalidated the Privacy Shield adequacy decision on 16 July 2020, and the Data Privacy Framework that replaced it, under Commission Implementing Decision (EU) 2023/1795, is under appeal as Case C-703/25 P. Confirm the status of that appeal with counsel before you rely on the framework for any US-linked supplier.

Technical controls do not close this gap when the provider must read the data in the clear. EDPB Recommendations 01/2020 state that where a cloud provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption you hold the keys for, or a self-hosted instance in your own data center, reduces the question, which is why the hosting model matters more than the vendor's brand. Record the provider's jurisdictional analysis, the parent company chain and the support access model in your transfer assessment, and decide in advance whether a non-EEA parent is acceptable for the data categories you will move.

How to deploy Zammad in an EEA data center

This sequence takes a Freshdesk account from an unconfirmed hosting question to a Zammad instance inside an EEA data center, with a migrated copy, a controlled cutover and a documented fallback export.

Confirm hosting location and access model
Before any build, get written confirmation of the data center country, the operator of the facility and every party that can reach the environment for administration or support. Ask whether any remote access, support tooling or backup replication could display or copy data from outside the EEA, because remote viewing from a third country counts as a transfer under EDPB Guidelines 05/2021. Your DPO or legal team signs off on the location and access list. Done when the signed record names the country, operator, administrators and any sub-processors.
Build the core stack on PostgreSQL and Redis
Your infrastructure team provisions the application server, PostgreSQL 15 or newer, Redis 7 or newer for realtime websocket communication, and Nginx or Apache as the reverse proxy, all inside the agreed EEA environment. Install Zammad using the package, Docker Compose or Helm route your team has standardized on. Add Memcached only if you run several Zammad instances or cluster nodes, since single installations can use the file system cache. Done when the application loads over TLS and the database and Redis connections pass health checks.
Decide on Elasticsearch for search
Zammad treats Elasticsearch as optional but strongly recommended, because it powers faster search, reporting and search of email attachment content. Decide whether your support volume and reporting needs justify running it, and record the decision along with its hosting in the same EEA environment, so the index does not sit outside your data boundary. Confirm the sizing with your Zammad implementation partner or the Zammad documentation before you provision it. Done when the decision and the sizing assumptions are written down and approved.
Configure identity with SAML or OpenID Connect
Connect Zammad to your identity provider through SAML or OpenID Connect so agents sign in with corporate accounts and access can be removed centrally when someone leaves. Zammad also lists Microsoft, Google, GitHub and GitLab among its third-party login options, so confirm which provider your organization uses. Set up roles and groups that mirror your support structure, and make sure local administrator accounts are documented and protected. Done when a test agent signs in through the identity provider and a deprovisioned test account is denied access.
Migrate into a new instance with the Freshdesk migrator
Run Zammad's built-in Freshdesk migrator against a fresh instance, because the migrator works only on a new instance, is all or nothing, and accepts one source system per migration. Your team creates the source credentials in Freshdesk, runs a rehearsal on a non-production copy, and checks tickets, customers, groups and attachments against Freshdesk counts. Note that the migration does not replace later changes, so plan a single final run. Done when the rehearsal reconciles and the signed-off results are recorded.
Run a controlled cutover with an XML fallback
Freeze new configuration, run the final migration, and switch the support mailbox and channel addresses to Zammad in a planned window. Before cutover, export tickets, solutions, forums and customers from Freshdesk as XML using the account export, and store that copy in the EEA. Agents work the old and new queues in parallel for a short, agreed period while the team checks that inbound email reaches Zammad. Done when inbound mail routes correctly, the export is verified and retained, and the support lead confirms the cutover.
Document backup location, log retention and access review
Place backups, database dumps and log storage in the same EEA region and record the location in your processing register. Set log retention to match your policy and confirm that logs containing personal data stay inside the EEA. Schedule recurring access reviews for Zammad administrators, agents and the hosting operator, and confirm the review owner in writing. Done when backup restores have been tested inside the EEA, the retention settings are documented, and the first access review is recorded.

Evidence a DPO or regulator will ask for

A DPO or supervisory authority will test whether the move is documented end to end, not just claimed. The cards below cover the contracts, maps, assessments and logs that show where tickets and backups sit and who can reach them. DeployOpen prepares this evidence, but independent auditors and certification bodies are the parties that issue audit reports and attestations.

Hosting location and sub-processors

Record the data center region for the application, database, backups and any email relay, and the legal entity that operates each one. Ask every provider for its current sub-processor list and keep dated copies, because a new sub-processor can change the transfer picture. Confirm in writing that the hosting region you chose at setup is the one the platform actually uses.

Data transfer map

List every place tickets, attachments, logs and backups are stored or accessed, including remote support sessions from outside the EEA. The EDPB treats remote access from a third country, even only displaying data on a screen, as a transfer, so vendor support access belongs on the map. Review the map each time a provider, region or support path changes.

Contract clauses and standard contractual clauses

Hold a data processing agreement that covers third-country access requests and, where a transfer remains, standard contractual clauses under Decision 2021/914. Check whether the provider commits to challenge overbroad government requests and to notify you where the law allows. Have counsel confirm the clause set, because the contract is the document a regulator reads first.

Transfer assessment for each provider

For each provider that touches personal data, document the destination country's laws on government access and the supplementary measures you rely on. Under Schrems II and the EDPB Recommendations 01/2020, where a provider must read data in the clear and foreign authority powers go beyond what is necessary, a technical fix may not be enough. Record the conclusion and the date you reviewed it.

Administrator and support access logs

Keep logs of which administrators and vendor support staff opened the helpdesk, exported data, changed mailboxes or read backups, with timestamps and reasons. Ask whether support access on your instance requires a ticket, a time limit and your approval. Review these logs on a schedule, since a regulator will ask who could see customer data and who actually did.

Freshdesk export as a record of the move

Keep the Freshdesk account export of tickets, solutions, forums and customers as a dated, read-only archive that shows what was moved and what was left behind. Store it under the same access controls as production, and record the checksum and the migration report alongside it. This copy also lets you answer later questions about what Freshdesk held at cutover.

What does an EU residency move from Freshdesk cost and require?

What drives the cost of self-hosting Zammad instead of paying for Freshdesk?

The Zammad software itself has no license fee, so the cost is made of components: hosting in your own or an EU provider's data center, the migration work, administrator time, and optional support. Hosting and administration recur every year, while migration and initial setup are mostly one-time. Optional self-hosted support subscriptions from Zammad GmbH are 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 for a written quote that separates hosting, migration, administration, backup and support, so you can compare each line with your current Freshdesk plan and seat count.

Can a small team run FreeScout on its own?

Often yes, if the team is comfortable administering a PHP and Laravel application and a MySQL, MariaDB or PostgreSQL database. FreeScout runs on Nginx, Apache or IIS with PHP 7.4 to 8.x, and its README says it has no minimum CPU or RAM requirements. The free core includes unlimited agents, tickets and mailboxes, and it offers a Docker image for installation. Several features that Freshdesk customers expect, such as knowledge base, satisfaction ratings, time tracking, workflows and LDAP or SAML login, are paid modules sold as lifetime licenses for a single instance. Confirm the module list against your Freshdesk plan before deciding who will maintain it.

How long does a migration from Freshdesk to Zammad take, and what sets that time?

No duration has been established for your environment, so treat any single figure as a guess until you have a written scope. The main drivers are the volume of tickets, attachments and customer records, how many channels and mailboxes you connect, how much workflow and automation must be rebuilt by hand, and how much testing your team requires before cutover. Zammad's built-in Freshdesk migrator works only on a new instance, runs all or nothing, and accepts one source per migration, so plan a full test run before the switch. Ask for a timeline that lists each phase and the decisions your staff must make.

What does the work need from our own staff?

Your staff need to make decisions and check results, even if an outside team does the build. Expect involvement from a business owner who signs off on mailboxes, queues, roles and SLAs; an administrator who will own the server, updates and backups; and agents who test real tickets during the trial run. Zammad documents package installation, Docker Compose and a Helm chart for Kubernetes, and on Kubernetes its support covers only the application, so your platform team must own the cluster. Also confirm who holds the Freshdesk export and who will verify the imported data.

Does Zammad GmbH's German hosting remove the need for a transfer review?

Not by itself. Zammad GmbH sells hosted plans run in German data centers, which keeps storage within the EEA, but a transfer review also asks who can access the data. The EDPB guidelines treat remote access from a third country as a transfer, and an EU processor subject to third-country law can still create exposure if it must respond to a foreign authority request. Ask the vendor in writing where support staff sit, which sub-processors it uses, and how it responds to government access requests, then record your assessment under your own GDPR accountability process.

Do the EU Data Act switching rights change our exit plan?

They give you more leverage on the exit side. Under the Data Act, which has applied since 12 September 2025, customers can switch from a data processing service to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. These rights help you negotiate your Freshdesk exit terms, but they do not replace a tested export. Freshdesk's account export produces XML for tickets, solutions, forums and customers on every plan, and that file still needs conversion before another help desk can load it. Confirm the exact terms with your legal team.

How is a fixed-scope engagement agreed in writing?

DeployOpen works from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that scope, and DeployOpen does not publish a price list. Ask for a scope that names the hosting location, the migration source and its export, the modules or integrations to include, the testing and cutover steps, backup and handover, and any ongoing support retainer. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, so ask your assessor which evidence they will need.

How DeployOpen deploys Zammad under an EU residency constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including EU data centers and cloud accounts the client controls. For EU residency, that means the Zammad instance, its database, search and cache layers, and its backups stay in the region the client chooses.

How we scope

Map which personal data, attachments and backups must stay in the EEA and who can access them.
Agree the hosting location, network boundaries and administrator access model in a written scope.
Define the migration boundary, including whether Freshdesk data is moved and what is rebuilt by hand.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

Deploy Zammad with PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy in the chosen region.
Add Elasticsearch and Memcached where search and multi-instance deployments require them.
Configure SSO, mail routing, roles and backups, then test restores and access controls before go-live.
Run the Freshdesk migration on a new instance, with a documented fallback copy from the Freshdesk XML export.

How we hand over

Deliver architecture records that show data locations, subprocessors and access paths for your compliance file.
Document runbooks for upgrades, backups, restores and Zammad release handling on the 6.5 and 7.x lines.
Prepare controls and evidence for your own assessments. Independent auditors and certification bodies issue any attestation.
Train named administrators on daily operations and on the steps for a planned region or hosting change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Security testing of the deployed application and its APIs can be scoped separately from the build.
Confirm with your legal team whether Zammad GmbH hosting, an EU provider or your own data center fits your transfer analysis.

Self-hosted Freshdesk alternative for EU data residency