> For the complete documentation index, see [llms.txt](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-34-34-migration-done-right.md). # Day 34/34 Migration Done Right ## 🔍 From Server Health to Service Observability: The OpenTelemetry Journey System monitoring has evolved—from focusing on individual server health to observing distributed service components. With OpenTelemetry (OTel), the industry now has an open standard for end‑to‑end tracing, logging, and metrics, backed by a growing ecosystem of vendors and tools. In theory, OpenTelemetry provides everything an organization needs for modern observability. In reality, however, most organizations still operate traditional monitoring infrastructures, built over many years on top of multiple, heterogeneous products. So the real challenge isn’t whether OpenTelemetry is the future—it’s how to migrate from traditional monitoring solutions to an OTel‑based architecture. ### 🚧 Migration is not a single-step change Moving to OpenTelemetry almost always involves migration across multiple tools and platforms. A successful transition requires strategy, discipline, and clear governance. #### **Key considerations include:** **✅ Choose the right product through PoC**\ Different APM vendors have different strengths, so a PoC is key to validating the best real‑world fit.
**âś… Design and establish the OpenTelemetry infrastructure**\ This includes collector architecture, data pipelines, scalability, reliability, and integration with existing platforms.
**✅ Design and implement an effective sampling strategy**\ Without proper sampling, observability costs can grow uncontrollably—especially with SaaS-based APM licensing models.
**✅ Define a clear migration roadmap** This should include:\ Transition from server-based APM to OTel-based observability\ Migration of monitoring data from on‑premise solutions to SaaS platforms\ Clear success criteria at each phase ✅ Start with critical end‑to‑end paths\ Identify and migrate the most business‑critical user journeys first to maximize value and learning.\ ✅ Adopt OTel for critical and newly onboarded systems first\ New systems are often the easiest place to enforce OTel-native standards and best practices. #### ⚠️ A word of caution \ Some organizations attempt a “big bang” migration—moving everything to OpenTelemetry on day one. Very quickly, they discover that:\ Dashboards don’t yet provide expected insights (OTel ecosystems are still maturing)\ Observability costs spike due to missing or poorly designed sampling strategies\ They are forced to descope after realizing APM license costs exceed expectations ## 🎯 Key takeaway \ OpenTelemetry is a powerful foundation for modern observability—but success depends on careful product selection, strong architecture design, phased migration, and cost-aware governance. Done right, OTel enables true service-level visibility. Done too fast, it can become an expensive lesson.
## 🚀 Let's Connect Beyond GitBook! If you found this article helpful, you can find more of my technical insights, daily discussions, and deep dives across these platforms: * **Read more of my work:** Check out my articles on [dev.to](https://dev.to/stephen_tsoi_5b2c4055f3a9) and [Hashnode](https://stephentsoi.hashnode.dev/). * **Join the daily conversation:** Connect with me directly on [LinkedIn](https://www.linkedin.com/in/stephen-tsoi-16309730/). *** #### 📬 Stay Ahead of the Curve Enjoyed this piece? I break down complex technical topics into bite-sized, actionable insights every week. 👉 **Subscribe to my** [**LinkedIn Newsletter**](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7487299517642612736) to never miss an update and get the latest articles delivered straight to your feed! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://stephen-tsoi.gitbook.io/stephen-tsoi-docs/opentelemetry/from-missing-events-to-complete-visibility-tracing-enterprise-transactions-with-opentelemetry/day-34-34-migration-done-right.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.