Once Optimizely DXP migrates the .NET stack from Classic SDK 2.x to OpenTelemetry (required by 2027-03-31 when Microsoft retires Classic 2.x support), please add a per-environment config that lets DXP customers register an additional telemetry exporter pointing at their own Application Insights resource (or OTLP endpoint). DXP's existing exporter stays untouched.

Why customers need this

DXP application telemetry currently goes only to a DXP-managed Application Insights resource. Customers can be granted read-only API-key access, but that's insufficient for:

• End-to-end distributed traces spanning customer-owned frontend/API services and the CMS backend. W3C traceparent already propagates correctly through DXP's Classic SDK 2.21.0 — the trace data exists, we just can't get it into our own resource.
• Unified SIEM / log-aggregation feeds (Splunk, Datadog, Elastic, etc.) that expect one ingestion path.
• Customer-controlled retention, sampling, and access policies.

API-key access doesn't enable Azure cross-resource KQL (which would help) because that's gated on Azure AD RBAC, and DXP support cannot grant RBAC per policy. The only current workaround is for every customer to build their own pull-and-forward integration — duplicated engineering effort across the customer base.

Why this is now feasible and low-risk

OpenTelemetry is designed to support multiple exporters per signal — adding a second is a one-line SDK registration with zero impact on the first. The double-counting / Activity.Current conflict concerns that apply to mixing Classic SDK 2.x with the OTel Distro don't apply once the whole stack is OpenTelemetry-based. DXP's existing pipeline, dashboards, alerts, and SLA stay exactly as today.

Proposed implementation

A per-customer-per-environment config in the DXP portal:

• CUSTOMER_APPLICATIONINSIGHTS_CONNECTION_STRING → DXP registers a second AzureMonitorExporter.
• Or more generally, OTEL_EXPORTER_OTLP_ENDPOINT for any OTLP destination (Datadog, New Relic, Splunk OTLP, Grafana Tempo, self-hosted collectors, etc.).

Customer-supplied Azure Monitor endpoints are in the same domain family as DXP's own (already allowlisted in egress). Per-customer opt-in; zero impact on customers who don't enable it.