A practical checklist for replacing a Jira app

A replacement is ready when people can complete the work, the necessary history is accounted for, and someone has checked the result. Treat the transition as part of the project from the beginning.

1. Map the workflow and its dependencies

List the people, fields, reports, automations, and connected systems that use the app. Ask each workflow owner to identify the outputs they rely on, including infrequent exports and exception handling.

Separate operational data needed on day one from history that can remain in an agreed archive. A full recreation of every historical screen may not be necessary, but decide how users will retrieve old records and who will retain access.

2. Verify the export path with a real sample

Do not assume a Jira site backup contains an app’s own data. Atlassian’s Jira Cloud export documentation explicitly excludes third-party apps and app data from that export. Check the specific app’s export or API options and any limitations before choosing a migration approach. Source: Atlassian’s Jira Cloud export documentation.

Request a small, representative sample first. Check whether it contains stable record identifiers, user references, timestamps, approval status, and the fields needed for your reports. Confirm export limits and whether cancelling the subscription would affect access.

Write down what cannot be exported or reproduced. Resolve the impact with the business owner before implementation proceeds.

3. Agree the mapping and acceptance checks

For each source field, define the destination, transformation, and behavior when a value is missing. Pay particular attention to inactive users, deleted projects, time zones, duplicate records, and the meaning of status values.

• Completeness: expected records and reporting periods are present.
• Accuracy: sampled entries and totals match the agreed source.
• Permissions: each role sees and changes only what it should.
• Workflow: users can complete normal and exceptional tasks.
• Reporting: important exports and downstream calculations reconcile.

A matching record count is one check, not the whole acceptance test. For time data, also compare totals by person, project, and reporting period. Decide acceptable differences and how they will be explained.

4. Run a trial before setting the cutover

Use an agreed test environment and appropriate access controls. Run the migration with representative data, capture errors, and have the actual workflow owners test the result.

Check that rerunning the import will not silently duplicate records. Measure how long the process takes, identify any manual steps, and update the runbook. A successful trial gives the team evidence for the rollout decision.

5. Plan the switch, including a way back

Name the person who approves the change and the people handling import, validation, communication, and support. Decide whether writes need to pause, how late changes will be captured, and how users will know which app to use.

Define a rollback threshold before the switch. If a critical report fails or permissions expose the wrong data, the team should know who makes the decision and how to restore the previous working process. Retain the old access and exports for an agreed period where the contract and data-handling requirements permit.

6. Close the project after the checks pass

Obtain acceptance from the workflow owners, provide short operating instructions, and record known limitations. Hand over the data map, validation results, support contacts, and deployment or administration guidance.

Only then confirm which subscriptions, integrations, and permissions can be removed. Check the cancellation terms and retention requirements separately; a successful import does not automatically end a billing commitment.