This page is about the mechanics of a change-over. It does not compare products, and it names none.

The most important point: history itself lives in Jira

Every Jira change-history app reads the same thing: the changelog Jira keeps on each work item. That data belongs to Jira, not to any app.

So when you swap apps:

  • Nothing is migrated, and nothing needs to be. The full history of every work item is still in Jira, and this app reads it the moment it is installed. A report run today covers changes made years before the app existed.
  • Uninstalling your previous app does not remove history from Jira.
  • There is no import step, and no window where history is unavailable.

The things that are app-specific are the app’s own records: captured deletions, saved views and configuration. Those do not transfer between vendors.

What does not carry over

Thing What happens
Change history Nothing to do. It is Jira’s, and both apps read it
Deleted work items already captured by the other app Stay with that app. Restore anything you still need before you uninstall it
Saved views, filters or reports defined in the other app Rebuilt by hand here. See below
Scheduled or emailed reports in the other app Recreated here as scheduled reports, delivered to a Jira work item
The other app’s comment or view tracking records Stay with that app
Exported files Yours already; keep them

The order to do it in

  1. Install this app alongside the other one. Two Forge apps reading history do not conflict. Both can be installed during the evaluation.
  2. Run a backfill here, from Settings → Marketplace apps → UndoTrail → Backfill. Capture only starts at install, so every work item untouched since then has no snapshot. The backfill takes a full snapshot, custom fields included, of each one the app can read. Run it once, before you rely on this app for recovery.
  3. Recover anything still sitting in the other app’s deleted bin. Its records are not readable from here and will go when it is uninstalled.
  4. Rebuild your saved views here, while the old app is still installed to copy the definitions from.
  5. Compare exports (see below) until you are satisfied the numbers agree.
  6. Tell your users where the app now lives: Apps → UndoTrail, the project sidebar, and the History+ tab on a work item.
  7. Set permissions and retention before you uninstall the old app, so there is no gap in what is captured or who can see it.
  8. Uninstall the other app. Its records are no longer available to you from then on.

There is one gap you cannot close: work items deleted before this app was installed, or during any window when neither app was installed. Keep the old app until you are comfortable that its retention window no longer matters to you.

Rebuilding saved views

A view here stores the whole query: scope, dates, every filter and the presentation. Rebuilding one is a few minutes of work:

  1. Open the report definition in your old app and note the projects, dates, people, fields and any JQL.
  2. In the explorer, set the scope and press Run.
  3. Apply the equivalent filters. Many filters people needed JQL for in other tools are direct controls here: NOT filters, transitions on any field (A → B, → B, A →), work item keys and sprints.
  4. Press Save view, name it, and tick Share with everyone in this Jira if colleagues used the old one.
  5. Copy the share link into wherever the old report was linked from, such as a Confluence page or a runbook.

See Saved views and sharing.

Comparing exports

The reliable way to satisfy yourself that nothing is missing:

  1. Pick one project and one month, for example project = OPS and last month.
  2. Export the same period from both apps as CSV.
  3. Sort both by the UTC timestamp, then by work item key, then by field.
  4. Compare row counts first, then the rows themselves.

Differences you should expect, and which are not errors:

Difference Why
A few more rows here This app adds a synthetic Created row per work item, because Jira’s changelog has no entry for creation
Different totals per person Each app reads under the permissions of the person running it. Compare exports produced by the same account
Time columns differ Check the UTC column, not the local one. This app exports both, plus the offset
One app splits a multi-value change differently One edit that changes two components is two history entries in Jira. The activity view shows both; the table view merges them into one cell
Rows missing at the end Check whether either export was truncated at a work item limit. This app tells you on screen when a load stopped early

If a row appears in one export and not the other, look it up in Jira’s own history on the work item. Jira is the arbiter.

What to check before you commit

Check Where
Reports return what you expect for a known project and month Reports and the explorer
Exports open correctly in your spreadsheet, with the right delimiter Exports
A test deletion is captured and the restore preview looks right Deleted items
Retention matches your policy Admin settings
The right groups have the right features Admin settings
Comment and viewer tracking match your privacy position Tracking
Security questions are answered for your reviewers Permissions and security

Limitations to plan around

  • Deleted-item capture begins at install. Run the backfill, and accept that earlier deletions are not recoverable here.
  • Saved views, gadget configurations and tracking records do not transfer between vendors.
  • Restored work items get new keys, whichever app does the restoring, because that is a Jira constraint.
  • This app sends no email, because it has no egress. If your old workflow depended on an emailed report, set up a scheduled report: the file is attached to a Jira work item every day, week or month, and Jira notifies the people watching it.