Answer: Because in Jira, data and configuration live in separate structures. When you restore a project or set of issues from a backup, you bring back the content, but custom field contexts, workflow schemes, screen schemes, permission schemes, and automation rules either restore incompletely or not at all. The result is a “hollow restore”: the tickets are back, but the logic that made them functional is gone.
Anyone who has executed a restore on a complex Jira instance has encountered some version of this problem. The data returns, but dropdowns are empty. Tickets exist, but routing breaks. Approvals fail silently. Workflows refuse to transition. Engineering waits while administrators spend days, sometimes weeks, manually stitching the configuration back together. This is not a backup bug. It is a structural property of how Jira works, and it is the single most under-discussed risk in SaaS resilience.
How Jira stores configuration separately from data
In Jira, the things end users see, like issues, fields, statuses, and dropdown values, are powered by underlying configuration objects: schemes, screens, contexts, workflows, and permission models. A custom field context is the object that defines, for a given custom field, which projects and issue types it applies to, what the default value is, and what options users can select. Per Atlassian’s own documentation: “When you create a custom field in Jira Cloud, you automatically create what’s called a custom field context or custom field configuration scheme.”
This separation is what makes Jira flexible. The same custom field, say, “Priority Justification” — can mean different things in a Security project than in a Marketing project, because each project has its own context for that field. The flexibility is a feature. The brittleness on restore is the cost.
The hollow restore: a concrete walkthrough
Imagine a typical scenario. An admin runs an automation script that, due to a logic error, deletes a thousand tickets across a critical project. You restore from yesterday’s backup. The tickets reappear in Jira, and then you start finding the gaps:
- The “Component” field is on every restored ticket, but the dropdown is empty. The project-specific context that defined the component options did not restore.
- Tickets that used to route to specific reviewers are now sitting unassigned. The automation rule that owned routing was a separate configuration object, not part of the issue data.
- Workflow transitions fail. The validators that enforced “Manager approval before Done” are missing because the workflow scheme references a custom field whose context has not been re-linked.
- The Xray test executions associated with these tickets are gone, because the linkage between Xray issues and the parent ticket was a relationship the restore did not reconstruct.
The tickets exist. The system is broken.
Why traditional backups produce hollow restores
Most backup tools, including native exports, treat Jira as a database. They capture rows: issues, comments, attachments, users. What they often miss or mishandle is the relational, configurational, and schematic layer that sits above those rows. There are three specific failure modes:
- Configuration drift. Configuration changes daily in active Jira instances. A backup taken on Monday and a configuration state on Friday are different. Restoring Monday’s data into Friday’s configuration produces inconsistent state.
- Context loss. Custom field contexts that were project-specific can be restored with global scope by mistake, instantly degrading performance and changing field behavior in dozens of unrelated projects. Atlassian itself warns: “Large numbers of custom fields with global contexts have a significant impact on system performance.”
- Dependency breakage. Workflows depend on statuses. Statuses depend on schemes. Schemes depend on permission and notification configurations. A partial restore breaks the chain.
What a configuration-aware restore looks like
To produce a restore that actually works, three things have to happen together:
- Capture the configuration alongside the data. Field contexts, workflow schemes, screen schemes, permission schemes, automation rules, and Marketplace app configurations must be part of every backup, not a separate process.
- Preserve relationships. The links between issues, the parent-child structure for Xray test executions, the cross-project epic linkages: these are first-class state, not metadata.
- Restore with awareness. The restore process must understand whether configuration in the live system has changed since the backup, and either reconcile or warn before overwriting.
How much this really costs
There is no public benchmark for the cost of a hollow restore, but admin teams who have lived through one tell consistent stories: one to four weeks of senior administrator time, engineering teams partially blocked the entire time, lost confidence in adopting new automations, and audit complications when configurations have to be re-derived rather than restored from a known-good baseline. Veeam research indicates organizations recover only 57% of their data on average during an attack, a figure that improves only modestly without addressing the configuration layer.
The right question to ask your backup tool
Not “do you back up Jira?” Most do, in some form. The right question is: “After a restore, will my workflows still work?” If the answer is anything other than yes, with evidence, you are exposed to the hollow restore problem. This is increasingly the technical core of the SaaS resilience conversation: not whether data is preserved, but whether the system that uses the data still functions.
Sources
- Atlassian — Configure field contexts in your site — https://support.atlassian.com/jira-cloud-administration/docs/configure-custom-field-context/
- Atlassian — Configuring custom field contexts (Data Center) — https://confluence.atlassian.com/adminjiraserver/configuring-custom-field-contexts-1047552717.html
- Konfirmity — SOC 2 Backup and Recovery (cites Veeam recovery statistics) — https://www.konfirmity.com/blog/soc-2-backup-and-recovery-for-soc-2
Rewind">
