Legacy Dashboard Migration

Dashboards created before the introduction of capture data in early 2020 (legacy dashboards) must be migrated to dictionary-driven dashboards. This migration is necessary because the legacy feature set is no longer being updated nor supported.

Dashboard Migration

General Migration Notes

1. Migration creates new dashboard models without modifying or overwriting the original legacy models. The new models only persist when a user authors and saves the dashboard.

2. Dashboards that have already been migrated and saved should be excluded from the migration process.

3. Since legacy dashboards did not include sections, all cards will migrate into the default section.

Global Attributes

Legacy dashboards have the following persisted features that require migration (all other features are transient):

1. Category and name (global) - Migrate 1:1
2. Threshold profile (global) - The selected threshold profile will be migrated into individual cards/widgets (local) that consumed a threshold profile (e.g. events)
3. Metadata filters (global) - Migrate 1:1 into dimension filters
4. Sharing settings (global) - Migrate 1:1
5. Cards (see following)

Cards

Eight different card types (legacy cards represent a single widget) have been identified.

1. Timeseries (measure)
2. TopN/Table (measure)
3. Timeseries (events)
4. TopN/Table (events)
5. Pie (events)
6. Timeseries (bins)
7. TopN/Table (bins)
8. Pie (bins)

To support this migration, we have introduced two new features in the new dashboards.

Timeseries (Bins/Threshold Profiles)

Example of a migrated timeseries with threshold profile events/bins: before migration (left), after migration (right):

Table (Bins/Threshold Profiles)

Example of a migrated table with buckets/bins: before migration (left), after migration (right):

Card Migration

The general approach to migration is:

1. Migrate the name (1:1 mapping).

2. Migrate grid position, now modeled as X and Y coordinates due to changes in the grid system.

3. Migrate card filters into dimension filters (1:1 mapping).

4. Migrate metric models with options based on widget type, buckets, and events.

5. Migrate any widget-specific parameters, such as limit or sort order.

Grid Migration

Legacy grids used Muuri, a grid packing system where each item is assigned a width, height, and a numeric position (e.g., 0, 1, 2). Items are arranged based on their position and wrap to the next row when they run out of columns for the next card's width.

To migrate, we must order the cards by position and then use the width of the card along with the current X position within the grid to determine when to shift to the next row. When we shift to the next row, we use the Y position for the tallest card in the previous row and add title spacing (all legacy cards have titles) to make the next row line up correctly.

Legacy cards may specify explicit row heights or use a default value based on the widget type. The Muuri grid system used 100px units, whereas the current Gridstack grid uses 16px units. As a result, we scale height units by approximately a factor of six (~6).

Widget Specific Considerations

Pie Widget

The legacy pie widget supported multiple metric directions with a dropdown to toggle between them. The aggregate widget has no equivalent. In these cases, we split the legacy card into a widget per metric/direction and display all widgets within the prior card grid dimensions, dividing the space equally amongst the widgets.