Environments & Services Migration FAQ

​

What is an in-place migration?

An in-place migration converts your existing Classic environment into an Environments & Services (E&S) environment through behind-the-scenes, database-level changes. It unlocks all of the newer E&S-gated features without requiring you to re-instrument, re-send data, or restructure anything. Everything keeps working the way it does today - you simply gain access to the new capabilities. This is different from the older E&S migration path, which involved dual-sending data and rebuilding your SLOs, triggers, and boards in a new environment. The in-place approach skips all of that.

​

Is there any downtime, and do I need to do anything?

No downtime, and no action required on your side. There’s no dual ingest, no data backfill, and nothing to reconfigure. Your data stays exactly where it is - nothing moves or is copied. The migration itself typically takes less than a minute.

​

What stays the same?

Everything you rely on today continues to work, untouched:

• All existing datasets remain exactly as they are
• All boards, SLOs, triggers, and saved queries stay in place and keep pointing at the same data
• All API keys remain unchanged — no need to rotate keys or update your collector, SDKs, or Terraform
• All existing permalinks are automatically redirected to the new environment (for very large teams this redirect can take a little longer to fully propagate)

​

What changes, and what do I gain?

The main visible change is that your environment is no longer labeled “Classic” - we give it a new name of your choosing during the migration. The big win is access to E&S-gated features, including:

• Honeycomb Intelligence
  • Canvas and the MCP server
• Service Maps
• Relational fields
• Environment-wide queries

To use certain AI-powered features, you may be prompted to accept the Honeycomb Intelligence terms of service.

​

How is my data routed into datasets after migration?

This is the one important behavioral detail to understand. In a standard E&S environment, the service.name attribute on your telemetry determines which dataset data lands in. In an in-place migrated environment, your existing routing is preserved: the x-honeycomb-dataset header (or the dataset specified in your API path) still takes priority. In practice this means your dataset structure stays exactly as it is today. Note: any new environments you create after migrating will behave like normal E&S environments (routing by service.name). Only this migrated environment keeps the header-priority behavior.

​

Can I test it first, or migrate just a few datasets?

The migration applies to the whole Classic environment at once - individual datasets can’t be migrated one at a time. However, there’s a clean rollback available, so if you do find any issues after being migrated, you can work with either support or your account team to roll back the change and we will work with engineering to fix the source of the problem before attempting the migration again. We have used this migration tooling for some of our largest customers and had no issues. We have very high confidence in the effectiveness and minimal impact of this process.

​

Is there a rollback if something goes wrong?

Yes. There’s a rollback function that cleanly reverts the environment back to Classic. Because the migration is a set of database-level changes (and doesn’t touch your stored telemetry), rolling back is just as quick as the original migration.

​

What happens to my metrics?

A few things worth knowing:

• Metrics have always required the dataset header for routing — they’ve never used service.name — so metrics routing is unaffected by the migration.
• Customers are getting communications on migrating to Time Series Metrics instead of Metrics as Events. That is not a part of this Classic environment upgrade. Time Series Metrics will be sent to the Metrics dataset, while Metrics as Events will be sent wherever the x-honeycomb-dataset header indicates.
• With Time Series enabled, OTLP metrics route into a dedicated metrics dataset regardless of any header. If you have multiple environments (dev, QA, prod) feeding metrics, they’ll share that dataset, so make sure your metrics carry resource attributes that let you filter by environment or service.

​

Will Service Map still work?

Yes. Service Map is driven by your dataset’s service name definition (the attribute you map in your dataset settings), not by the dataset header or your dataset list. As long as that definition is in place, Service Map works as expected.

​

Will Terraform or my API tokens need changes?

No. API keys don’t change, and Terraform continues to use the same keys to identify the environment. You’d only need new keys if you later decide to route telemetry into a brand-new environment.

​

What if I want to fully adopt the E&S model (a dataset per service) later?

That’s entirely optional and can be done on your own timeline after migrating. The typical path is:

1. Stand up separate new environments for Production, dev, QA, staging, etc…
2. Update API keys to send environment appropriate data to the new environments
3. Recreate any SLOs, triggers, and boards to point at the new per-service datasets.
   1. Triggers and Board Queries can be environment wide to make it easier to recreate these in a standard E&S environment
   2. SLOs can have as many as 10 datasets attached to them, to target them at the appropriate services for each SLO.

There’s no requirement to ever do this — the migration gives you all E&S features permanently regardless.

​

Build boards with queries spanning multiple environment-scoped datasets

In-place migrated environments keep the ability to build boards with queries spanning multiple environment-scoped datasets — for example, comparing QA against prod on a single board. This is a capability many standard E&S customers have asked for.