Migrating BriteData Reports with Report Copilot

Beta Note: The BriteData migration tool is part of the Report Copilot beta. If you do not see the migration option on your site, contact your BriteCore account team.

Many sites still run legacy BriteData reports: YAML-defined reports built on the older dataframe engine. Report Copilot can translate a BriteData report into a SQL Editor report that produces the same output from the logical views, so the report can be maintained, scheduled, and extended with the tools described in this series. The Copilot writes the SQL, runs it, compares the result with the report's most recent BriteData output, and refines the SQL until the two agree, then saves the result as a SQL Editor report for your review.

Eligible Reports

BriteCore surveyed each site's BriteData reports and prepared a migration plan for the reports that had been run and downloaded within the previous twelve months. A report's status is shown in the migration list in SQL Editor:

• Available for migration: the report was included in the survey and the Copilot has a conversion plan for it.
• Not supported for migration: the report was not included in the survey, usually because it had no recent usage. If a report you still rely on is marked unsupported, contact BriteCore support so it can be added to the survey.

Only YAML-based BriteData reports are in scope for the Copilot tool. Custom Python reports and other legacy report types are handled separately by BriteCore.

Prerequisites

• Run the BriteData report once from the Report List so there is a recent, successful execution for the Copilot to compare against. The comparison uses the output file of the latest successful run.
• Note the report's parameters and the date range you used, so you can run the migrated report with the same inputs.
• Work in UAT if you have one, then export the finished SQL Editor report as JSON and import it in production.

Migration Steps

1. In SQL Editor, select Open and open the BriteData report you want to migrate. Because the report is a legacy BriteData report, SQL Editor shows the migration dialog instead of the normal editor. If a migration of this report was started earlier and not finished, the report shows a Resume badge and you can pick up where you left off.
2. Start the migration. Report Copilot opens with the report's definition, column mapping, and date handling already loaded.
3. The Copilot generates the SQL, runs it, and compares the result with the report's last BriteData execution: column names, row counts, and the distribution of values. If they differ, it adjusts the SQL and tries again, up to three times. You can watch the progress and the Copilot's notes in the chat panel.
4. When the Copilot finishes, it presents the new report with a Changes Summary that explains what was translated and any differences you should be aware of. Review it.
5. Select Save Migration. The result is saved as a SQL Editor report with the same name and description, and the migration is marked complete.
6. Run the new report from SQL Editor with the same parameters you used for the original, and compare the output with the BriteData file. When you are satisfied, publish it so it appears in the Report List.

A report can be migrated once. If you need to redo a migration, ask BriteCore support to reset it.

Missing Previous Run

The comparison step needs the output of a recent successful run of the BriteData report. If the Copilot reports that no past execution was found:

1. Run the BriteData report from the Report List and wait for it to complete, then start the migration again.
2. Download a previous output file of the BriteData report and attach it to the Copilot chat using the paperclip icon. The Copilot will use the attached file for the comparison.

Without a prior run the Copilot still translates the report, but it cannot validate the result against real output, so review the migrated report more carefully.

Post-Migration Checks

The Copilot matches the data, not every presentation detail of the legacy report. Compare the two outputs and check in particular:

• Summary sheets. BriteData reports that produced a summary sheet in addition to the detail sheet are migrated as a single detail sheet. Add a second sheet with the summary query if you still need it.
• Date semantics. Confirm that balances that should be cumulative "as of" the end date are not being limited to activity within the date range, and that the report filters on the same date field as the original (for example, loss date versus report date).
• Column formats. Set currency, date, and percent formats on the output columns; see Formatting Output Columns.
• Cover sheet and links. Turn on the cover sheet in Settings if the legacy report had one. Values that were selectable links in the legacy output (such as claim numbers) are plain text in the migrated report.
• Column order and headers. Reorder or re-alias columns in the SQL if downstream users depend on the legacy layout.

Common Messages