How a team moves off AppDynamics agents to OpenTelemetry and SigNoz
The move off AppDynamics is a staged, service-by-service migration, not a single cutover. Teams usually start when a renewal is near, an on-premises Controller approaches end of maintenance, or data residency or lock-in becomes a concern. The safest sequence keeps AppDynamics agents running while OpenTelemetry traces are sent to both backends in parallel, so each service can be compared before its agent is removed. Platform engineers and APM owners usually own the work, with SREs validating alerts. An implementation partner such as DeployOpen can take on instrumentation, Collector configuration and SigNoz hardening if the internal team lacks capacity, with the scope agreed in writing first.
Begin with an inventory: list every application, the AppDynamics agent type and version it uses, its business transactions, health rules and the dashboards and alerts that depend on them. Then pick a low-risk, well-understood service as the pilot. Deploy the OpenTelemetry SDK or auto-instrumentation alongside the agent, and route telemetry through the OpenTelemetry Collector (otelcol-contrib) to SigNoz and, if still needed, to AppDynamics. Confirm which SDK languages you run are stable for traces using the OpenTelemetry status page, because log SDK maturity varies. Use the Collector's authenticator extensions and the configuration best practices to protect the ingest endpoints before they carry production data.
Effort and risk concentrate in three areas: rebuilding health rules as SigNoz alerts and dashboards, which is manual work with no automatic conversion; reproducing AppDynamics business transaction views, which needs an explicit definition of transaction boundaries in trace attributes; and parity testing during the overlap period. The overlap period, the number of services per wave and the staffing are decisions to make from your own inventory, not from a generic estimate. Ask any implementation partner for a written breakdown of instrumentation, alert rebuild, testing and handover, and confirm who operates SigNoz after go-live, since self-hosting shifts storage, scaling, upgrades and backups to your team.
Which AppDynamics capabilities map cleanly to SigNoz and which need rework
This table compares common AppDynamics capabilities with what SigNoz provides out of the box and what needs redesign. Read each row as a starting point, then confirm the AppDynamics features your teams actually use against your own environment and configuration. The main takeaway is that tracing, metrics, logs and dashboards map well, while business transactions, baseline-driven health rules and agent auto-discovery need deliberate rebuilding.
| Capability | SigNoz with OpenTelemetry | Migration effort |
|---|---|---|
| Application and service monitoring | APM and distributed tracing are listed among SigNoz features, fed by OpenTelemetry SDK traces | Maps cleanly once services emit OTLP traces |
| Distributed tracing | Traces ingested through the SigNoz OpenTelemetry Collector and stored in ClickHouse | Maps cleanly; confirm trace context propagation across your services |
| Infrastructure metrics | Infrastructure monitoring is a Community Edition feature; metrics arrive via OpenTelemetry or Collector receivers | Maps with configuration; confirm the host and container metrics you rely on |
| Logs | Log management is included in the Community Edition and collected through the same Collector pipeline | Maps with configuration; log SDK maturity varies by language |
| Dashboards | Built with the Query Builder, PromQL or ClickHouse SQL; existing AppDynamics dashboards must be rebuilt | Needs rework; plan to recreate each dashboard |
| Alerting | Alerting and Alertmanager-based notification are included; AppDynamics health rules must be rewritten as alert rules | Needs rework; baselines and health rule logic do not transfer directly |
| Business transactions | No direct equivalent is listed in the supplied SigNoz feature set; teams usually model them with span attributes and saved queries | Gap; design a custom approach and validate with stakeholders |
| Health rules built on baselines | Anomaly detection is not included in the Community Edition according to the SigNoz pricing page | Gap on the free edition; define static thresholds or evaluate paid tiers |
| Agent-based auto-discovery | OpenTelemetry instrumentation is explicit, so services must be instrumented individually | Gap; plan an inventory and instrumentation sequence |
| SSO and SAML | SSO is on every plan including Community; SAML requires the Teams or Enterprise plan | Confirm your identity provider requirements before choosing a plan |
How hybrid mode and the OpenTelemetry Collector send traces to both backends
During a parallel run, one instrumented service can feed both AppDynamics and SigNoz because the OpenTelemetry Collector can receive telemetry once and export it to more than one destination. The Collector can run as an agent next to each service or as a gateway that accepts data from many sources. For a migration, a gateway is often the simpler choice because it gives one place to add a second exporter, change routing and watch queue health while the agents keep sending. Before you commit to a design, confirm with AppDynamics documentation which hybrid mode your agent version supports and whether its data can be exported through the Collector. That answer decides whether the Collector only fans out OpenTelemetry data or also sits alongside the AppDynamics agent.
The Collector is licensed under Apache-2.0, so the routing layer you add during the migration carries no copyleft obligations. Each release ships the contrib distribution with signed artifacts, SHA256 checksums and SBOM files, alongside the Collector builder and OpAMP supervisor. Treat these as the acceptance checks for the gateway: verify the signature and checksum against the release you download, keep the SBOM with your change records, and pin the version in your deployment. If you build a custom distribution with the builder, include only the receivers, processors and exporters your pipelines use. Check each component's README for its stability level, because core components vary in maturity.
OpenTelemetry is not an observability backend, so on the new side the data is stored by SigNoz's own pipeline. SigNoz's OpenTelemetry Collector receives telemetry and writes it to ClickHouse, which means your team owns that storage, its retention and its capacity planning. Decide early who operates the gateway, where TLS terminates and which credentials each exporter uses. The Collector's authenticator extensions can check incoming connections with OIDC and add OAuth2 credentials to outgoing exporter requests through the oauth2client extension. Confirm both extensions and the target endpoint settings against the current configuration documentation before the first production pipeline goes live.
Migration sequence from inventory to decommission
This sequence moves AppDynamics workloads to OpenTelemetry and SigNoz one service at a time, keeping AppDynamics readable until each replacement has been checked. It is a planning model to adapt to your environment, and each step closes with a written output that the next step depends on.
Inventory agents, services and health rules
Platform owners list every AppDynamics agent in use (Java, .NET, Node.js, Python, machine agents and any database or browser agents), the application and tier each one reports from, the business transactions that matter to the business, and every health rule, alert and dashboard that pages someone or feeds a report. Assign an owner and a criticality rating to each service. The output is an inventory list that maps each service to its agent type, its health rules, its on-call owner and its dependencies. The step is done when the application owners have reviewed and signed off the list.
Pilot OpenTelemetry on one non-critical service
Choose one non-critical service with a clear owner and instrument it with OpenTelemetry SDKs and the OpenTelemetry Collector, exporting to a self-hosted SigNoz instance deployed in your own infrastructure. Keep the AppDynamics agent running on the same service so the two sets of data can be compared. Check that traces, metrics and logs arrive, that service names and resource attributes are consistent, and that the team can find the same slow requests in both tools. Record the gaps, such as business transaction naming, missing database or message queue spans, and data retention needs. The output is a pilot report with the decisions on instrumentation patterns and Collector configuration.
Run both backends in parallel
For each service in the next wave, run the OpenTelemetry pipeline and the AppDynamics agent together and send the same telemetry to both backends through the Collector, which can fan out to multiple exporters. Compare request latency, error rates, throughput and trace coverage across both tools over a period agreed with the service owner. Rebuild each health rule as a SigNoz alert and confirm that it fires on the same test conditions as the original. The output is a dual-run comparison per service that lists matching signals, differences and the owner's decision to proceed. Confirm the Collector's security settings, including authentication on receivers, before production traffic flows.
Rebuild dashboards and alert routing
Recreate the dashboards that operators and business owners rely on in SigNoz, using its Query Builder, PromQL or ClickHouse SQL depending on the query type. Route SigNoz alert notifications to the same on-call tool and escalation paths that AppDynamics used, and test each route with a controlled alert. Document which business transaction views have no direct equivalent, and agree with the business owners how those views will be approximated, such as with trace-based queries or service-level dashboards. The output is a dashboard and alert catalog with a test record for each notification route.
Cut over service by service
For each service that passed its dual run, the owner approves a cutover window, removes the AppDynamics agent from the deployment configuration, and confirms that the OpenTelemetry instrumentation remains the only telemetry source for that service. Watch the new alerts and dashboards through the first business cycle the service owner selects, and keep a documented rollback path to the agent configuration. Record the change, the approver, the rollback path and the first-week findings in a cutover record. Repeat for each service in criticality order, starting with the lowest-risk services.
Decommission agents and Controller access
When every service in the inventory has a signed cutover record, remove the AppDynamics agents from base images and build pipelines, revoke agent access keys and Controller user accounts, and export any historical reports or data the organization must keep under its records policy. Confirm with the security team how the Controller, its data and its backups will be retired under the organization's retention rules. The output is a decommission checklist with each item marked complete and signed by the platform owner, the security lead and the service owners.
What data and integrations move, and what has to be rebuilt
Telemetry from the cutover date forward moves through OpenTelemetry, while history, health rules, notification routing and access controls need deliberate work. Each card names a part of AppDynamics that does not carry over on its own and what to confirm in your own tenant before the cutover plan is set.
Historical AppDynamics data
Plan on not carrying over AppDynamics history as a live store. Telemetry sent to SigNoz starts at the point you begin dual-shipping, so incident baselines and year-over-year comparisons remain in AppDynamics. Ask your AppDynamics administrator which export and API paths your tenant exposes for metrics and events, and confirm the retention window for each. Decide how long the source tenant stays readable, and who approves exports into long-term storage. Treat exported files as records with their own retention rules.
Dashboards and health rules
AppDynamics health rules do not convert automatically. Inventory each rule, its threshold and the baseline it compares against, then rebuild it as a SigNoz alert or dashboard panel using the Query Builder, PromQL or ClickHouse SQL. Some baseline-driven rules will need a fixed threshold or an anomaly approach that you verify yourself, because SigNoz anomaly detection is not part of the Community Edition. Run the old and new rules side by side for a period before retiring the AppDynamics versions.
Notification channels and on-call routing
Alerts reach people through channels, and these must be recreated deliberately. Map each AppDynamics action, such as email, webhook or ticket creation, to a SigNoz notification channel, then confirm that Alertmanager handles grouping and deduplication the way your on-call rota expects. Test each route with a synthetic alert, and confirm who owns escalation when a channel fails. Keep AppDynamics notifications active during the overlap so a gap in routing does not go unnoticed.
SSO and SAML access
Single sign-on differs by plan. SigNoz lists SSO on every plan, including the Community Edition, but SAML is available only on the Teams and Enterprise plans. If your identity policy requires SAML federation, price the Teams or Enterprise plan or choose a different access model before cutover. Confirm current plan contents with SigNoz, and map existing AppDynamics roles to SigNoz roles so reviewers can verify who can view and change alerts.
Collector authenticator extensions
The OpenTelemetry Collector can authenticate incoming connections on receivers, for example with OIDC, and attach credentials to outgoing exporter requests, for example with the oauth2client extension. Use these to protect the gateway that receives telemetry from services, and to authenticate exports to SigNoz without storing static secrets in each service. Follow the configuration best practices, test token expiry during the parallel run, and confirm which extensions your Collector distribution includes.
Why business transaction views need a new approach
AppDynamics defines a business transaction through its own discovery and naming model: the agent detects entry points such as servlets, web requests or message consumers, and the Controller groups them into flows that operators name and tune in the UI. SigNoz has no equivalent object. It works from OpenTelemetry traces, which are trees of spans, each carrying attributes such as http.route, messaging.destination.name or a custom key your team sets. A business flow therefore exists in SigNoz only when your team decides which span attributes identify it, for example a checkout or payment-authorization path, and writes that decision down before anyone builds a view.
Plan that decision as a workshop with the application owners and the people who read the current AppDynamics dashboards. For each business transaction you intend to keep, list the entry span name, the attributes that separate it from similar traffic, and the attributes that must never be recorded because they carry personal or payment data. Then agree naming and attribute conventions across services before cutover, since a trace-based view built on inconsistent span names will silently miss traffic. Confirm these conventions against the OpenTelemetry semantic conventions your language SDKs follow, and check the instrumentation status for each language in your estate on the OpenTelemetry status page.
Once the attributes are fixed, rebuild each flow in SigNoz as a saved query, a dashboard panel or a trace-based alert. SigNoz dashboards can be built with its Query Builder, PromQL or ClickHouse SQL, so pick one query method per view type and document it, because a team that mixes all three will struggle to hand dashboards over. Expect the rebuilt views to show latency and error rates per flow rather than AppDynamics' baseline and automatic anomaly views, and confirm with the vendor which of those behaviors your SigNoz edition provides before you promise them to stakeholders.
What usually goes wrong and how to prevent it
Most failed AppDynamics migrations do not fail on the first day. They fail quietly when alerts go missing, telemetry drifts between the two backends, or a Collector is exposed without review. The cards below name each risk and the check that prevents it.
Alert coverage gaps after cutover
AppDynamics health rules fire on baselines and thresholds that teams rarely write down. When an agent is removed, its health rules can stop evaluating without any notice. Before cutover, export the list of health rules and policies for each application, map each one to a SigNoz alert or dashboard panel, and confirm that every alert has a named owner and a notification route. Test each rule by triggering it in a staging environment.
Duplicate or missing telemetry in parallel runs
Running AppDynamics agents and OpenTelemetry instrumentation side by side can double-count requests or leave gaps where one pipeline drops data. Compare request counts, error rates and latency percentiles between the two backends for the same service over the same window. Agree in advance on which backend is authoritative for each dashboard, and record the variance you accept before you turn off the old agent.
Inconsistent span naming across teams
When each team names spans and attributes differently, service maps, latency views and alerts become hard to query and easy to misread. One team may record an operation as a route template while another records the full URL with IDs in it. Publish a short naming and attribute convention based on OpenTelemetry semantic conventions, add it to the instrumentation checklist, and review a sample of spans from each service before it counts as migrated.
Sampling that hides rare errors
Head-based sampling set to keep a small fraction of traces can drop the rare failures that matter most to a regulated service. AppDynamics captured business transactions with its own rules, so teams often assume the same coverage carries over. Decide which error, latency and payment or authentication paths must be kept at full fidelity, configure tail-based sampling in the Collector for those paths if you need it, and check that known rare errors still appear in SigNoz after cutover.
Collector configuration without security review
A Collector that accepts OTLP from many services and exports to a backend is an attractive target and a common source of exposed endpoints. Teams often run default receivers on open ports without authentication or TLS. Before production, follow the Collector configuration best practices: restrict receiver endpoints, enable TLS, use authenticator extensions such as OIDC for incoming connections and oauth2client for outgoing exports, and keep configuration files under version control with a documented review.
Relying on community support for regulated operations
The SigNoz Community Edition includes APM, tracing, log management and alerting, but its support is community Slack only, and it does not include SAML, SOC 2 or HIPAA compliance. A regulated operation needs a named escalation path, tested backups, and a patch process with a defined owner. Ask SigNoz or a support partner which support tier covers your requirements before go-live, and document who responds to a production incident at night.
What drives cost and duration in this migration
This table lists the factors that set the effort of moving from AppDynamics agents to OpenTelemetry and SigNoz, with the reason each one matters and how to keep it under control. Read it before asking for a quote, since the same driver often appears twice: once as one-time migration work and again as recurring operations.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of services and agent types | Each Java, .NET, Node.js or other agent replaced needs its own instrumentation change, test and rollout, so effort grows with services and with the number of distinct runtimes. | Inventory every AppDynamics agent by service, runtime and owner first, then group services that share a framework so one OpenTelemetry pattern covers many of them. |
| OpenTelemetry SDK language coverage | Trace APIs and SDKs are stable in most languages, but log SDK maturity varies and some languages are still in development, so logs may need a different path for some services. | Check the OpenTelemetry status page for each language in use, and decide early whether logs stay in their current pipeline during the first phase. |
| Health rules and alerting | AppDynamics health rules have to be rebuilt as SigNoz alerts or dashboards, and each rule needs its threshold and notification route rechecked, which often reveals rules nobody uses. | Export the current rule list, retire unused rules before migration, and map the rest to a short set of alert types that Alertmanager routes consistently. |
| Dashboards and reporting | Every operations or executive dashboard is rebuilt in SigNoz Query Builder, PromQL or ClickHouse SQL, and the query language chosen affects how much rework each one needs. | Rank dashboards by actual use, rebuild only the ones teams still open, and agree on one query method per dashboard type so the team does not maintain three. |
| Business transaction complexity | AppDynamics business transactions group requests by rule, and rebuilding them as trace-based views or attributes usually needs custom span naming and attribute design per business flow. | Start with the few business flows that drive reporting or SLAs, define the span names and attributes for them in writing, and leave the long tail for later. |
| Collector pipeline design | Running the OpenTelemetry Collector in hybrid mode, as agent or gateway, means sampling, filtering, exporter and authentication settings must be written, tested and secured for both backends. | Standardize one reference Collector configuration, review it against the Collector security best practices, and reuse it across teams. |
| Infrastructure for SigNoz | Self-hosted SigNoz runs the OpenTelemetry Collector, ClickHouse storage, the API server and Alertmanager, so compute, storage and retention settings drive ongoing infrastructure cost. | Size ClickHouse storage from the expected ingest and retention, confirm the Helm or Docker deployment target with the SigNoz install documentation, and set retention per data type from the start. |
| Team skills and operations | Someone must own ClickHouse, Collector upgrades, backups and scaling after go-live, which SigNoz documents as the customer's responsibility in self-hosted enterprise support. | Name the operator before the pilot, train on the upgrade path, and ask the provider to document runbooks for upgrades and backups in the written scope. |
Cost components on the SigNoz side
Self-hosted SigNoz has no license fee for the Community Edition, which the SigNoz pricing page describes as free to self-host and includes APM and tracing, log management, infrastructure monitoring and alerting. The cost sits elsewhere: infrastructure to run the SigNoz components and ClickHouse, storage sized to your telemetry volume and retention, OpenTelemetry Collector capacity at the gateway and agent tiers, and the engineering time to operate the stack. Those costs recur every month, and the largest variable is usually how many spans, logs and metric samples you keep and for how long. Before you size anything, confirm with your own AppDynamics data what volume of traces and metrics the migrated services will produce, since AppDynamics agent telemetry does not map one to one onto OpenTelemetry signals.
Staff time is the cost most often missed in the first estimate. Someone must own SigNoz upgrades, ClickHouse backups and restore tests, Collector configuration changes, retention policies and the alert rules rebuilt from AppDynamics health rules. Ask who on your team holds those tasks, how many hours per month they expect them to take, and whether the work is covered by a retainer or by internal staff. Community support for the Community Edition is through Slack, so a production team should plan for its own on-call path for the stack itself.
The choice between the three SigNoz paths changes where those costs land. SigNoz Cloud's Teams plan starts at $49 a month including $49 of usage, with logs and traces at $0.30 per GB ingested and 15-day retention, according to the same pricing page, which shifts infrastructure and upgrade work to SigNoz but adds usage-based charges. SigNoz Enterprise starts at $4,000 a month and is offered as Cloud Dedicated, as BYOC in your cloud account, or self-hosted with enterprise support, where your team still runs infrastructure, storage, scaling, upgrades and backups. When you request a quote, ask SigNoz which of these components are included, how usage is metered, what retention is covered, and what support response is committed in writing.
How the migration differs by starting point
A small estate with a few instrumented services is the simplest starting point, because the team can move agents in one planned window and skip most coexistence work. In illustrative terms, a team with a handful of Java and Python services might add OpenTelemetry SDKs to each one, send them through a single Collector, and compare SigNoz traces with AppDynamics business transactions during a short overlap.
- Inventory first: List every AppDynamics agent, application and tier, then map each one to an OpenTelemetry SDK or auto-instrumentation for its language.
- Run one Collector: Use a single gateway Collector that exports to self-hosted SigNoz and, during overlap, to AppDynamics if your agreement and the exporter options allow it.
- Install SigNoz simply: Docker Standalone or Docker Swarm are documented self-hosting routes that often suit a small footprint, and Kubernetes with Helm is the other documented option.
- Rebuild alerts by hand: With few services, recreate each health rule as a SigNoz alert and dashboard, and test it against known AppDynamics behavior before cutover.
Confirm with your AppDynamics account team whether parallel export is permitted under your license, and confirm that your team can operate a ClickHouse-backed stack after cutover.
A large estate with many agent types, such as Java, .NET, Node.js, machine, database, web server and browser monitoring, needs a sequence by language and tier. Each agent type has its own coverage question, and OpenTelemetry maturity differs by signal and language. Trace APIs and SDKs are stable in most languages, but log SDK maturity varies, so some runtimes will need more validation than others.
- Sequence by language and tier: Start with languages whose trace SDKs are stable, such as Java, .NET, Go or Python, and defer runtimes where log or metric support is still maturing.
- Plan for agent types without a direct match: Machine, database and middleware agents need a separate coverage check, using OpenTelemetry receivers or other collection methods, before any AppDynamics agent is retired.
- Layer the Collector: Run agents next to services and gateways in front of SigNoz, and read each component's stability note in its README before using it in production.
- Size storage early: Trace volume from many services drives ClickHouse storage, retention and query load, and those are the main levers on ongoing infrastructure cost.
Before setting cutover dates, check each agent type against the OpenTelemetry status page and confirm sizing guidance with SigNoz for your expected volume.
An on-premises AppDynamics Controller that is nearing end of maintenance turns the migration into a timing decision. The safest pattern keeps the Controller on a supported release while the OpenTelemetry pipeline and SigNoz are built beside it, so the team is not forced to upgrade and migrate under the same pressure. The end of maintenance schedule depends on your release, so the first task is confirming that date in writing.
- Confirm the support window: Ask your AppDynamics account team which release you run, its end of maintenance date and whether any extended support option exists for your environment.
- Build beside the Controller: Deploy the Collector and SigNoz in the same infrastructure, so you do not duplicate planning, network access and monitoring work in two places.
- Reuse existing capacity: Check whether current Kubernetes or virtual machine capacity can host SigNoz through Helm or Docker, and whether the team has operated ClickHouse before.
- Retire agents in waves: After SigNoz covers the most important business services, move agents from the Controller to the Collector in waves, and keep the Controller available for historical comparison for the retention period you need.
Compare the upgrade path, the appliance path and the OpenTelemetry route on effort and recurring cost, and confirm each option with your vendor before committing budget.
A regulated environment that needs SAML, audit evidence or air-gapped and residency controls changes the design before any agent is moved. SigNoz lists SSO on every plan, including Community Edition, while SAML is available on its Teams and Enterprise plans. Self-hosting keeps telemetry inside your network, but the controls around access, backups, change records and evidence still fall to your team. Independent auditors issue any attestation, and DeployOpen prepares the systems and evidence for their review.
- Settle identity first: SAML is limited to Teams and Enterprise, so decide whether OIDC through the Collector authenticator extensions or SigNoz SSO meets your requirements, and confirm the options with SigNoz.
- Own the evidence: The Community Edition does not include SOC 2 or HIPAA compliance, so define the logs, access reviews, backup tests and change records that your auditors will ask for.
- Mirror for air-gapped networks: Confirm that SigNoz install artifacts and OpenTelemetry Collector images can be mirrored internally, and verify the signed artifacts, SHA256 checksums and SBOM files for each release.
- Weigh enterprise self-hosting: The self-hosted Enterprise option includes enterprise support, but your team still runs infrastructure, storage, upgrades and backups, so SigNoz pricing should be read alongside a written support scope.
Confirm the identity, evidence and mirroring requirements in writing before the architecture is approved, and ask your auditor which of them they expect to test.
Questions buyers ask before moving off AppDynamics
What drives the effort and cost of moving off AppDynamics?
The main driver is how many services, agents and custom instrumentation points you run, not the license line you are replacing. Each Java, .NET, Node.js or other agent you remove needs an OpenTelemetry SDK or auto-instrumentation path, a tested Collector pipeline, and new dashboards and alerts. Costs fall into one-time work (inventory, instrumentation, rule rebuilding, validation, cutover) and recurring work (running the SigNoz or Grafana stack, storage, upgrades, backups and on-call). Ask any quote to split those two groups and to state which applications and business transactions are in scope.
How long does an AppDynamics migration take?
The timeline depends on the number of applications, their language mix, how many business transaction views your teams rely on, and how much custom alerting you have. No fixed duration is supplied for this migration, so treat any single number with caution. A practical approach is to run a short inventory first, pilot one or two services end to end, then move the rest in waves. Ask for milestones in the written scope so each wave has an agreed exit condition before the next one starts.
What does the internal team need to provide during the move?
Your team needs to supply access to the applications, deployment pipelines and Kubernetes or VM environments, plus people who know the business transactions and the health rules that matter to the business. Someone must own the self-hosted SigNoz or Grafana stack after go-live, including upgrades, storage sizing and backups. Plan for security review of the Collector and the telemetry it carries, since traces can contain sensitive data. Confirm these responsibilities early, because they often decide whether the migration stays on schedule.
Can our own engineers do the migration without outside help?
Yes, many teams do it internally, especially with a small number of services and strong platform skills. The work is mostly familiar engineering: adding OpenTelemetry instrumentation, configuring the Collector, building dashboards and writing alert rules. The harder parts are rebuilding AppDynamics business transaction views with trace-based queries, validating that alerts fire as expected, and running the platform after handover. Assess your capacity honestly against your release calendar before deciding. DeployOpen can plan, implement and document the work under a fixed-scope agreement if that is the better fit.
Can AppDynamics and SigNoz run side by side during the migration?
Yes, in most setups. Because AppDynamics is a commercial APM that works with its own agents, and SigNoz receives OpenTelemetry data, the usual pattern is to keep the existing agents on services not yet migrated while adding OpenTelemetry to migrated services. Some teams also use the Collector to fan out telemetry to more than one backend during validation. Check with AppDynamics and your contract whether running both affects licensing or host counts, and confirm how your chosen agent mode handles duplicate instrumentation before you enable it.
What happens to historical AppDynamics data after cutover?
AppDynamics data does not move automatically into SigNoz. Its baselines, business transaction history and snapshots are stored in AppDynamics, so most teams keep read access to that data for an agreed period, then retire it. New history starts accumulating in SigNoz from the first day telemetry flows, with retention set by your configuration and storage. Decide early which dashboards and reports must keep historical comparison, and confirm the retention period and export options with your AppDynamics contract and your SigNoz deployment.
What does a fixed-scope DeployOpen engagement cover?
A fixed-scope engagement covers the work agreed in writing before it starts: the services in scope, the deliverables, and the timeline. For this migration that typically means planning the wave order, implementing OpenTelemetry instrumentation and the Collector pipeline, self-hosting SigNoz in your infrastructure, rebuilding agreed health rules as alerts and dashboards, hardening the deployment, documenting it, and handing over operations. Ongoing support, upgrades and testing are separate retainers. DeployOpen does not publish prices, so ask for a quote based on a written scope.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from AppDynamics to OpenTelemetry and SigNoz follows a written scope from the start. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we scope
- We inventory AppDynamics agents, business transactions, health rules and dashboards to decide what must be rebuilt.
- We agree in writing which services move first, which telemetry paths run in parallel, and what counts as done.
- We confirm the SigNoz edition, hosting target, storage sizing inputs and support model before any build starts.
How we build
- We deploy the OpenTelemetry Collector and SigNoz in your cloud account, data center or air-gapped network.
- We replace agents service by service, configuring the Collector to send traces to both AppDynamics and SigNoz during overlap.
- We rebuild health rules as SigNoz alerts and dashboards, then test each alert path against known failure conditions.
How we hand over
- We document the Collector configuration, instrumentation standards, alert definitions and dashboard ownership for your team.
- We run a handover session covering upgrades, backups and how to add a new service to the pipeline.
- We deliver a cutover record listing retired agents, decommissioned controllers and remaining gaps in business transaction coverage.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover SigNoz and Collector version upgrades, backups and periodic review of alert quality.
- Ask us to confirm in the written scope which support tier, response expectations and upgrade cadence apply to your environment.
