By Nate Rich, Principal Engineer at Foulk Consulting
Every enterprise observability rollout follows a familiar trajectory.
Phase one begins with genuine momentum. Executive sponsors sign off on the New Relic contract, leadership announces the initiative, and the platform engineering team deploys infrastructure agents across host clusters via Terraform or Ansible. Within weeks, you have thousands of entities reporting basic metrics, CPU spikes, and memory utilization to your dashboards. Victory feels close.
Then comes phase two: The Mid-Migration Slump.
Suddenly, progress slows to a crawl. Core development teams haven’t set up custom APM instrumentation. Distributed tracing lies dormant across microservice boundaries. Developers still rely on legacy logging tools or raw SSH sessions to debug incidents. Meanwhile, executive stakeholders start asking why the platform isn’t yielding the high-visibility ROI and mean-time-to-resolution (MTTR) reductions promised in the business case.
If this sounds like your organization, you aren’t alone. Installing an agent is an operational task; driving deep, cross-team platform adoption is a cultural shift.
Here is why your rollout stalled, and how to use our “Defining ‘Done'” framework to re-energize your teams, expand platform utility, and demonstrate clear ROI.
Why Rollouts Stall: The Gap Between “Installed” and “Adopted”
The primary cause of the mid-migration slump is confusing deployment with adoption.
Deploying standard host or container agents requires zero application context. An infrastructure engineer can roll them out globally in an afternoon. But turning New Relic into the primary tool for daily engineering workflows requires product engineering teams to make active changes:
Configuring custom application performance monitoring (APM) agents.
Defining meaningful Service Level Indicators (SLIs) and Service Level Objectives (SLOs).
Curating alerting policies to prevent notification fatigue.
Contextualizing logs, traces, and metrics under unified entity tags.
When developers view observability as an administrative task imposed by centralized IT, rather than a tool that saves them time during on-call rotations, they will prioritize feature delivery every time.
Step 1: Reframe “Done” Using the Maturity Framework
In our earlier discussions on observability strategy, we introduced the concept of Defining “Done.” To break out of a slump, engineering leaders must move away from binary metrics like “80% of servers have agents installed” and adopt a multi-tiered maturity definition.
Clear milestones show teams what success looks like beyond basic infrastructure tracking:
[Level 1: Basic Visibility]
– Host/Infra agents live
– Out-of-the-box metrics
– Basic ping checks
[Level 2: Contextual APM]
– APM agents attached
– Error Inbox configured
– Alert threshold tuning
[Level 3: Full-Stack Correlation]
– Distributed tracing across services
– Unified logs-in-context
– Custom business telemetry (NRQL)
The Three Tiers of “Done”
Level 1: Baseline Visibility (The Easy Part)
Host and Kubernetes infrastructure agents installed.
Standard CPU, memory, and disk utilization reporting.
Level 2: Application Context (Where Slumps Occur)
APM attached to all critical services.
Noise-reduced alerts mapped directly to PagerDuty or Opsgenie.
Error Inbox integrated into sprint workflows to catch regressions early.
Level 3: Operational Excellence (True Observability)
Distributed tracing enabled across API boundaries.
Logs-in-context linked directly to trace IDs and APM transactions.
Business-level NRQL events tracking user journeys and application health.
By explicitly stating that Level 1 is not “Done,” you reset expectations across the organization and give teams a clear target for Level 2 and Level 3 adoption.
Step 2: Practical Tactics to Re-Energize Engineering Teams
You cannot demand adoption through policy alone; you need to reduce friction for developers.
1. Build “Paved Paths” and Automation Templates
Developers shouldn’t need to learn the intricacies of New Relic configuration from scratch. Provide them with ready-to-use patterns:
Infrastructure-as-Code (IaC) Snippets: Provide reusable Terraform modules for deploying standard alert policies, synthetic monitors, and workload definitions.
Auto-Instrumentation: Utilize New Relic OpenTelemetry auto-instrumentation packages for common runtimes (Node.js, Java, Python, .NET) so developers can attach telemetry via simple environment variables rather than custom code changes.
2. Kill the Noise (Defeat Alert Fatigue)
Nothing kills platform adoption faster than hundreds of noisy, non-actionable alerts flooding Slack channels.
Conduct an audit of all active alert conditions.
Delete or disable any alert that doesn’t require immediate human action.
Enforce Golden Signal alerting (Latency, Traffic, Errors, and Saturation) focused on user impact rather than low-level host metrics.
3. Run “Observability Office Hours” & Game Days
Assign platform engineers to hold weekly drop-in sessions to help feature teams solve specific problems, like diagnosing a slow SQL query or setting up custom NRQL alerts. Organize a “Chaos Game Day” where engineers use New Relic in real-time to locate induced system faults.
Step 3: Expand Platform Utility Beyond Basic APM
To keep momentum going, show teams how New Relic solves everyday engineering pain points that extend beyond system crashes.
Fix Flaky Deployments with Deployment Markers: Integrate New Relic deployment markers into your CI/CD pipeline (GitHub Actions, GitLab, Jenkins). When a build goes live, developers can immediately compare error rates and latency before and after the release.
Trace Bottlenecks with Distributed Tracing: Show frontend and backend teams how distributed tracing reveals latency hidden deep within microservice call chains or third-party API dependencies.
Unify Logs with APM: Moving between a separate log management tool and an APM platform wastes valuable debugging time. Enabling logs-in-context lets developers jump from a spike in HTTP 500 errors straight to the exact stack trace and log line in two clicks.
Step 4: Prove Continuous ROI to Leadership
While developers care about debugging speed, executive leadership cares about cost efficiency, system reliability, and business impact. To secure ongoing sponsorship for your observability initiative, build executive dashboards that translate technical telemetry into business metrics.
Technical Metric
Executive / Business Translation
Mean Time to Resolution (MTTR)
Saved engineering hours during major incidents
Apdex / Latency Trends
User experience quality during high-traffic events
Synthetic Uptime Percentage
SLA compliance for enterprise customer agreements
Cloud Resource Utilization
Right-sizing opportunities to reduce cloud infrastructure spend
Using New Relic’s NRQL (New Relic Query Language), you can consolidate these operational indicators into single-pane-of-glass executive dashboards that demonstrate how platform adoption directly protects revenue and engineering velocity.
Moving Forward: Getting Your Migration Back on Track
A stalled migration isn’t a failure, it’s a predictable phase in technology adoption. Moving from basic monitoring to deep observability requires shifting focus from deploying tools to enabling engineers.
If your New Relic rollout has hit a plateau:
Audit where your teams sit on the “Defining ‘Done'” maturity scale.
Remove developer friction with automated templates and clean, low-noise alerting.
Focus on high-value features like deployment tracking and logs-in-context that save developers time today.
Measure and publish ROI metrics to maintain executive alignment.
Need Help Unblocking Your Observability Strategy?
At Foulk Consulting, we help enterprise engineering organizations navigate complex observability rollouts, optimize platform usage, and align technology investments with business outcomes. Reach out to our team today to learn how we can help you accelerate your New Relic deployment.
*** Nate Rich is a Principal Engineer at Foulk Consulting, where he helps enterprises master performance engineering and full-stack observability.
