Migrate your Relic ERP data

Entities represent monitored hosts, applications, containers, and services. New Relic assigns each entity a GUID that we preserve in migration to maintain relationship maps and workload groupings in the destination.

Application performance monitoring data includes transactions, error rates, throughput, and Apdex scores. We migrate application configuration and historical metric snapshots within retention constraints.

Real user monitoring data for web applications includes page load timing, JavaScript errors, and session data. We map these to destination RUM equivalents preserving segmentation attributes.

Custom events inserted via agent APIs or Event API require schema mapping since destination platforms may not support identical custom event types. We preserve attribute names and values as custom properties or equivalent fields.

Dashboards built with NRQL widgets require translation to destination query languages (PromQL, SQL variants). Static visualizations and chart configurations are migrated as-is; computed widgets are flagged for manual review.

Classic notification channels are being replaced by Workflows. Migration must account for whether source account uses legacy alert configurations or the newer workflow model, as these have different API structures.

Synthetic monitoring scripts for uptime checks, scripted browsers, and API tests are exported via REST API and re-created at destination with equivalent credentials and schedule intervals.

Logs are stored under consumption-based ingest limits with automatic PII masking. Historical log export is available via Data Plus; standard tiers have 8-day default retention. We flag which log records fall outside accessible retention windows.

Infrastructure monitoring entities include hosts, Kubernetes clusters, and cloud integrations. We preserve host-level metrics, process data, and integration configurations during migration.

Workloads group entities by service or team ownership. We map workload assignments to equivalent grouping constructs in the destination platform, since not all observability platforms support the same workload abstraction.

Entity tags and changelog annotations must be re-applied post-ingest in most destination platforms, as tag schemas differ. We provide a tag mapping spreadsheet to guide bulk re-tagging after migration.

New Relic has three user types: Basic (free), Core, and Full Platform. Role assignments, organization permissions, and notification preferences require mapping to destination user management models.