What end of maintenance on the AppDynamics Controller means for your APM platform
If your on-premises AppDynamics Controller runs release 25.7, plan around its end of maintenance date of October 31, 2026. The realistic choices are upgrading the Controller to a supported release, moving to the Kubernetes-based Virtual Appliance, or replacing the Controller with a self-hosted OpenTelemetry stack such as SigNoz. Each option can keep telemetry inside your own network, so the decision turns on effort, skills and the agents you have already deployed, not on where the data lives.
The Controller is not the only dependency. Java, .NET, Node.js and other agents running on your application hosts, the business transaction configuration that groups requests, the health rules that trigger alerts, and the dashboards and notification integrations built on them all need a plan. Upgrading the Controller can require agent upgrades, and replacing it means rebuilding those health rules as alerts and dashboards in a new tool. Inventory each of these before you pick a path, so the migration does not stall on configuration nobody documented.
End of maintenance dates follow a rolling schedule across releases, so confirm the exact date for your own version with Splunk before you choose. Ask Splunk in writing which support you keep after the date, whether the Virtual Appliance and your current agent versions are covered, and which release you should target. If the end date falls before your realistic change window, that timing should drive the decision, and a parallel run with OpenTelemetry can shorten the period in which you depend on the Controller.
What the constraint requires from your monitoring platform
Moving off an on-premises Controller is less about picking a tool and more about keeping the same controls you already answer for. The cards below list the requirements that follow from keeping telemetry in your own environment, and each one is a check to run against any open-source candidate before you commit.
Telemetry stays on your infrastructure
A self-hosted backend keeps traces, metrics and logs inside your own data center, cloud account or enclave, which is the reason many teams leave a hosted or vendor-run Controller. Confirm where every component writes data, including the Collector, the query store and any vendor telemetry or update endpoints. Check which exporters and integrations are enabled by default, because they can send data outside the boundary.
Platform stays on a supported release
The Controller constraint is a release calendar, so the replacement needs a published release and support path you can follow without a rushed rebuild. Record the version you deploy, the upgrade path and who approves each change. For SigNoz, for example, releases such as v0.146.0 are published on the project's GitHub releases page, so confirm which build your change board has accepted and how quickly patches reach you.
Software verifiable across isolated boundaries
Where a monitoring platform sits inside an isolated network, every package, image and update carried across the boundary needs a documented integrity check. NERC CIP-013-2 requires utilities to address verification of software integrity and authenticity in their supply chain procurement processes, so energy readers should map that control to their own change records. Ask whether releases ship with checksums and SBOM files, and whether you can verify signatures before import.
Access controlled by SSO and MFA
Operators, administrators and read-only viewers of the monitoring stack need the same identity controls as other production systems. Check which login methods the open-source edition supports, because some features such as SAML may only appear in paid tiers. Confirm that your identity provider can enforce multi-factor authentication for every console, API key and Collector authentication extension, and document who holds administrative roles.
Deployment works without internet access
If your environment is air-gapped, the monitoring platform, its container images, its Helm charts and its dashboards must install and update from internal mirrors. Kubernetes clusters can pre-pull control plane images and point the installer at a private registry, so confirm that the observability stack has the same path. Ask the vendor whether offline installation is included in the edition you plan to run, since several open-source projects reserve air-gapped support for paid tiers.
Your regulator's wording governs
The requirements above are a starting point, not a compliance determination. Ask your auditor or regulator how they expect telemetry retention, access logging, change control and supply chain evidence to be shown for the monitoring system. DeployOpen can prepare systems and evidence for that review, but the assessment itself is performed by your independent auditor or the authority that oversees you.
Which path fits your situation: stay supported, move to the Virtual Appliance or replace
This path fits a team that cannot change its platform this year and needs supported software for one more cycle. Maintenance ends per release line, so the first task is to confirm which line you run and when it stops receiving maintenance. Staying put keeps the same operating model, but your team still owns patching, backups and certificate renewal for the Controller.
- Current version: Confirm your exact release line and its end of maintenance date in Splunk's lifecycle documentation, since each line ends on its own schedule.
- Budget cycle: Check whether your support entitlement and renewal date match the period you plan to stay on this release.
- Staffing: Name who applies patches, rotates credentials and restores backups during the extra cycle.
- Agent coverage: Ask whether agent versions must move with the Controller, because a Controller upgrade can force agent upgrades across your fleet.
Before you commit to another cycle, get the end of maintenance date for your version in writing and ask whether any extended support option exists and what it costs.
This path fits a team that already runs Kubernetes well and wants the Controller on that platform rather than on individual virtual machines. The move changes how the Controller is deployed and operated, so the platform team must own the cluster, storage and upgrades that the appliance depends on. Do not assume the Virtual Appliance matches your current Controller feature for feature until Splunk confirms it.
- Cluster readiness: Confirm your Kubernetes version, storage classes, capacity for the Controller's databases and which team operates the cluster day to day.
- Air-gapped needs: If the cluster has no internet access, confirm how images are mirrored into a private registry before installation.
- Feature parity: Ask Splunk which Controller features, agent types and integrations the Virtual Appliance supports today and which it does not.
- Migration path: Ask whether the move can run side by side, what configuration and dashboards carry over and which agents need reconfiguration.
- Staffing: Confirm that Kubernetes and Controller skills exist in-house or through a contract before the move is scheduled.
Ask for written answers on parity and migration, then test the appliance with a production-like agent set before you set a cutover date.
This path fits a team that wants to leave on-premises APM agents behind and move instrumentation to OpenTelemetry, with a self-hosted backend such as SigNoz, or with Prometheus, Grafana and Jaeger. OpenTelemetry is vendor-neutral and is not a backend, so you still choose where traces, metrics and logs are stored and viewed. This is the largest change, and it affects every service that the agents cover today.
- Agent coverage: List every agent type and runtime in use, then check which language SDKs and instrumentation libraries you need, since trace SDKs are stable in most languages while log SDK maturity varies.
- Business transactions: Identify the business transaction views that leadership relies on, because those need a new design built on traces, attributes and dashboards.
- Parallel running: Send the same telemetry to both backends through the OpenTelemetry Collector during the transition.
- Operating model: A self-hosted backend means your team runs storage, upgrades and backups. The SigNoz self-host install docs describe Docker and Kubernetes options.
- Budget: Model the shift from a subscription to engineering time and infrastructure, and include the parallel running period.
Pilot two or three services in parallel, then confirm that the dashboards and alerts your teams depend on can be rebuilt before you retire any agent.
Upgrade, Virtual Appliance or self-hosted SigNoz and Grafana compared
This table compares the four main paths for a Controller nearing end of maintenance, including release 25.7 on October 31, 2026: upgrading, the Kubernetes-based Virtual Appliance, self-hosted SigNoz and a Grafana, Prometheus and Jaeger stack. Read each row against your agent count, compliance obligations and team skills. Only the open-source options remove the AppDynamics dependency, and both require business transaction views to be rebuilt.
| Option | How it meets the constraint | Trade-offs |
|---|---|---|
| Upgrade the Controller to a supported release | Keeps existing agents, health rules and dashboards largely unchanged, so the migration effort stays low in the short term. | Postpones the problem if the target release also nears end of maintenance. Confirm current end-of-maintenance dates with Splunk before choosing a version. |
| Kubernetes-based Virtual Appliance | Moves the Controller onto a Kubernetes deployment model in your own cluster while keeping AppDynamics agents and workflows. | Needs in-house Kubernetes skills and cluster capacity. Confirm supported Kubernetes versions, sizing and migration steps with Splunk. Remains a commercial product with its own licensing. |
| Self-hosted SigNoz (open core) | Community Edition is MIT outside the ee/ and cmd/enterprise/ directories and includes APM, tracing, logs and alerting, fed by OpenTelemetry instead of agents. | Community Edition has no SAML, SOC 2 or HIPAA compliance and offers community Slack support only. Business transaction views need a new approach. |
| Grafana, Prometheus and Jaeger stack | Prometheus (Apache-2.0) stores metrics, Jaeger (Apache-2.0) stores traces and Grafana (AGPL-3.0-only) provides dashboards and alerting. | Three components to run, upgrade and back up. Grafana and Mimir are AGPL-3.0-only, so review obligations with counsel. Business transaction views need custom work. |
| OpenTelemetry framework | A vendor-neutral standard that generates and exports traces, metrics and logs to any backend, so one data path can feed old and new tools during cutover. | Exports data to a backend but does not store or visualize it. Needs a backend such as SigNoz, Prometheus or Jaeger. Log SDK maturity varies by language. |
What changes when APM moves from AppDynamics agents to OpenTelemetry
The Controller holds more than data, and most of its configuration does not carry over automatically. Agent configuration, performance baselines, health rules and business transaction definitions live in the Controller, not in the telemetry itself. When an application is instrumented with OpenTelemetry, the traces, metrics and logs can flow to a self-hosted backend such as SigNoz, but the rules that decided what counted as slow, failing or important have to be rebuilt. Before cutover, export your health rule definitions, baseline thresholds and business transaction list from the Controller so the team has a written inventory to rebuild from.
Trace and metric data map across with the fewest changes. Health rules become alerts and dashboards in SigNoz or in a Prometheus and Grafana stack, and each alert needs an owner, a threshold and a notification route, which the Controller often handled implicitly. Business transaction views need a new design. In OpenTelemetry, a business transaction is usually modeled by grouping services and filtering spans on attributes such as an HTTP route, a tenant identifier or a payment type. Decide which attributes must be set by your instrumentation and which naming convention applies, because span attributes that are missing or inconsistent will break the views.
Plan around the support model before you commit. SigNoz Community Edition, which is free and self-hosted, does not include SAML and relies on community Slack for support. SigNoz Enterprise is offered as self-hosted with enterprise support, but your team still runs infrastructure, storage, scaling, upgrades and backups. Ask SigNoz which agent types and runtimes your applications use are covered, and confirm feature parity for each one with the vendor before you retire an agent. Use the SigNoz pricing page to check the current edition boundaries.
How to deploy a self-hosted SigNoz stack inside an isolated network
This sequence takes a team from choosing a SigNoz deployment target to retiring the on-premises Controller, with the Collector running beside it so telemetry is verified in both places before any cutover. The result is a self-hosted stack inside your own boundary, with the operating duties that stay with your team.
Confirm the target deployment platform
Platform engineering and the application owners choose between Docker Standalone, Docker Swarm and Kubernetes with Helm, as listed in SigNoz's self-host installation documentation. Kubernetes suits teams that already run clusters and want standard upgrade tooling, while Docker options fit smaller footprints. Record the choice, the host sizing for ClickHouse storage, and the network paths each service needs. Done when the architecture decision is signed off and the storage plan names who owns it.
Build the internal registry and stage images
The platform team creates a private container registry inside the isolated network and copies every image the chosen deployment needs, including SigNoz, the OpenTelemetry Collector, ClickHouse and Alertmanager. For Kubernetes, run kubeadm config images list to enumerate control plane images, pull them ahead of time, and point kubeadm init at the registry with the --image-repository flag. Verify each artifact against its published checksum and SBOM before import. Done when every image pulls from the internal registry with no outbound access.
Deploy SigNoz and the Collector gateway
Engineers deploy SigNoz with the chosen method, then run the OpenTelemetry Collector as a gateway that accepts telemetry from many services and writes it to ClickHouse through the SigNoz pipeline. Configure authenticator extensions such as OIDC on receivers so that only identified senders can deliver data. Confirm that the Collector's contrib distribution version is pinned and recorded. Done when a test service sends a trace and log that appear in the SigNoz interface.
Configure TLS and access control
Security engineers apply the Collector configuration best practices: encrypt receiver and exporter traffic with TLS, restrict listening addresses, limit which networks reach the gateway, and enable SSO and role assignments in SigNoz. Check the SSO and SAML options on your SigNoz edition, since SAML is listed only on the paid tiers. Store certificates and credentials in your secrets manager, not in configuration files. Done when a scan from outside the permitted segment fails to reach the ingest ports and an unauthorized sender is refused.
Run the Collector and Controller in parallel
Application teams add OpenTelemetry instrumentation to a pilot set of services while the AppDynamics agents keep reporting, so the same requests reach both backends. Compare trace counts, error rates and latency between the two views for the same transactions. Document every gap, such as business transaction naming or health rule behavior, in a tracking list owned by the platform team. Done when the pilot services show matching core signals in both systems for an agreed review period.
Rebuild alerts and dashboards in SigNoz
Operations and SRE staff recreate each important health rule as a SigNoz alert, routed through its Alertmanager to your on-call tooling. Build dashboards with the Query Builder, PromQL or ClickHouse SQL, depending on the team's skills. Test each alert with a controlled fault in a non-production environment and confirm the notification reaches the right responders. Done when every critical rule has an equivalent alert that has fired in a test and been acknowledged.
Cut over service by service and retire the Controller
Teams move each service to SigNoz as its dashboards and alerts are verified, and the owners sign off each cutover. Once all services report to SigNoz and a restore test of the Controller's backup has succeeded, the platform team decommissions the Controller and archives its data according to retention policy. Done when no production service depends on the Controller, the backup restore was verified, and the decommission is recorded.
Assign the ongoing operating duties
Your team keeps the duties that a self-hosted stack moves in-house: applying SigNoz and Collector upgrades from the pinned releases, running and testing backups, scaling ClickHouse storage as ingest grows, and staffing on-call for the stack itself. Community support is through Slack, so decide ahead of time whether you need a paid support arrangement. Ask any implementation partner to state these responsibilities in the written scope. Done when a named owner and an on-call rota exist for each duty.
Evidence assessors ask for when the Controller is replaced
When an on-premises AppDynamics Controller is replaced, assessors look for records that show where telemetry now flows, who can reach it, how software was verified, and what happened to the old data. The six items below connect the migration plan to evidence an auditor can sample. DeployOpen prepares this evidence, but auditors and certification bodies issue any opinion on it.
Agent and service inventory
List every AppDynamics agent and each service it observes, then map each one to its new telemetry path, such as an OpenTelemetry SDK sending to the Collector or a Collector receiver. Record the owner, the cutover date and whether the service runs in hybrid mode during overlap. Assessors use this inventory to test whether any monitored system lost visibility during the move. Confirm the inventory against the live environment rather than the original design document.
Collector and SigNoz release records
Keep a record of each deployed OpenTelemetry Collector and SigNoz version, with the artifact checksums and SBOM files that were verified before installation. Collector releases ship contrib builds with signed artifacts, SHA256 checksums and SBOMs, so the verification step can be written down and repeated. Store the record with the change ticket that approved each upgrade. Assessors often ask how a team knows the binary running in production is the one that was published.
Telemetry access and SSO records
Document who can query traces, metrics and logs, which roles they hold, and how sign-in is enforced. SigNoz lists SSO on every plan, including Community, but SAML is available only on its Teams and Enterprise plans, so the identity design depends on the edition chosen. Confirm whether MFA is enforced at the identity provider and whether it covers the SigNoz login path. Review access on a schedule and keep the review results.
ClickHouse backup and restore tests
SigNoz stores telemetry in ClickHouse, so backups of that database are part of the recovery story. Keep dated restore test results that show a backup was taken, restored to a separate environment and queried successfully. Record the recovery point achieved and the time it took, measured in your own environment. An unrestored backup is weak evidence, so the restore test is the item assessors tend to ask for first.
Controller decommission and retention decision
Record the date the on-premises Controller was shut down, who approved it, and what happened to its data. Decide how long historical AppDynamics data is kept, where it is stored and who can read it, then write that decision down with its legal or policy basis. Confirm the Controller's end of maintenance date with Splunk for your version before setting the decommission date. Keep the export or archive hash so the retained data can be shown intact later.
Alert rule change records
Keep a change record for each alert that moved from an AppDynamics health rule to a SigNoz or Grafana alert, including the old rule, the new query, the threshold, the notification target and the approver. Note any alert that was retired rather than rebuilt, and why. Assessors use these records to confirm that alerting coverage did not shrink during the migration. Test each rebuilt alert with a controlled event and keep the result.
Questions teams ask before moving off an on-premises AppDynamics Controller
What drives the cost of replacing an on-premises AppDynamics Controller?
The main cost drivers are the number of applications and agents to re-instrument, the volume of telemetry the new backend must store, and the number of dashboards, health rules and alerts to rebuild. Costs split into one-time work (instrumentation, migration, rebuilding views and alerts, testing) and recurring work (infrastructure, storage, upgrades, backups and the staff who operate the stack). The SigNoz Community Edition is free to self-host, so your main costs are infrastructure, ClickHouse storage and operating time. The SigNoz pricing page lists SigNoz Enterprise starting at $4,000 a month for a self-hosted option with enterprise support, where your team still runs infrastructure, storage, scaling, upgrades and backups. Ask for a quote that separates one-time and recurring costs and states who is paid for each item.
How long does it take to move off an AppDynamics Controller?
No duration is published here, so ask for a written scope before accepting any timeline. Time depends on how many applications and agents are in scope, how much custom instrumentation exists, how many health rules and business transaction views need a new approach, and how long you want both systems running in parallel before cutover. Confirm the end of maintenance date for your own Controller version with the vendor, because the page lists 25.7 as ending October 31, 2026, and other versions follow a rolling schedule. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ask for the phases, the exit criteria for each phase, and what is excluded.
What does our internal team need to contribute to the migration?
Your team supplies the knowledge that no outside party can reconstruct from the Controller alone. In practice, that means:
- Owners for each application who can confirm which services matter, their dependencies and acceptable alert thresholds.
- Platform staff who can provide the Kubernetes or container hosting, network paths, storage, certificates and access controls that the new stack needs.
- Someone who owns the decision to retire each health rule, dashboard and report, and who signs off on what replaces it.
Security and compliance staff should review data retention, access and audit requirements before the new stack receives production telemetry. Name these owners in the written scope so that approvals do not stall the schedule.
Can our team replace the Controller without outside help?
A capable team can do it in-house if it already has experience with OpenTelemetry instrumentation, Kubernetes or Docker, and operating a column-oriented database such as ClickHouse. The gaps usually appear in business transaction views, which have no direct equivalent in OpenTelemetry traces, and in rebuilding health rules as alerts and dashboards. Support also changes: the SigNoz Community Edition support is community Slack only, so there is no vendor on call for production incidents unless you buy a support tier. Before deciding, count the engineering hours your team can commit for several months, not only the build period. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure, so you can choose between doing it internally, buying a fixed-scope engagement, or a mix of both.
Does the Kubernetes-based Virtual Appliance remove the need to change anything?
Moving to the Kubernetes-based Virtual Appliance changes the hosting model and the upgrade procedure, so it is unlikely to remove all change work. Confirm with the vendor which Controller versions and agent versions it supports, what data can be carried over, and whether your current agent configuration works without changes. Also check the parts outside the product: cluster capacity, storage classes, load balancers, certificates, single sign-on, backup jobs, and any integrations that read data from the Controller API. Ask for a written compatibility statement for your versions, a rollback plan, and a list of components your team must operate after cutover. If the appliance keeps you on the same product, the cost and operating model may change less, but the effort to verify your environment still applies.
Does SigNoz Community Edition meet our support and SSO needs?
SigNoz lists SSO on every plan, including the Community Edition, but SAML is available only on the Teams and Enterprise plans. The Community Edition does not include SAML, SOC 2 or HIPAA compliance, anomaly detection or prebuilt integrations, and its support is community Slack only, according to the SigNoz pricing page. If your identity policy requires SAML, or your compliance program needs documented support response, the Teams or Enterprise tiers are the relevant options to price. Confirm the current feature list and support terms on the SigNoz pricing page before writing requirements. Then ask for a quote that names each tier, the support level, and which features your identity and compliance controls depend on.
Can the replacement stack run in an air-gapped network?
Kubernetes clusters can be built without internet access by pulling control plane images in advance and pointing the installer at a private registry. The OpenTelemetry Collector releases ship signed artifacts, SHA256 checksums and SBOM files, which helps you verify each package before it crosses an isolated boundary. You still need to confirm with SigNoz whether its Community Edition and Helm charts can be installed and updated fully offline, because air-gapped support is often a paid-edition feature among open-source vendors. Ask for the list of images, charts and dependencies, the update procedure for each release, and how security patches reach an isolated network. Your security team should own the process for verifying each package before it is installed.
How DeployOpen plans and runs a Controller replacement under your constraint
DeployOpen plans and implements self-hosted open-source monitoring inside your own infrastructure, whether that means a supported upgrade path, a move off the on-premises Controller, or a parallel OpenTelemetry stack. Each engagement starts with a written scope that fits your change windows, data residency rules and the applications still reporting to the Controller.
How we scope
- We confirm which AppDynamics Controller version and end of maintenance date applies to your environment before choosing a path.
- The written scope lists applications, agents, dashboards, health rules and alerts that must move or be rebuilt.
- We agree deployment targets, including your cloud accounts, data centers or air-gapped networks, before any work starts.
How we build
- We deploy the chosen platform in your environment, using OpenTelemetry Collectors to receive telemetry from both old and new agents.
- Each in-scope service is instrumented and checked so traces, metrics and logs reach the new backend as documented.
- We configure authentication, network access and backups as defined in the scope, then test alerting and dashboards against agreed cases.
How we hand over
- You receive configuration, runbooks and a list of which AppDynamics features were replaced, partly replaced or not covered.
- We document dashboards, alert rules and business transaction views that need a new approach, so your team can review them.
- Handover includes a walkthrough with the staff who will operate the platform, with evidence gathered for your own compliance assessment.
How we support
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing of the monitoring platform are available as a retainer.
- Confirm with us which support boundaries apply after handover, and ask for a written quote based on your scope.
