Migration from NewRelic to DataDog: A Real-World Story of Growth, Cost, and Change Management
Published by Vladyslav Ratslav · Cloud Architect · January 2026
Also published on LinkedIn: Read on LinkedIn
About seven years ago, when I was working at Cloudbeds, we relied heavily on NewRelic to monitor application performance, user experience, and other critical metrics. During that period, our client base was growing extremely fast, and naturally our infrastructure had to scale with it.
To handle the increasing load without causing slowness or service degradation, we first scaled vertically by upgrading our writer RDS instance. Then we scaled horizontally by adding several more reader instances. After that, we focused on EC2 and other components – increasing instance counts, tuning performance, and optimizing configurations. Once all of this work was completed, the application became stable again, with no noticeable slowness.
Rising costs and a competing offer
Several months later, we noticed the cost of our observability stack – NewRelic – rising exponentially. At the same time, DataDog approached us with an attractive offer. After internal discussions, training sessions, and executive review, the Infra team and leadership decided to evaluate a migration to DataDog.
From our side, the decision felt driven by two forces: cost pressure and product capability. Cost was the immediate trigger; capability was the strategic justification.
Technical migration
From a technical perspective, the migration itself was straightforward. We:
- Deployed DataDog agents to our instances.
- Added the PHP library to the application and set listeners on relevant functions.
- Integrated JavaScript on required web pages.
- Recreated and configured dashboards and existing metrics in the DataDog console.
Everything worked smoothly. We observed that both NewRelic and DataDog agents consumed additional CPU and memory, but we accepted that trade-off and proceeded.
Onboarding friction and human cost
The real challenge was not the code or the agents – it was onboarding developers to a new platform.
Although everyone knew the migration was coming, discussions, presentations, and interactive learning sessions did not eliminate reluctance. What was planned as a two-month transition stretched to about six months before we disabled the last NewRelic agent. Even after the migration was technically complete, teams continued to express frustration for another six months. Fortunately, productivity remained largely intact, but the emotional and operational friction was real.
Pricing Context and Product Comparison
After the migration, I received inside information from the person who negotiated with both vendors. That context changed how I view the decision:
- NewRelic pricing change – NewRelic was moving customers to the NewRelic One pricing model, which would have tripled our cost. The negotiator escalated the case up NewRelic’s executive chain and secured a discount of nearly 90% off the new list price. With that discount, NewRelic would have been competitive on cost alone.
- Product differences – Despite the potential cost fix, DataDog’s tech stack was judged to be ahead in several areas. In particular, DataDog offered stronger log capabilities – including log rehydration – and appeared to have more active development, positioning it as a more capable single-pane-of-glass observability platform.
- Tradeoffs acknowledged – The negotiator reflected that, despite the migration pain, they would still choose DataDog in hindsight because of its long-term capabilities. They also emphasized that migrations create extra work for engineering teams, so evaluating cost, effort, and both immediate and long-term benefits is essential.
Merging these perspectives, the decision becomes clearer: we were choosing between a vendor that could have been made affordable through negotiation and a vendor that offered stronger technical momentum and product features. The choice favored long-term platform capability over a negotiated short-term cost fix, but it came with human and operational costs.
Lessons learned
Technical migrations are rarely just technical. From this experience I took away several lessons:
- Negotiate first, evaluate second – Always explore vendor negotiations thoroughly; pricing conversations can materially change the calculus.
- Weigh product momentum – Long-term product development and capabilities matter, especially for observability platforms that must evolve with your stack.
- Plan for people – Invest in change management early: involve developers in vendor evaluations, create hands-on migration paths, and set realistic timelines for adoption.
- Balance cost and effort – Consider both immediate savings and the long-term operational burden on teams.
Bottom line: We reduced observability costs and moved to a platform with stronger long-term capabilities, but the migration highlighted how important it is to combine vendor negotiation, technical evaluation, and deliberate change management into a single, coordinated strategy.