Existing Workspaces and Migration

Prev Next

Co-existence with Non-Control-Plane Workspaces

Enabling the Control Plane feature toggle does not retroactively change any existing workspaces. Environments can have a mix of Control Plane and non-Control-Plane workspaces running side by side:

  • Existing workspaces continue to operate exactly as before — machine, machine type, and facility data remains embedded in pipeline configurations

  • New workspaces created after the toggle is enabled automatically have Control Plane active

  • There is no disruption to running pipelines, deployed configurations, or analytics in existing workspaces

This design supports a gradual rollout — you can enable the toggle, create new workspaces with Control Plane, and keep existing workspaces unchanged until you are ready to migrate them.

Migrating an Existing Workspace to Control Plane

To bring an existing workspace into Control Plane, copy the workspace while the Control Plane toggle is enabled. The copy process automatically migrates your data:

What is automatically migrated:

Source

What Gets Created

Deployed machines

Machine assets in Control Plane

Deployed machine types

Machine type assets in Control Plane (name and display name only — analytics and stats configurations are pipeline-derived and are not migrated)

Existing facility data

Facility assets are already present from prior pipeline deployments; facility identifiers are updated to the current naming format

What is not automatically migrated:

Item

Why

What to Do

Tag list

Must be created for each workspace's specific tag set

Create or upload a tag list via CSV, often by transforming an existing data dictionary to the tag list format

Pipeline operator references

Pipelines still use the legacy Map Machines operator

Replace with the Control Plane-aware Map Machines operator in each pipeline

Data dictionary references in Jinja

Pipeline templates may reference prior tag data dictionaries

Update Jinja expressions to reference the Tag List data dictionary

Post-Migration Steps

After copying a workspace to create a Control Plane version:

  1. Review machine assets — Verify the expected machines are present and have the correct machine type and facility assignments.

  2. Upload a tag list — Create or upload the tag list via CSV. If your previous workspace used a custom data dictionary for tag data, transform it to the tag list column format (see Tag CSV Format).

  3. Update pipelines — Replace all legacy Map Machines operators with the Control Plane-aware version. Update any Jinja expressions that referenced prior tag data dictionaries to reference the Tag List data dictionary instead.

  4. Redeploy pipelines — Redeploy each pipeline in place. This does not change pipeline data or metadata — it recomputes pipeline dependencies to include the new Control Plane assets and moves pipelines out of edit mode.

📝 Note: The redeployment in step 4 is a housekeeping step. It has no effect on your pipeline data or analytics — it simply ensures pipelines recognize their new Control Plane dependencies.

⚠️ Warning: Do not skip the pipeline update step (step 3). Pipelines using the legacy Map Machines operator will not read from Control Plane data and will not benefit from centralized asset management.