Skip to main content
Flexible Boards introduce a new structure for organizing and displaying queries and Service Level Objectives (SLOs) in Honeycomb. You can migrate existing Boards to the Flexible Boards format using the Honeycomb UI, API, or Terraform. Choose the migration method matching how you manage your Boards:
On August 15, 2025, the Honeycomb API will stop supporting legacy Boards. Any Board API calls that use "type": "classic" or omit the type field will fail.By August 29, 2025, Honeycomb will automatically migrate any remaining legacy Boards to the Flexible Boards format. During this process, query captions will move into the corresponding query’s description field.

Migrate an Individual Board in the UI

The UI is the easiest option if you manage Boards manually. To migrate a Board using the Honeycomb UI:
  1. Open the Board in the Honeycomb UI.
  2. Select Preview as Flexible Board in the banner to review the updated layout.
  3. If the preview looks correct, select Migrate board now to complete the migration.
If your Board is managed via Terraform or the Honeycomb API, you must also update your API payload or Terraform configuration to use the Flexible Board format.

Migrate Boards Using the Honeycomb API

If you use the API to create or update Boards, you need to update your request payload to match the Flexible Board format. The Flexible Board format introduces two key changes:
  • The panels field replaces the queries and slos fields. To learn more about the panels field, visit the Honeycomb API documentation.
  • The type field, which represents the Board type, must be set to flexible. To learn more about the type field, visit the Honeycomb API documentation.
    On August 15, 2025, the Honeycomb API will stop supporting legacy Boards. Any Board API calls that use "type": "classic" or omit the type field will fail.
To migrate a Create Board or Update Board request:
  1. Set type:flexible in your request payload.
  2. Remove these deprecated fields:
    • column_layout
    • style
  3. Replace queries and slos fields with panels.
  4. Add layout_generation and set it to auto. This helps automate panel positions.

Example: Convert a Legacy Board Payload to Flexible Format

In this example, we show you how to migrate a legacy Board API payload containing the queries and slos fields to a Flexible Board payload. The example legacy Board payload is as follows:
To convert the legacy Board payload:
  1. Start with an empty panels array:
  2. Add your SLOs as panels. Each slo maps to a panel, so each SLO requires its own panel:
  3. Add your queries as panels. Each query also requires its own panel:
  4. Add layout_generation and set it to auto. This helps automate panel positions.
Once you update your API requests using this structure, you are ready to create and update Flexible Boards.

Migrate Boards Managed by HashiCorp Terraform

To migrate Boards defined in Terraform, update your Terraform configuration:
  1. Upgrade to v0.37.0 or later of the Honeycomb.io Terraform provider.
  2. Replace honeycombio_board blocks with honeycombio_flexible_board blocks.
  3. Convert query and slo blocks to panel blocks.

Example: Manually Convert Legacy Board to Flexible Board in Terraform

In this example, we show you how to update a Terraform configuration file to convert a legacy Board to a Flexible Board. The example legacy Board Terraform configuration file is as follows:
To convert the example configuration file:
  1. Create a honeycombio_flexible_board resource:
  2. Add your Board’s name and description to your new resource:
    The column_layout and style fields are not supported in the honeycombio_flexible_board resource.
  3. Add SLO panels. For each of your slo blocks in honeycombio_board resource, create an equivalent panel block:
  4. Add query panels. For each of your query blocks in the honeycombio_board resource:
    • Create an equivalent panel block
    • Replace graph_settings blocks with visualization_settings blocks
      The honeycomb_board legacy resource uses utc_xaxis while the honeycomb_flexible_board resource uses use_utc_xaxis. To learn more about these changes, visit the Honeycomb Terraform Flexible Boards documentation.
  5. Replace your old honeycombio_board block with your new honeycombio_flexible_board block. Your final configuration should look similar to:

Example: Manually Convert Legacy Board to Flexible Board Without Recreating IDs in Terraform

This example requires manual migration steps using the Honeycomb UI, and relies on import/removed blocks in Terraform. The described migration process below will generate an initial configuration file that then can be adapted to replace your legacy Boards configuration file. This approach will generate most Terraform elements for you, but you can refer to the previous example’s migration guide to change your honeycombio_board to honeycombio_flexible_board resource.

Before You Begin

If you are using dynamic IDs for your query, query_annotations, and/or slos, ensure that you update the generated configuration file to remove the hardcoded ID and replace them with your existing dynamic logic.
Before you begin, you will need:
  • One or more existing legacy Boards that were created through a Terraform configuration.
  • The ability to commit the newly created Terraform configuration.

Migration Process

This example legacy Board Terraform configuration file includes four different Boards:

Step 1: Locate Your Board Information via the Honeycomb UI

To start your migration process, locate and copy the board ID located in each Board’s URL, which is formatted similarly to:
You will use this board ID to import via your Terraform configuration. Here is how our example boards appear with their board IDs:

Step 2: Update your Terraform Configuration

Manually update your Terraform configuration with an import block and a remove block for each Board. For our example, our updated Terraform configuration looks like:

Step 3: Generate the Terraform Configuration Based on the Migrated Boards

Use the following command (and replace with your relevant variables) to generate your Terraform configuration:
  • -generate-config-out flag is an option that allows Terraform an auto-generated configuration file to dump at the specified path. In the above example, the new Terraform configuration will be dumped in migrated.tf.
Results
After running the command, the output for our example looks like:

Step 4: Run terraform apply to Ensure Proper Syncing

Use the following terraform apply command (and replace with your relevant variables):
This command will:
  • remove the honeycombio_board resource from the state and prevent their deletion
  • add the honeycombio_flexible_board resources to the state and enable them
Results
After running the command, the output for our example looks like: