CSV import, backups and recovery

Preview Jira CSV imports and export or restore portable content safely.

Prepare a Jira CSV import

Managers open the CSV import tools in Project settings. Export Jira data, then map fields, users, types, statuses, estimates, release assignments and hierarchy/link references. Original Jira keys are preserved separately from Nearer ticket keys.

Review the preview and every validation error before importing. Map user values to eligible existing accounts rather than creating identities through arbitrary CSV text. Points and hours remain separate; do not map one estimate into the other by assumption.

CSV alone does not restore attachment binaries or complete Jira history. Unknown historical fields/statuses need a deliberate mapping. Cross-project release assignments and changes to live release scope are rejected through imports too.

Run and resume

Imports use small resumable batches and stable source identities. Retrying the same source should not duplicate tickets. Inspect partial results and resume using the same identity instead of starting a different import to conceal errors.

For Harbor, import a few legacy support defects with original keys first. Validate their type, links and hours in the resulting tickets before continuing with a larger file. Importing mentions does not emit new historical mention alerts.

Export a backup

Administrators use Site settings backup controls. Export includes tickets, comments, retained attachment binaries/thumbnails, workflows, configuration, saved queries, sprints, dashboards, releases, notes revisions and history.

Pause team edits during export. Nearer checks content revision and rejects an export changed during preparation. Keep the downloaded ZIP independently; the app is not the only place a recovery copy should exist.

Accounts, sessions, invitations, integration credentials, personal favourites and recent-people preferences are excluded from portable content. Transient automation runs/events are not replayable backup content.

Restore deliberately

1. Arrange a maintenance window and keep a current independent backup.
2. Select the ZIP and review validation and attachment results.
3. Check the proposed content replacement and current local identity/membership implications.
4. Supply the explicit REPLACE CONTENT confirmation only when replacement is intended.

This replaces content, rather than merging a few tickets. D1 replacement is atomic and rejects concurrent content changes. Browser restore input is limited to 100 MB compressed. Authentication and integration configuration remain local.

Valid local favourites/preferences survive where their targets/users remain eligible; missing targets are pruned. Older backups receive compatible defaults for absent release/condition/attachment metadata. Removed attachments retain absolute deadlines, not a new 30-day window.

After restoration

Verify membership, attachment access, workflow mappings, release scope and saved-query/dashboard sources. Unavailable widget sources remain unavailable rather than broadening to all work. Review restored automation configuration before enabling it; it is restored disabled.

Mention indexes are rebuilt from saved content without generating historical alerts. Unknown historical actors remain historical IDs; personal saved-query ownership may be reassigned to the restoring administrator if its prior account no longer exists. A restore does not clone active GitHub credentials.

Limits and recovery failures

A malformed archive, missing binary, changed content revision or storage budget can block validation/commit. Keep the original service content and archive until resolved. Never repeatedly confirm replacement without understanding the validation result. For a small CSV problem, correct/resume the import instead of restoring the entire workspace.