Define the preservation requirement first A project archive can serve several purposes: preserving delivery evidence, making a closed project reviewable without Jira, or supporting a retention decision. These purposes differ from restoring a Jira site after failure. Write down which purpose applies and who will accept the resulting archive before choosing an export method.
Identify the records that matter to that purpose. Issue fields may be enough for a simple status inventory. A historical investigation may also require comments, worklogs, change history, and the actual files attached to tickets. List the requirements explicitly so a successful export operation is not confused with successful preservation.
Ravenshift's local Project Archive Export for Jira implementation describes a Jira Project Archive Bundle, or JPAB, with machine-readable data, attachment binaries, and an offline HTML viewer. Its public Marketplace availability was not confirmed during this content review. Contact Ravenshift about the relevant release and supported coverage before planning operational use.
CSV, site backup, and project archive are different A CSV export is useful for tabular analysis and some import workflows. A site backup follows Atlassian's documented export and restore behavior. A project archive aims to preserve a defined collection of project records for later inspection. None should be assumed to meet the other's requirements without testing.
Atlassian documents that a Jira Cloud site backup can include issue data, comments, configuration, and selected media, with exclusions such as third-party app data. Review the current documentation for its exact scope and restore restrictions. Do not infer that a project archive can restore every workflow, integration, and app state from that backup documentation.
| Requirement | What to evaluate | Evidence to request |
|---|---|---|
| Spreadsheet analysis | CSV issue export | Columns, issue count, and encoding |
| Site recovery | Supported Jira backup process | Current restore procedure and limitations |
| Offline project review | Structured project archive and viewer | Data coverage and offline access |
| Attachment preservation | Actual downloaded file contents | File counts, sizes, and integrity checks |
Write a coverage contract A coverage contract names what the archive includes and excludes. It should describe the project, relevant dates, issue discovery method, and record types. If linked issues outside the project are excluded, say so. If an app stores additional data that the archive does not capture, record that limitation.
The local Ravenshift implementation documents issues, fields, comments, worklogs, changelogs, attachment files, and an offline viewer as part of its project archive format. That is an implementation description, not a guarantee that every export can retrieve every record. Permissions, source changes, and API limitations can still affect a particular run.
Treat individually archived issues as a special case. The project documentation states that issues removed from normal search through Jira's individual issue archival are not covered by this implementation's full archive contract. Restore those issues before a preservation run that requires them, or establish a separate clearly limited scope.
Check access and source consistency Use an account and installation with the access required for the intended scope. Test whether the exporter sees restricted issues and comments that the archive owner expects to preserve. If access is incomplete, the export may be internally consistent while omitting records outside that access boundary.
Choose a period when the project is stable, or define how changes during export will be detected. A project with active edits can produce a collection whose records represent different moments. Capture the expected issue set and compare it after export where the workflow supports that check.
Tell project owners what the export covers and when it will occur. If they need to pause edits, make that an explicit operational decision. Do not rely on a quiet project being immutable. Automated changes, attachment uploads, and integrations can still affect the source during a run.
Preserve attachment contents, not only references An attachment URL may become unusable after access changes, site deletion, or retention cleanup. For a durable archive that requires files, verify that the bundle contains the actual attachment bytes. Check that filenames and metadata remain connected to the correct issues so a reviewer can interpret what each file represents.
Compare expected file counts with retrieved file counts. Investigate failed downloads, zero-byte files, and mismatched sizes. If duplicate filenames occur, verify that the archive format keeps them distinct. A directory that contains some plausible files is not evidence that every required attachment was preserved.
Use hashes where the archive workflow provides them. A hash can help establish that downloaded content matches the recorded file, but it does not prove that the issue set was complete. Integrity and coverage are separate questions, and both matter before deleting the original records.
Understand incomplete and verified exports The local project documentation distinguishes incomplete exports from verified-generation states. It describes checks for retrieved records, attachment sizes and hashes, and source mutations. Review the result of the specific run rather than treating the existence of a downloadable bundle as proof that those checks passed.
An incomplete run can still contain useful data. It should not be promoted to a complete preservation record without resolving or accepting the documented gaps. Keep the error report and the archive together so a future reviewer can understand the limitation.
If a run reports verified generation, retain the evidence used to establish that state. A verification status belongs to a particular export scope and moment. It is not a permanent certification of every future export or a guarantee that source data had no pre-existing omissions.
Verify the archive independently Download the bundle and any external manifest or verification report. Work from a copy in an approved environment. Compare record counts, inspect a sample of issue histories, and validate attachment content using the format's verification tools. Keep the check results with the retained archive.
- Record the intended project scope and expected issue set.
- Inspect run status and unresolved retrieval errors.
- Compare issue and attachment counts with expectations.
- Validate file sizes and available hashes.
- Open representative issues and files in the offline viewer.
- Review exclusions with the archive owner.
- Record acceptance separately from the export operation.
The local Ravenshift project includes an independent integrity verification utility for extracted archives and a separately downloaded manifest. Confirm the release-specific procedure before use. Independent checking is valuable because it separates file inspection from the process that created the files.
Test offline review in the environment that matters Open the viewer without relying on a live Jira session. Confirm that issue navigation, comments, and local attachment references work in the intended browser and storage environment. If the viewer requires specific file placement or a local serving method, document that procedure for future readers.
Use representative records: a long issue, a ticket with custom fields, one with a substantial history, and one with several attachments. Compare them with the original before access is removed. A viewer that opens its landing page successfully may still fail on the records the team most needs later.
Remember that offline content can include sensitive data. The archive needs its own access controls, storage protections, and retention ownership because it is no longer governed solely by Jira permissions. Plan that transfer of responsibility before handing the files to another department.
Keep deletion as a separate decision Do not delete a project merely because an export finished. First obtain acceptance of scope, integrity, readability, and known exclusions from the responsible owner. Check any retention obligations through the organization's established process. A technical success state cannot make a business retention decision on its own.
Preserve the archive in the approved storage location and verify that the people responsible for future access can retrieve it. Consider keeping an additional protected copy according to the organization's normal backup practice. Define who maintains the archive when project staff move to other roles.
If a source deletion is later authorized, keep the acceptance record and verification evidence. Record what was deleted and how the archive can be located. This makes a future question answerable without relying on the memory of the person who performed the export.
Common preservation gaps Watch for attachment links without file contents, records hidden by permissions, changes during export, and individually archived issues outside the normal search scope. Also check whether third-party app records, external linked content, and custom integrations are required. Make each exclusion visible rather than burying it in a generic complete-export claim.
A hash check does not establish that the wrong project was not exported. A correct issue count does not establish that every comment was captured. A functioning viewer does not establish that the archive is restorable into Jira. Match each test to the specific claim you want to make.
When a gap cannot be resolved, decide whether a limited archive still meets the requirement. That decision needs the responsible owner's acceptance and a clear statement of the limitation. It should never be implied by a successful download.
Evaluate the Ravenshift implementation Ask Ravenshift about release availability, supported Jira environments, coverage profiles, size limits, and the procedure for independent verification. Use a small non-production or otherwise approved project for evaluation. Include the record types and edge cases that matter to your actual retention requirement.
Check that the archive owner can interpret run status and locate the verification evidence without developer assistance. Document the process in terms of the future reader, who may not know the original Jira setup. A useful archive must remain understandable after the team that created it changes.
Project Archive Export for Jira is a Ravenshift implementation aimed at defined project preservation and offline review. Use the related guides for PDF snapshots and attendance exports when those are the actual needs. Keeping the requirements separate is the best way to choose an export that preserves the right evidence.