Why a self-hosted Jira Service Management alternative is a 2029 decision
If your Jira Service Management estate runs on Data Center and must stay on your own servers, GLPI covers internal ITSM and inventory, while Zammad covers customer-facing ticketing, and both can run entirely on your infrastructure. The timing question is less about whether to move and more about when the work is scheduled. Atlassian ended sales of new Data Center subscriptions to new customers on March 30, 2026. Existing customers can buy licenses or expansions until March 30, 2028, and on March 28, 2029, Data Center licenses expire and become read-only. Read-only status generally means the installation keeps running for its existing data but cannot take the changes you would need for growth or fixes, so the migration window closes well before that date in practice. Confirm the exact license terms and the read-only behavior with Atlassian and your account team before you plan around them.
Server is not a path. Atlassian stopped selling new Server licenses on February 2, 2021, and ended support for all server products, including Jira Service Management Server, on February 15, 2024. If you are still on a Server instance, treat the migration as already overdue and plan the export before anything else. For Data Center customers, the practical decision is which target fits each part of the service desk. Ask your team to inventory three things: internal request and incident workflows, the configuration items held in Assets, and customer-facing queues with email, chat or portal channels. Each of these maps to a different open-source platform, and each has a different export path. The Atlassian journey to cloud announcement is a useful reference for the product timeline when you brief leadership.
Build the plan backward from March 28, 2029, but schedule the work against your own change freeze calendar, audit cycle and staff availability. Decide early whether you need an external partner for hardening, data migration and cutover testing, and ask for a written, fixed-scope proposal that names deliverables, a test plan and a rollback approach. The cost of the self-hosted route is mostly staff time and infrastructure, and the cost of waiting is compression: the same migration squeezed into a shorter period costs more and carries more risk. Your decision timeline should be set now, with named owners and checkpoints well ahead of the read-only date.
What staying on your own servers requires
Once Data Center licenses become read-only on March 28, 2029, every constraint below moves onto your team. The data stays in your environment, the application tiers become your job, and the backup and export path must be proven before you need it. The workflows you rebuild are the part most likely to be underestimated.
Keeping data inside your environment
Self-hosting only protects residency if every component, including the database, search index, cache and mail relay, runs in your own accounts or data center. Cloud backup features do not cover this. Atlassian's Jira Cloud backup manager excludes automation rules, third-party apps and Assets, so those objects need their own extraction plan before you migrate. Ask your team to list each data store and confirm where it sits.
Operating the application tiers
Data Center handled clustering and vendor-run upgrades for you. On a self-hosted alternative, your team or a partner owns the web tier, the application server, the database and the patch cadence. GLPI 12.0.0 was published on October 7, 2026, and Zammad 7.2.2 followed with security releases in October 2026, so plan for regular upgrades. Confirm who approves patch windows and who restores service when an upgrade fails.
A tested backup and export path
Treat backup as a restore test, not a setting. Atlassian's cloud backup manager requires 48 hours between backups when attachments are included, and it leaves out automation rules, apps and Assets. Export those separately in CSV or XML and store them with the database and attachments. Before cutover, restore into a test instance and check ticket counts, attachments and custom fields against the source.
Rebuilding Data Center workflows
Data Center's automation rules, request types, queues, SLAs and approval paths do not move automatically. GLPI covers ITIL incident, problem, change and service level management, and Zammad covers agent ticketing with its own triggers and SLA settings. Map each Jira workflow to its counterpart and mark any with no equivalent as a decision for your change board. Confirm each mapping in a pilot queue before you retire Data Center.
How GLPI and Zammad meet the constraint, and where they fall short
This table compares GLPI and Zammad on license, requirements, migration paths and gaps against what Jira Service Management Data Center covered for internal IT and customer agent ticketing. Read the rows as a checklist: a gap marked in a row is something to resolve in the design or the migration plan before the Data Center read-only date of March 28, 2029 takes effect.
| Capability | GLPI | Zammad |
|---|---|---|
| License | GPL-3.0, free to self-host; vendor subscriptions are optional | AGPLv3, owned by the Zammad Foundation; self-hosted use has no license fee |
| Primary use | Internal IT service management, inventory, CMDB and contracts | Agent ticketing for customers and employees across email, chat, forms and phone |
| ITIL coverage | Incident, problem, change and service level management | Ticket queues, channels and service-style workflows; change management is not its focus |
| Asset and CMDB equivalent | Inventory and CMDB, not a one-to-one match for Jira Assets object schemas | No CMDB equivalent; asset data stays outside the ticketing tool |
| Core requirements | PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later on the main branch; confirm against your release | PostgreSQL 15 or newer, Redis 7 or newer, Nginx or Apache; Elasticsearch optional but recommended |
| Sign-in options | Internal database, LDAP, IMAP and REMOTE_USER, tried in that order | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab, among others |
| Built-in migrators | Confirm the import path for Jira Service Management data with your migration partner | Freshdesk, Kayako, OTRS and Zendesk only; no Jira migrator, so moving runs through the API |
| Latest release noted | GLPI 12.0.0, released October 7, 2026; confirm the production line you will run | Zammad 7.2, released September 23, 2026; security fixes also shipped on the 6.5 line |
| Largest gap to plan for | Rebuilding Jira automation rules and Assets relationships by hand | Rebuilding queues, SLAs and automation rules that a Jira backup does not export |
Which option fits which Jira Service Management workload
Teams that run an internal IT service desk tied to hardware, software, contracts and a configuration database usually have the heaviest rebuild in front of them. GLPI covers ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management under GPL-3.0, so the asset side of a Jira Service Management estate has a direct home. The work is in mapping the existing schema, not in finding features.
- Assets and CMDB: Jira Service Management Assets object schemas and references must be re-modeled as GLPI item types and relations, and discovery data is best refreshed through GLPI Agent rather than copied across.
- Request types and forms: Each request type, its fields and its approval path is rebuilt by hand in GLPI's ticket templates and forms.
- Queues and SLAs: Assignment rules, escalation levels and service level agreements need to be defined again in GLPI and tested against real ticket volumes.
- Automation rules: Jira Cloud backups exclude automation rules and third-party apps, so each rule is documented from the live configuration and reimplemented.
- Change management: Change approval flows and their links to assets are rebuilt and verified with the change board.
See the sibling page on migrating from Jira Service Management to GLPI for the data extraction steps. Confirm the GLPI version and PHP and database requirements against the installation documentation before sizing servers.
Service desks that handle tickets from customers or external users, through email, web forms, chat or phone, are a different workload. Zammad is licensed under AGPLv3 and is built around agent ticketing, with third-party sign-in through SAML and OpenID Connect and search on Elasticsearch. Its gaps are in the change management and asset areas that Jira Service Management teams often use alongside agent queues.
- Channels and inbound email: Mail accounts, web forms and any phone or chat integrations are configured again, and inbound routing is tested before cutover.
- Queues and groups: Groups, roles and queue ownership are recreated, since Zammad has no built-in Jira migrator.
- Macros and triggers: Macros, triggers and overview screens replace Jira automation, and each one should be traced from the old rules.
- Customer records: Customers and organizations are moved through the Zammad API, and the team should decide which history must be carried over.
- Attachments and search: Elasticsearch is optional but strongly recommended for attachment content search, so it belongs in the sizing discussion.
See the sibling page on Jira Service Management versus Zammad for the feature comparison. Confirm which Jira Service Management features your team depends on that Zammad does not cover, such as change management, before committing to a cutover date.
Some organizations run one Jira Service Management instance that serves both internal IT and customers. Splitting that instance is the hardest part of the decision, because queues, permissions and reporting often cross the boundary. A mixed estate may end with two tools, a single tool with a clear division of queues, or a stepped plan that moves one side first.
- Shared request catalog: Requests that serve both customers and staff must be assigned to one system of record, or they will be duplicated.
- Identity and sign-in: Both tools need the same directory integration, so that agents and requesters keep a single identity across systems.
- Reporting continuity: Dashboards and SLA reports that span both groups need to be rebuilt in each tool or exported to a shared reporting layer.
- Operating two platforms: Two products mean two upgrade cycles, two backup routines and two sets of administrators, which should be costed as recurring work.
- Cutover order: Moving the internal side first often reduces risk, but the sequence depends on how much the customer queues depend on shared assets.
See the sibling pages on Jira Service Management versus GLPI and versus Zammad to compare each side. Ask your team to list every queue and its owners before choosing a split, because the boundary decides the rebuild scope.
Working back from March 28, 2029 to a cutover plan
This sequence turns Atlassian's published Data Center dates into a set of phases, each with a clear output, so the team can see what must be finished before the licenses become read-only. The length of each phase depends on your own estate and should be fixed in a written scope rather than assumed from this page.
Fix the Atlassian deadlines in your planning calendar
Start by recording the dates that set the outer limits: Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026, the last date for existing customers to buy licenses or expansions is March 30, 2028, and Data Center licenses expire and become read-only on March 28, 2029. Owners are the IT service management lead and the procurement contact, who confirm current terms with their Atlassian account team. The step is done when every milestone below has a named owner and a date agreed by leadership.
Inventory Jira use, apps and automation
Catalogue every project, request type, queue, SLA, workflow, custom field, automation rule, marketplace app and integration in use, and record who depends on each one. Assets objects and any scripts or webhooks outside Jira must be listed separately, because a Jira Cloud backup excludes automation rules, third-party apps and Assets. The output is a register that marks each item as keep, rebuild, retire or replace, reviewed by the service owners who actually run those queues.
Decide the target platform for each workload
Assign each workload to a target, for example internal IT requests and assets to GLPI, or customer-facing agent ticketing to Zammad, and record the reason in the register. Confirm the data protection, residency and access requirements for each workload with your security and compliance leads before choosing. The step closes with a signed decision record per workload, so later phases do not reopen the choice.
Stand up a non-production instance
Build a separate test environment for the chosen platforms inside your own infrastructure, including the database, cache and search components that each product requires, and configure sign-in against your identity provider. Check the vendor's current software requirements for the exact versions you intend to deploy. The step is complete when the instance passes a documented smoke test and the backup and restore procedure has been run once.
Run a test extraction and import
Export a representative sample of Jira data, using the backup and CSV exports where they fit, and load it into the test instance using the target product's import route. Record every field, attachment, history item and user mapping that fails or is dropped, and decide how each gap is closed by hand or by custom work. The output is a defect log with counts and owners, and a repeatable import script that a second run can reproduce.
Run the platforms in parallel
Keep Jira as the system of record while agents work the same live demand in the new platform for a period agreed in your written scope. Compare ticket volumes, SLA timers, routing and notifications, and log every difference that matters to a service owner. The step is done when the open defect log shows no unresolved item that blocks a workload, and the business owner signs the cutover readiness review.
Cut over and freeze Jira writes
Take a final extraction from Jira, import the delta into production, switch intake channels and integrations to the new platform, and set the Jira projects to read-only for new work. Keep a rollback path documented until the business owner confirms the new queues are stable. The output is a cutover record listing the time of freeze, the final import checks and the channels redirected.
Archive the Data Center instance before read-only
Before March 28, 2029, export and store a complete, verifiable archive of the Data Center instance, its configuration and attachments in your own storage, and decide how long records must be retained under your policies. Retire the instance only after the archive has been restored and sampled successfully. The step is complete when the archive is catalogued, access-controlled and signed off by compliance, which is the last item on the plan.
How GLPI and Zammad run on your own infrastructure
GLPI is a PHP application, so the deployment starts with the stack you already run or can support. The GLPI README lists PHP 8.3 or later with MariaDB 10.11 or later, or MySQL 8.0 or later, and the installation docs for GLPI 11.0 list older minimums, so confirm which requirement applies to the release you select before you build the server. Point the web server's document root at GLPI's public directory rather than the installation root, and enable URL rewriting so requests route through index.php. The web server can be Apache, Nginx, lighttpd or IIS. Plan the database backup, the files and the config directory, which holds glpi.key and glpicrypt.key. Losing those keys makes encrypted data unreadable, so store them with your other secrets and test a restore before go-live. GLPI also publishes an official Docker image, which fits a container host if your platform team standardizes on that model.
Zammad needs more moving parts. It stores content in PostgreSQL 15 or newer and uses Redis 7 or newer for realtime websocket communication, with Nginx or Apache as the reverse proxy. Elasticsearch is optional but strongly recommended for search, reporting and attachment content search, so budget for it in the design. Memcached is required once you run multiple Zammad instances, such as containers or cluster nodes. Single installations can use the file system cache. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart. Its Kubernetes support covers only the Zammad application, not cluster problems, so the team that runs the cluster owns the rest. Ask the Zammad team or a support partner to confirm the exact versions for the release you choose, since these requirements change between major lines.
For a Data Center replacement, decide the topology before procurement. Size the database, Redis and Elasticsearch tiers for your ticket volume and attachments, and decide where each runs. Confirm the high availability design with your platform team, because Zammad's documented multi-instance pattern depends on Memcached and shared services. Both products need patching on a schedule you control, so write that cadence into the operating plan and test upgrades in a non-production copy first.
Moving data out of Jira without losing what backups leave behind
This sequence captures the Jira Service Management data that a standard backup omits, reshapes it for the target platform and proves the new instance holds the same records before cutover. Each step ends with a check you can record in the migration log.
Take a full Jira Cloud backup and inventory the instance
The Jira administrator runs the backup manager in Jira Cloud, which creates a backup of work items, comments, users and groups, and project configuration. Because the backup excludes automation rules, third-party apps and Assets, the team also lists every automation rule, installed app and Assets object type before the backup is taken, so nothing is missed later. With attachments included, Atlassian requires 48 hours between backups, so plan the snapshot date with that limit in mind. The step is done when the backup file is stored in the migration repository and the inventory is signed off by the service owner.
Export Assets and automation rules separately
Assets data is not part of the Jira Cloud backup, so the team exports it through the separate Assets CSV export and records the object schema, object types and references. Automation rules are exported by hand, either by documenting each rule's trigger, conditions and actions or by using any export function the tenant provides, which should be confirmed in your own environment. Third-party app data follows the same pattern: each app's stored data is identified and extracted according to its vendor's documentation. The step is complete when every Assets object type and every automation rule has a matching exported file or written specification.
Document third-party app data and attachments
For each installed app, the team records what business data it holds, such as approvals, custom forms or linked records, and where that data can be read. Attachments are checked against the backup, since their presence determines whether the backup was taken with attachments included. Anything that cannot be exported is listed as a known gap with an owner and a decision: rebuild, retire or accept the loss. The output is a gap register that the business signs off before transformation starts.
Transform records into the target schema
Engineers map Jira issue types, request types, statuses, priorities and custom fields to the target model, whether that is GLPI tickets and CMDB items or Zammad tickets, groups and states. Users and groups are matched to accounts in the new identity source, and Assets objects are mapped to GLPI or iTop configuration items with their relationships preserved. Zammad's built-in migrator supports Freshdesk, Kayako, OTRS and Zendesk only, so Jira data moves through the Zammad API using scripts written and tested for this mapping. The step closes with a mapping document and a transformed test dataset reviewed by the service owner.
Load into a new instance and test with a sample
The target platform is installed on the organization's own infrastructure, and the transformed data is loaded into it. Zammad's migrator is all or nothing, works only on a new instance and accepts one source system per migration, so the team loads into a fresh Zammad or GLPI environment rather than an existing one, and runs a sample migration first. Failed records are logged, corrected in the mapping, and reloaded into a clean instance. The step is done when the sample imports without unexplained errors and the team agrees on the fixes.
Verify counts, attachments and relationships
Record counts are compared between Jira and the new instance for work items, comments, users, groups, Assets objects and attachments, with each difference explained or fixed. A random sample of tickets is checked field by field, including linked configuration items and attachment download. Automation rules and app logic are re-tested against the rebuilt queues, SLAs and workflows. The step closes with a verification report signed by the service owner, which becomes part of the evidence for any later compliance review.
Archive the source and retain evidence
Once the business accepts the verification report, the Jira backup, exports, mapping documents and gap register are stored under the retention rules the organization already applies to ITSM records. Read-only access to Jira is kept for the agreed period so staff can look up historical records. Retention periods and the decision to keep or delete the Jira tenant should be confirmed with your legal and records team. The step is complete when the archive index lists every artifact and its owner.
Evidence the operator keeps under a self-hosted ITSM
Once Jira Service Management runs on your own servers, the evidence an auditor will ask for is produced by your team, not by a vendor. The cards below cover the records that connect a self-hosted GLPI or Zammad deployment to the 2029 decision and to later assessments. DeployOpen prepares these inputs with you, but independent auditors and certification bodies issue any reports.
Versioned configuration and change records
Keep the GLPI or Zammad configuration in version control, including the glpi.key and glpicrypt.key handling for GLPI and the environment settings for Zammad, with every change tied to an approved ticket. For GLPI, the update procedure already requires a backup before files are replaced and php bin/console db:update is run, so each upgrade should leave a dated change record. Check that the record shows who approved the change and how it was rolled back if it failed.
Backup and restore test results
A backup only counts as evidence after a restore has been tested. Record which database, file and configuration backups were taken, where they are stored, and the date of the last restore test into a separate environment. Keep the restore output, not just the backup job log. For Zammad, include PostgreSQL and attachment storage in the test, and for GLPI, include the database and files together.
Access control and sign-in configuration
Document how users sign in: GLPI tries its internal database, LDAP, IMAP and external methods in a set order, and Zammad supports SAML, OpenID Connect and other third-party providers. Export the settings for each provider, the admin role assignments and the step-up authentication settings where your GLPI version offers them. Review these records at least as often as your identity provider policy requires, and confirm the current options in your version's admin documentation.
Retired Jira data and its archive
Jira Cloud backups exclude automation rules, third-party apps and Assets, so those items need a separate extraction and a written inventory. Create a register listing each retired Jira data set, its export method, its checksum, its storage location and its retention end date. Keep this register with the migration records, because an auditor will ask where a historical ticket or asset now lives and who may read it.
Patch records for GLPI and Zammad
Record the version running in each environment and the date it was applied. Zammad publishes security releases on more than one line, so the 6.5 and 7.x lines both need tracking if you run either. GLPI 12.0.0 was published on October 7, 2026, and GLPI 11.0 plugins are suspended after a new version is detected, so each upgrade record should list the plugins reactivated and tested afterward.
Decision records behind the 2029 timeline
Keep a dated record of the decisions that set your timeline: the Atlassian end of sale for Data Center and the March 28, 2029 read-only date, your license expansion decisions, the options you assessed and the reasons for choosing them. Note which dates came from Atlassian and which came from your own planning. This record shows auditors and leadership why the migration was scheduled as it was and what was reviewed before each cutover.
Questions teams ask before a self-hosted Jira migration
What does it cost to run GLPI or Zammad on our own servers?
The software itself carries no license fee for either GLPI (GPL-3.0) or self-hosted Zammad (AGPLv3), so the cost is what you spend to run it. The main components are infrastructure (virtual machines or containers, database, search and cache services, backups), staff time to operate and patch the platform, a one-time implementation scope for data migration, integrations and configuration, and optional vendor support. Infrastructure and staff time recur every year. Implementation is largely one-time, but ongoing changes add to it. 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. Support is optional. Ask any provider to split a quote into one-time and recurring items.
How long does a migration from Jira Service Management take?
The duration depends on ticket volume, the number of automation rules and custom fields to rebuild, how many integrations exist, and whether Assets data must move to a CMDB. No fixed timeline applies to every organization, so do not accept one from a vendor without a written scope. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts. Ask for the phases, the data each phase covers, the test and cutover criteria, and what is required from your team, such as access, approvals and subject-matter reviews.
Can our team migrate and run the new service desk without outside help?
Yes, many teams can, but it depends on the skills you already have. Running GLPI needs a PHP 8.3 or later stack with MariaDB 10.11 or later or MySQL 8.0 or later, a web server, and someone who can handle updates, which require backing up the database, files and the config directory. Running Zammad needs PostgreSQL 15 or newer, Redis 7 or newer, and often Elasticsearch and Memcached in multi-instance setups. Your team should have Linux administration, database and backup skills, and someone who can own automation rules and email channels. If those skills are thin, an implementation partner can cover the build while your staff learn to operate it.
Does Zammad's lack of a Jira migrator change the migration effort?
Yes. Zammad's built-in migrator covers Freshdesk, Kayako, OTRS and Zendesk, but not Jira Service Management, so tickets and customers have to move through the Zammad API or custom development. Migrations are all or nothing, work only on a new instance, and accept one source system per migration. That means more scripting, field mapping and test loads than a built-in import would need. Queues, SLAs, triggers and automation rules must also be rebuilt by hand, because a Jira Cloud backup does not include automation rules, third-party apps or Assets. Ask the provider to show the mapping of each Jira object to a Zammad object before agreeing on scope.
What does GLPI Network's 45-day free trial cover, and what does it not replace?
The 45-day free trial lets you evaluate GLPI Network, Teclib's hosted cloud offering, and it does not replace a self-hosted deployment. The trial answers whether the product fits your workflows, but it does not move your data into your own infrastructure, and it ends on a fixed date. For self-hosted use, the relevant GLPI Network prices are the subscription tiers, which the subscriptions page lists at 19 euros per user per month for public cloud, 21 euros per user per month for private cloud with a 25-user minimum, and from 100 euros per month for self-hosted Basic. Plan your self-hosted build separately from any trial.
What should we ask a consultant to include in a quote?
Ask for a written, fixed scope that lists each deliverable, the source systems and volumes, and what is excluded. A useful quote states the platform version and target architecture, the data to migrate from Jira (requests, incidents, changes, attachments, customers, and Assets exported separately), the automation and integration rebuild, testing and cutover, backup and update procedures, handover documentation, and training. Ask which items are one-time and which are retainers for support, upgrades or testing, and what your own team must provide. Request the acceptance criteria and the change process if scope grows. DeployOpen does not publish prices, and quotes follow from the written scope.
What breaks most often when moving off Jira Service Management?
The usual failures come from what a backup leaves out. Jira Cloud's backup manager excludes automation rules, third-party apps and Assets, and attachments require 48 hours between backups when included. Teams also lose email routing, request forms and approval paths if no one documents them before cutover. Check that users, groups and permissions map correctly, that SAML or OpenID Connect sign-in works with your identity provider, that historical SLA data is either migrated or archived, and that you can restore your own backups. Ask the provider to test a full restore before the cutover date.
What to confirm with vendors before you commit
Some of the decisions in this migration depend on details that the public material does not settle, so treat them as open items to confirm before you sign anything. Start with Atlassian's exact behavior for Data Center once licenses expire and become read-only on March 28, 2029. Ask Atlassian in writing what remains accessible in read-only mode, whether users can still log in, whether attachments and reports can still be downloaded, and which export options remain available at that point. Do not assume that a read-only instance stays usable for a long cutover. Confirm the answer against your own contract and license terms, and record the date you were given.
Next, inventory the Jira apps your team depends on and check each one against GLPI and Zammad. Run a list from your Jira administration console and mark every app that adds workflow steps, approvals, custom fields, forms or reporting. For each one, decide whether the function is built into GLPI or Zammad, can be covered by a plugin or API integration, or must be dropped or redesigned. Ask the GLPI and Zammad maintainers or your implementation partner to confirm which functions exist in the version you plan to run, because plugin and integration availability changes between releases.
Finally, confirm how your current Jira workflows map to ITIL change handling and the support terms you will rely on. Walk through a sample of real change requests with your change advisory board and check whether approvals, risk fields, scheduling and post-implementation review can be expressed in GLPI's change module. For support, ask Teclib' and Zammad GmbH what current support terms apply to your deployment model, which response times they commit to, and whether they cover the database, search and cache layers you run yourself. Put each answer in writing before you commit.
How DeployOpen deploys under this constraint
The sequence turns a Data Center exit decision into a written scope, a deployed GLPI or Zammad instance inside your own environment, a verified migration, and documented operations you can run or retain support for.
Agree the scope in writing
Before any work starts, DeployOpen and your team agree the scope, deliverables and timeline in writing. The scope names the chosen platform (GLPI for internal IT service management and inventory, or Zammad for customer-facing ticketing), the systems in scope, and the data sources to migrate. Your team confirms the Data Center license dates that apply to your contract, including the read-only date of March 28, 2029. The step is complete when both parties sign the scope document.
Produce a fixed-scope deployment plan
DeployOpen drafts a plan for the chosen option covering the target architecture, database and cache layers, web server, backup location and integration points such as LDAP, SAML or OpenID Connect sign-in. For GLPI, the plan confirms supported PHP and MariaDB or MySQL versions. For Zammad, it confirms PostgreSQL, Redis and whether Elasticsearch and Memcached are needed. Your team reviews and approves the plan. The step closes with an approved architecture document.
Deploy inside your own environment
DeployOpen installs the platform in your cloud account, data center or air-gapped network, using the install methods the vendor documents for your choice. Access is restricted to your administrators, and the instance is reachable only through the endpoints you define. Your team keeps ownership of the infrastructure accounts and secrets. The step is done when a staging instance passes functional checks for ticket creation, assignment, notifications and user sign-in.
Migrate and run in parallel
DeployOpen exports data from Jira Service Management, using the backup and CSV exports for work items and the separate Assets export for configuration items, and imports them into the new platform. Zammad's built-in migrators cover only Freshdesk, Kayako, OTRS and Zendesk, so Jira data passes through the Zammad API or custom import work. Automation rules, apps and SLAs are rebuilt by hand and listed as gaps. Both systems run in parallel for a period agreed in the scope, and your team signs off reconciled record counts.
Harden the platform
DeployOpen applies the hardening baseline agreed in the plan, covering TLS, administrator access, authentication policy, logging, patching of the operating system and database, and restriction of plugins and file permissions. For GLPI, this includes protecting the glpi.key and glpicrypt.key files. Findings from internal review are fixed or recorded as accepted risks. The step ends with a hardening checklist signed by your security owner.
Document backup, restore and upgrade procedures
DeployOpen writes runbooks for backup and restore, covering the database, file storage and configuration secrets, and a tested restore to a separate host. Upgrade procedures follow each vendor's documented steps, such as the GLPI sequence of backing up before replacing files and running the database update, with plugin reactivation after major versions. The step closes when a restore test succeeds and your operations team acknowledges the runbooks.
Hand over operations and evidence
DeployOpen hands over the architecture, configuration, runbooks and change records, and provides the control evidence your internal or external auditors need for their own assessment. DeployOpen prepares that evidence but does not issue audit reports or certifications; independent auditors and certification bodies do that work. Your team runs the platform with knowledge transfer completed. The step is complete at signed handover.
Optionally retain ongoing support
Teams that want continuity can add a retainer for ongoing support, upgrades and continuous testing, scoped in writing. Retainers cover recurring work such as applying vendor security releases, testing upgrades in staging and reviewing backups. DeployOpen does not publish a price list, so a quote follows from the written scope that you agree. Ask for the scope, response expectations and exit terms in any quote.
