What Actually Breaks When You Leave Jira: A Pre-Migration Audit

A replacement can import every ticket and still break the way your team works.

Consider a change request that reaches "Approved" after migration. The status looks correct. But the old workflow required approval from someone other than the requester, checked a mandatory field, and triggered a downstream action. If the replacement preserves only the status label, the ticket survived while the control disappeared.

That is the migration problem to investigate before comparing boards or subscription costs.

First, distinguish the deadlines: Jira Server support ended on February 15, 2024. Atlassian has announced March 28, 2029 as the end-of-life date for affected Data Center products, including Jira Software Data Center. These are different timelines, even if both put replacement planning on your desk. See Atlassian's Server support FAQ and Data Center end-of-life announcement.

The following audit produces something more useful than a feature wishlist: a set of requirements and test cases you can hand to any replacement vendor.

Start with an evidence register

Create a spreadsheet with one row per dependency or behavior:

Project / issue type:
Configuration or dependency:
Business purpose:
Owner:
Evidence from current system:
Required behavior after migration:
Disposition:
Acceptance test:
Unresolved question:

Use four dispositions: preserve, redesign, archive, or retire. Leave genuinely unknown items marked unknown until someone investigates them.

Gather configuration exports where available, installed app names and versions, integration details, project ownership, and representative tickets. Record the source version and collection date so later configuration changes do not silently invalidate the audit.

Work from read-only inspection or an isolated restored copy. Disable outbound integrations and notifications in the copy before exercising workflows.

Do not clean up production as part of discovery. A field that looks abandoned may still feed a quarterly report. Identify its owner and dependencies first.

Audit workflow behavior, not the diagram

Start by mapping each project's issue types to their assigned workflows. A single project can use different workflows for different issue types through a workflow scheme. Atlassian documents that relationship in its workflow administration guide.

For each active workflow, inspect the transitions. Jira distinguishes conditions, validators, and post functions: these can control whether a transition is available, whether it succeeds, and what happens afterward. A destination with matching status names does not establish equivalent behavior. See Atlassian's advanced workflow configuration documentation.

Record:

• Who can perform each transition, including exceptions.
• Which fields must be present and how their values are checked.
• What changes automatically after the transition.
• Which rules depend on an app, script, webhook, or external service.
• How reopening, rejection, cancellation, and reassignment behave.
• How statuses map to board columns and reporting definitions.

Turn important rules into executable acceptance scenarios. For a hypothetical approval process:

Given: A change request is awaiting approval.
Actor: The person who submitted it.
Action: Attempt to approve it.
Expected: Approval is denied.

Actor: An authorized independent approver.
Action: Approve with the required evidence missing.
Expected: Approval is denied.

Action: Supply the evidence and approve.
Expected: The transition succeeds and the approval
actor and time remain inspectable.

The exact target implementation can differ. The required control should be explicit.

Include rejection paths in the test set. A demo where an administrator moves a ticket through every column proves little about ordinary users or restricted actions.

If nobody can explain a rule, mark it for investigation. Do not automatically carry it forward or delete it.

Trace plugin dependencies to the work they perform

An installed app list is only a starting point. You need to know where each app participates in daily work and where it stores information.

For every app, identify:

• The projects, fields, workflow rules, and reports that use it.
• Any data stored outside ordinary issue fields.
• Its export options and the format of exported data.
• Scripts, scheduled jobs, or integrations that depend on it.
• The person who will accept a replacement behavior.

Even Atlassian's own Cloud Migration Assistant treats app migration separately: app vendors must provide an automated migration path for their app data to migrate through the assistant. That illustrates why "we migrate Jira" is insufficient evidence for a particular dependency. See what the assistant migrates.

Suppose an app implements an approval table with multiple decisions per ticket. Flattening it into a text field might preserve readable evidence, but it may eliminate structured reporting and enforcement. That can be acceptable for historical records while being unacceptable for active requests.

Require a disposition for every essential dependency:

Disposition	Evidence needed
Replace with native behavior	A passing test of the required behavior
Rebuild	An owner, implementation estimate, and maintenance plan
Preserve as an archive	A tested retrieval method with appropriate access controls
Retire	Approval from the process owner and a dependency check

"No equivalent" is a real outcome. It may require changing the business process or rejecting a candidate. Discovering it before purchase is the purpose of this audit.

