Migrate from the legacy Openflow Connector for Jira Cloud¶

Overview¶

The new connector is a complete rewrite that changes how data is stored in Snowflake. It consists of two separate flows: a core flow (issues, projects, comments, changelogs, worklogs, users, votes, watchers, remote links, issue security schemes, and optionally deleted issues) and an agile flow (boards, sprints, board mappings).

The core flow and agile flow can write to the same Snowflake destination schema, since they create tables with different names. The legacy connector and the new connector can run side by side during migration — including on the same Openflow runtime — as long as they write to separate destination schemas, so you can validate the new output before decommissioning the legacy connector.

Feature comparison¶

Key differences¶

Migration steps¶

1. Set up the new connector. Install the core flow on the same or a different Openflow runtime. If you need agile data, also install the agile flow. Configure both flows to write to a different destination schema than the one used by the legacy connector. This allows the legacy and new connectors to run simultaneously.

2. Map your legacy configuration to the new parameters.

   • Copy the Jira Email, Jira API Token, and Environment URL values from the legacy connector to the new core flow. If using the agile flow, configure these values separately for that flow as well.

   • If the legacy connector uses Project Names, convert them to project keys for the Project Keys Filter parameter.

   • If the legacy connector uses a JQL Query, evaluate whether Project Keys Filter covers your use case. If your JQL filters by criteria other than project (for example, status or custom fields), those filters aren’t available in the new connector. All matching issues from the configured projects are ingested.

   • Set Issue Fields to match your previous configuration. The default changed from *all (legacy) to *standard.

   • Configure the Snowflake destination parameters (database, schema, warehouse, credentials) for each flow.

3. Start the new connector. Run the core flow and allow the initial load to complete. If using the agile flow, start it as well.

4. Validate the data. Compare the data in the new destination tables against the legacy destination table to check for completeness. Expect some differences: the legacy connector didn’t track deletes, so issues that were deleted in Jira still appear in the legacy table but not in the new ISSUE table (or they appear with _SNOWFLAKE_DELETED = TRUE if delete tracking is enabled). Row counts will not match exactly when any issues have been deleted.

   CopyExpand

   -- Compare issue counts (expect differences if issues were deleted in Jira)
   SELECT COUNT(*) AS legacy_count FROM legacy_schema.JIRA_ISSUES;
   SELECT COUNT(*) AS new_count FROM new_schema.ISSUE;
   
   -- Spot-check specific issues
   SELECT KEY, SUMMARY, STATUS FROM new_schema.ISSUE WHERE KEY = 'PROJ-123';
   

   Show lessSee more

   Scroll to top

5. Update downstream queries. Rewrite any queries, views, dashboards, or pipelines that reference the legacy table structure. Key changes:

   • Replace references to the legacy ISSUE OBJECT column or _VIEW with direct column references.

   • Replace FLATTEN-based queries with standard SELECT statements.

   • Add JOIN statements to combine data across the new entity tables (for example, join ISSUE with COMMENT on ISSUE_ID).

   • If you want queries to ignore deleted issues, filter on the new _SNOWFLAKE_DELETED column (WHERE _SNOWFLAKE_DELETED = FALSE). The legacy connector didn’t track deletes at all, so legacy queries against JIRA_ISSUES returned issues that had since been removed in Jira.

6. Stop the legacy connector. Once you’ve confirmed that the new data is complete and downstream consumers have been updated, stop the legacy connector process group. Both new flows (core and agile) can continue running independently.

7. Clean up. Optionally, drop the legacy destination table and view after confirming they’re no longer needed.