Treat historical tickets as records with relationships

A ticket count is a useful reconciliation check. It does not tell you whether the records remain meaningful.

Years of history can contain former employees, deleted field options, old project keys, attachments, and links to systems that no longer exist. Decide what must remain usable before selecting an import method.

Build a representative sample that includes:

• The oldest records and recently updated records.
• Reopened issues and issues moved between projects.
• Tickets attributed to inactive or renamed users.
• Restricted issues and restricted comments.
• Large attachments and unusual filenames.
• Parent-child relationships and cross-project links.
• App-owned fields and historical sprint membership.

For each sample, compare the source and proposed target. Check authorship, timestamps, field values, comments, attachments, and relationships. Where file bytes should remain unchanged, compare attachment checksums as well as counts.

Document identity mapping explicitly. Mapping every departed employee to "migration user" can erase useful attribution. Mapping an old account to the wrong current employee is worse.

Separate operational history from archival history. Active work may require editable relationships and queryable fields. Closed work may only need reliable retrieval, preserved attribution, and restricted access. The owners of those records should decide.

If historical reporting matters, run a known report against the proposed target or archive. A final status alone cannot reconstruct how long a ticket spent in each state.

An archive is only a valid plan if someone has demonstrated retrieval. "We have the backup" does not answer how a project owner will find an attachment later. If the archive depends on running the old application, verify that licensing, support, and operating arrangements make that practical.

Test effective permissions

Permission scheme sprawl makes configuration names poor evidence of actual access. Audit what specific people can do.

Start with project permissions, project role membership, directory groups, and issue-level restrictions. Record exceptions for service accounts and individually granted access. Atlassian's project permission documentation provides a reference for inspecting the source configuration.

Build an access matrix around representative identities:

Identity	Resource and action	Expected result
Project member	Read ordinary project ticket	Allow
Unrelated employee	Read restricted ticket	Deny
Contractor	Download restricted attachment	Deny
Automation account	Update designated project	Allow
Former employee	Sign in	Deny

Adjust these expectations to your actual policy.

Run the same tests against each candidate. Include direct URLs, searches, exports, API access where available, and notifications. A ticket hidden from a board may still be exposed through another route.

Record intended changes separately from migration defects. If the existing permissions are too broad, reproducing them faithfully is not success. The responsible owner should approve the corrected access matrix before testing starts.

Use the audit to control the pilot

Choose a pilot scope that covers each distinct high-risk dependency. The smallest or cleanest project may exercise none of the difficult behavior.

Give each candidate the same sample records and acceptance tests. Ask for observed results, including failures. Keep "supported according to documentation" separate from "demonstrated with our data."

Before choosing a replacement, verify:

• [ ] Every active workflow has an owner and a documented disposition.
• [ ] Essential app dependencies have a demonstrated path or an accepted redesign.
• [ ] Historical records have explicit preservation and retrieval requirements.
• [ ] Permission tests include denied actions.
• [ ] Integrations have owners and target behavior defined.
• [ ] Each unresolved limitation has an owner and a decision deadline.
• [ ] The proposed migration service states its exclusions and acceptance criteria.

Then rehearse the operational move. Measure extraction, import, and validation time using representative data. Identify how changes made during the migration window will be captured or prevented.

Write the rollback decision before cutover. Specify who can call it, what triggers it, and what happens to tickets edited in the destination. Restoring the source does not automatically reconcile destination writes.

Compare candidates using the cost of the accepted design, including rebuilds, archive operation, retraining, and ongoing maintenance. For a self-hosted replacement, assign responsibility for patching, backups, monitoring, and restore testing.

Where our own product lands on this

Adaptive Work is a self-hosted Jira alternative in Adaptive IP Services' Hub division and part of the Adaptive Reservoir platform. It provides ticketing, kanban boards, sprints, and approval workflows on-premises, behind your own network boundary. Migration off Jira Server/Data Center is handled as a service.

Those facts make it relevant to teams that want issue tracking to stay inside their network. They do not establish compatibility with a particular plugin, custom workflow, or historical data model.

Apply the same audit to Adaptive Work. Bring the dependency register and acceptance tests into the evaluation, and require the migration scope to explain what will be preserved, redesigned, archived, or retired. A migration service still needs concrete acceptance criteria.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.

David J. Boggs
Founder and CEO, Adaptive IP Services

Adaptive Work