Why plugin compatibility decides how long a Grafana upgrade takes
If your shared, self-hosted Grafana has installed panels and data sources that must move to a new major version, audit every plugin before the upgrade, not after it. The plugin inventory determines how much of the upgrade is routine and how much becomes a rebuild of dashboards that stop rendering. Each installed panel, data source and app plugin should be listed with its version, its source (official Grafana Labs, a third-party publisher or a private build), and whether it depends on Angular, which is the framework the Grafana team has been retiring. Angular support removal was planned for Grafana 12, and the angular_support_enabled setting was part of that retirement, so an Angular plugin that loaded on your current version may not load on the target.
A new Grafana version can stop older plugins from working properly because plugins call into the host application's frontend and backend APIs, and those APIs change between releases. The Grafana 11.0 upgrade guide therefore recommends updating plugins after the Grafana upgrade, not only before it. That advice means your plan needs two checks: a pre-upgrade audit to find plugins that need a newer version or a replacement, and a post-upgrade pass to confirm that the updated plugins load. Ask each plugin publisher, in writing, whether a release supports your target version. Where a publisher has not confirmed support, treat that plugin as a blocker for scheduling, not as a detail to resolve on upgrade day.
The supported path matters as much as the audit. Grafana's upgrade guidance describes major releases once a year, minor releases every other month, and patch releases at least monthly, with each minor release supported for 9 months. Staying on a supported minor within your current major gives you plugin vendors more time to ship compatible builds, and it lets you move in smaller steps when a plugin changes behavior. Check Grafana's upgrade guidance against your current version before choosing a target, and confirm with your plugin owners which minor release they test against.
Which plugin changes in each Grafana release affect your audit
This table maps three plugin-related changes to what they mean for your installed panels and data sources, and what to do about each. Read it as a checklist: each row is a trigger that should produce a line item in your audit. The main takeaway is that Angular plugins are the hard blocker, while the other two rows call for verification after every upgrade.
| Change | Impact | Action needed |
|---|---|---|
| Angular plugin support removal (planned for Grafana 12) | Angular panels and data sources stop loading once support is removed. The angular_support_enabled setting that once re-enabled them is also removed in that release. | List every Angular plugin in use, confirm each has a modern replacement or an updated version, and plan removal before moving to Grafana 12. |
| Plugins that stop working properly after a new Grafana version | The Grafana 11.0 upgrade guide notes that older plugins can fail after a Grafana upgrade even when they still install. | Update each plugin after the Grafana upgrade and test every dashboard that uses it. |
| grafana cli plugins ls | Lists installed plugins and their versions, giving you a baseline inventory before and after the upgrade. | Run it on every instance and save the output with your change record. |
| grafana cli plugins update-all | Updates all installed plugins in one step, which can move plugins to versions that need the new Grafana release. | Confirm the target Grafana version first, then update, then retest. Review the release notes of each plugin. |
| Later Grafana releases | Plugin requirements, removed settings and CLI behavior can change in releases after those covered here. | Check the upgrade guide and release notes for your exact target version and confirm each item with the plugin maintainer. |
What to inventory and back up before touching plugins
Plugin compatibility problems are easiest to fix when you know exactly what is installed, where each piece is used and how to get back to a working state. These cards cover the inventory, the backup and the test run that together form the baseline for every later step.
Full plugin list with versions and sources
Record every installed plugin with its exact version, its source (Grafana catalog, a GitHub release, a private build or a copied directory) and whether it is signed. Run grafana cli plugins ls on each node, because a plugin installed on one server in a cluster is easy to miss. Without this list you cannot tell which updates are available or which plugin is the source of a broken panel.
Dashboard and panel type usage
Export or query dashboards to find every panel type in use, including panels that came from Angular plugins and panels that depend on a third-party visualization. Count the dashboards that use each panel type so you can see which teams are affected before the upgrade. Dashboards stored in folders you do not own are the ones most often missed.
Data sources and their plugin types
List every data source with its type, plugin ID and whether it is a built-in or external plugin. Note which dashboards and alert rules reference each data source, since a plugin that stops loading breaks those references as well as the data source itself. Confirm with each data source's owner that the connection still works on the target version.
Database and plugin directory backup
Take a backup of the Grafana database (SQLite, MySQL or PostgreSQL) together with the plugin directory and configuration files. Test that the backup can be restored on a separate host before you rely on it. Store the backup outside the instance being upgraded so a failed plugin update does not remove your rollback path.
Non-production test instance on the target version
Build a staging instance on the target Grafana version, restore the inventory and a copy of the database into it, and run the plugin updates there first. Check each dashboard and panel type from your inventory and record any that fail to load. Use the results to decide the production change window and which plugins need replacing first.
Named owner for each plugin
Assign one person or team to every plugin, with the owner responsible for approving updates, testing dependent dashboards and deciding on replacement. Plugins without an owner tend to stay on old versions, and abandoned community plugins are often the ones that stop working first. Record the owner in the inventory so the list stays current after the upgrade.
How to handle an Angular plugin that will not load
The first option is to move the plugin to a version built on React. This keeps the panel working on the new Grafana release and preserves the dashboards that depend on it. It is usually the lowest-change path when the author still maintains the project and publishes a release that supports your target Grafana version.
- Trade-off: Dashboard JSON and panel options often carry over, but a newer version may rename options or change defaults, so panels can look different after the update.
- What to test: Open every dashboard that uses the panel, then check thresholds, field overrides, data links and template variables against a baseline captured before the upgrade.
- Version match: Confirm which Grafana versions each plugin release supports, and record the exact plugin version you will install for the target release.
- Dependencies: Ask whether the new version needs a different data source plugin version, extra configuration or changes to how the plugin is installed.
Before you commit, ask the author for a written statement of the Grafana versions the update supports, and keep the test results with the change record.
The second option is to replace the plugin with a maintained alternative. The alternative can be a panel that ships with Grafana or another plugin from a maintainer you can verify. This removes dependency on an unmaintained project, but it means rebuilding panels, and the new visualization may not match the old one exactly.
- Trade-off: Core panels are maintained alongside Grafana, but they may lack some options the old panel offered, so a few visualizations may need a different layout.
- What to test: Build the replacement on a copy of each dashboard, run the same queries, and compare units, decimals, time zones and handling of empty values.
- Licensing and support: Check the license, recent maintenance activity and the security reporting path for any third-party alternative before you adopt it.
- Mapping record: List each old panel with its replacement, the owner who approved it and any alert rules that reference the panel, so nothing is missed at cutover.
- Deployment: Add the replacement to your provisioning or deployment configuration so the change is recorded and repeatable.
Ask the original author whether they plan to maintain the plugin, and ask the replacement's maintainers what their support commitment covers.
The third option is to keep the Angular plugin running for a short period, using the angular_support_enabled setting, but only if your target Grafana version still accepts it. The Grafana Angular deprecation documentation planned complete removal of Angular support for Grafana 12, including this setting, so the option may not exist on the release you are moving to. Use it as a short bridge to a supported state, not as a long-term plan.
- Availability: Confirm in the release notes for your exact target version whether
angular_support_enabledis still honored before you rely on it. - Security exposure: Ask the plugin author whether security fixes will be released for the Angular code path, since it is outside the supported direction of Grafana itself.
- Scope: Limit the exception to named plugins and named dashboards, with a written owner and an approval record.
- What to test: After a restart, confirm that each affected panel renders, that dashboards load for each user group and that the server logs show no plugin load errors.
- Exit plan: Set a removal date tied to either the React upgrade or the replacement, and track it in your change system.
Get a written release date from the author or vendor for a supported version, and do not start the next Grafana upgrade until this exception has a named owner and an end date.
How to run the plugin audit and update sequence
The sequence turns an unknown plugin estate into a tested upgrade decision. It produces a plugin inventory, a list of plugins to replace or retire, a staging result for the target version, and a rollback point the team can restore if production breaks.
Export the plugin inventory from the running instance
Run
grafana cli plugins lson the current production instance and save the output with the Grafana version, the host name and the date. Include plugins installed in the plugins directory and any deployed through provisioning or a container image, because the CLI only sees what is on disk. Done when the team has one file listing every plugin ID and installed version, and the owner of each plugin has confirmed that the list is complete.Classify each plugin by source and support status
Sort every entry into core (bundled with Grafana), Grafana Labs, third party or Angular-based. Check each plugin's documentation or repository to see whether it still ships a release for the target Grafana version and whether it is maintained. Record the owner, the dashboards and alert rules that depend on it, and the decision for each: keep, update, replace or retire. Done when every plugin has a classification and a decision, and any Angular plugin is flagged for a replacement plan.
Build a staging instance at the current version
Restore a recent copy of the production database and the provisioning and plugin files to a separate staging host that matches production's install method, network path and data sources. Confirm that staging loads the same dashboards and data sources as production before any upgrade. Done when a side-by-side comparison of the staging and production dashboard lists and data source lists shows no differences.
Upgrade staging and test panels and data sources
Upgrade the staging instance to the target Grafana version and open each dashboard that uses a flagged plugin, along with a sample of dashboards that use each data source. Look for panels that fail to render, data sources that return errors, and plugins that Grafana refuses to load because of an Angular or compatibility problem. Record each failure with the dashboard UID and the plugin ID. Done when every failure is either fixed, assigned to a plugin replacement, or accepted in writing by the dashboard owner.
Create and verify the rollback point
Before touching production, take a backup of the Grafana database (SQLite
grafana.db, or the MySQL or PostgreSQL database), the configuration files and the plugin directory. Store the copy outside the host being upgraded and confirm that it can be restored on a test host. Done when the team has a restore test on record and knows the exact steps and owner for a rollback. Check the separate rollback guidance before starting, since downgrades carry their own risks.Upgrade production and run plugin updates
Install the target Grafana version on production during the agreed change window and start the service. Then run
grafana cli plugins update-allto bring installed plugins to versions that match the new release, and restart Grafana if the plugin change requires it. The Grafana upgrade guide recommends updating plugins after the upgrade because older plugins can stop working properly on a new version. Done whengrafana cli plugins lsshows the expected versions and Grafana starts without plugin errors in its logs.Verify dashboards and alerts, then decide
Walk the list of critical dashboards from the staging test, confirm panels render and queries return data, and confirm that alert rules evaluate and that notification contact points are reachable. Compare results with the baseline recorded before the upgrade. The team proceeds when every critical dashboard and alert matches the baseline or has an accepted exception. The team stops and restores from the rollback point when any critical dashboard, data source or alert path fails and no fix can be made within the change window.
When to replace an abandoned community plugin
Replace a community plugin when you cannot show it will work on the target Grafana version. Start by checking its source repository: look at the date and frequency of its latest releases, whether issues and pull requests are being answered, and whether the maintainer has published a compatibility statement for the version you plan to run. Then ask whether the panel or data source is now covered by built-in options or by a plugin from Grafana Labs. Confirm the current list of supported plugins in the Grafana documentation and in the plugin catalog for your version, because coverage changes between releases. A plugin with no recent release, no statement for the target version and a built-in replacement is a strong candidate for retirement.
Keeping an unmaintained plugin is not free. You carry the risk that a future Grafana release breaks it without a fix, that a security issue goes unpatched, and that the person who understands its configuration leaves. The cost of replacing it is different in kind: someone must choose the substitute, rebuild the configuration, and migrate queries or options into it. Ask your implementation partner or internal team to estimate that work per plugin in writing, and to name who is responsible for each part. The cost of keeping a plugin usually shows up later, when an upgrade fails, so compare the two options against the next planned upgrade rather than against today's stable setup.
Replacement changes what users see, so treat every affected panel or data source as a change to retest. Export the dashboards that use the old plugin, list each panel with its query, variables, thresholds, links and transformations, and confirm that the replacement produces the same results for a set of known time ranges. Check alert rules that read from the same data source, since a changed query can silently change alert behavior. Record the before and after results and keep the original dashboard JSON so you can roll back. Only retire the old plugin after the replacement has passed this check in a non-production instance.
What makes a plugin audit take longer
This table lists the factors that stretch a pre-upgrade plugin audit and what each one changes in effort. Read each row against your own estate: the larger and less documented the plugin footprint, the more time the audit needs before any upgrade date is set. Confirm the items in the last column early, because they decide how much of the audit can be done by inventory and how much needs hands-on testing.
| Driver | Effect on effort | What to confirm |
|---|---|---|
| Dashboards and panels using third-party plugins | Each plugin-backed panel must be opened, rendered and checked, so effort grows with the count of affected dashboards | Export a list of dashboards and the panel plugin types each one uses |
| Angular plugins still installed | Angular-based panels and data sources stop loading in newer releases, so each one needs a replacement, an update or a retirement decision | Which installed plugins declare Angular support and which dashboards depend on them |
| Custom or internal plugins | Internal plugins may need source changes and a rebuild against the new Grafana version, which is often the longest item | Who owns each internal plugin, its source location and whether a maintainer is still available |
| Number of data sources and their authentication | Each data source needs a connection test, and credential or auth changes add rework and coordination with other teams | Count of data sources, their plugin types and which use stored secrets or token-based access |
| Team ownership of dashboards | Unowned dashboards need someone to decide whether to fix, retire or keep them, and decisions can stall the audit | Named owner for each dashboard folder and a contact for sign-off |
| Existence of a test environment | Without a staging copy, plugin checks run against production and fixes wait for change windows | Whether a restorable copy of the Grafana database and plugin directory is available for trial upgrades |
Questions teams ask before a plugin compatibility audit
How much does a Grafana plugin compatibility audit cost?
The cost depends on how many data sources, panels and dashboards your instance carries, how many of those plugins are community-maintained, and how much remediation you want included. The audit itself is inventory and testing work, while fixes such as replacing an abandoned plugin or rewriting a panel are separate effort. No supplied figure sets a price, so ask for a written scope that lists the instances covered, the plugins to inventory, the test environment, and whether remediation is priced separately. DeployOpen does not publish a price list, and a quote follows from that written scope. Expect the one-time audit to be distinct from any recurring support or retainer you choose later.
How long does a plugin audit take?
Duration scales with the number of installed plugins, the number of dashboards that depend on them, and whether a staging copy of your instance exists for test upgrades. A small instance with a handful of plugins is faster to review than a shared instance with many teams and custom panels. Time also depends on how quickly your owners can confirm which dashboards matter and who approves replacements. No supplied duration applies to your environment, so ask the partner to state the expected duration in the written scope and list the dependencies on your side, such as access to a staging server and named reviewers.
What does the audit need from our team?
You will need someone who can give the audit read access to the Grafana server or its configuration, the plugin directory, and the database that stores dashboards and data source definitions. You also need owners for each dashboard or data source who can say whether a panel is still used and which alerts depend on it. A staging instance on the target Grafana version is valuable because it lets the team test plugin loading before production changes. Ask the partner to list these inputs, the access they need, and the sign-off points in the scope before work begins.
Can our own staff run a plugin audit without a partner?
Yes, a team with Grafana administration experience can inventory plugins with the Grafana CLI, check the Grafana upgrade guidance, and test panels in staging. The CLI command grafana cli plugins ls lists installed plugins, which is a practical starting point. The harder work is judging each finding: deciding whether an abandoned community plugin has a supported replacement, and whether a dashboard owner still needs it. Teams that lack a staging copy, have many shared dashboards, or run alerts on plugin-backed panels often choose a partner for the inventory and test plan while keeping the approvals in-house.
How do I tell whether a Grafana plugin is an Angular plugin?
Start with the plugin's own documentation and metadata, then confirm by testing it on a staging instance running the target version. Grafana's Angular deprecation documentation explains that complete removal of Angular plugin support was planned for Grafana 12, including the angular_support_enabled setting, so any plugin still relying on that path needs attention before the upgrade. Check the plugin's plugin.json and its release notes, then load each dashboard that uses it and watch for panels that fail to render. Record every result, because a plugin can load on one dashboard and fail on another depending on which panel options are set.
Should we update plugins before or after the Grafana upgrade?
The Grafana 11.0 upgrade guide recommends updating plugins after upgrading Grafana, because a new Grafana version can make older plugins stop working properly. In practice, the audit should identify plugins that are already broken or abandoned before the upgrade, and the update pass should follow the Grafana upgrade on staging and then production. Use grafana cli plugins update-all to update every installed plugin, and check grafana cli plugins ls afterward to confirm the versions. Plan a retest of each dashboard after both steps, because an update can change panel options that dashboards depend on.
What does a rollback look like if a plugin fails after the upgrade?
A rollback is only clean if you took a backup of the Grafana database, configuration and plugin directory before the upgrade. If a plugin fails, the first step is usually to reinstall the previous plugin version or disable the affected panel while you fix the dashboard. Rolling back Grafana itself is riskier because a database migration may not reverse cleanly, so the rollback plan should be written before the upgrade starts. Ask the partner to include the backup and restore steps, the test cases for each plugin, and the person who approves a rollback in the written scope.
What to confirm with each plugin vendor before upgrading
For every plugin on the inventory, the first question to put to the author or vendor is which Grafana versions the current release supports, and whether that support is written down for the target version rather than implied by an older compatibility note. Ask directly whether the plugin is built on React or still depends on Angular, because an Angular plugin that has not been ported will not run once Angular support is removed. Ask for the date of the last release, how often they publish, and whether they commit to updates within a stated window after a new Grafana major version. A plugin with no release in a long period, or with an open issue about the target version that has no owner, goes on the replacement list. Record each answer in the audit with the date you received it, since vendor statements change between the audit and the upgrade window.
License terms belong in the same review. Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, according to the Grafana Labs licensing page, and that page also notes that plugins, SDKs and agent software kept other licenses. A plugin can carry a license that differs from the core server, so do not assume the AGPLv3 obligations or permissions apply to it. For each plugin, confirm the license name from the plugin's own repository or metadata, whether the license permits your internal use and modification, and whether any commercial or enterprise tier of the plugin adds terms you have not accepted. Legal or procurement should sign off on this list before the upgrade is scheduled, because a license problem discovered after a replacement is chosen can reopen the decision.
Finally, ask each vendor for written confirmation of what they will support during your upgrade window, including a point of contact if a release breaks on the target version. Ask whether they test against the Grafana minor releases you will run, not only the major release, and how they report known incompatibilities. Keep the answers in the same register as your scope document so they can be attached to the change record. If a vendor cannot answer in writing, treat the plugin as unverified and plan either a test upgrade in a non-production instance or a replacement, and state that decision in the audit so the upgrade owner knows which plugins still carry risk.
How DeployOpen scopes and delivers a Grafana plugin audit
DeployOpen approaches plugin compatibility as a written, fixed-scope piece of work on your own Grafana instance. We inventory what is installed, test panels and data sources against the target version in a non-production copy, and hand over a dated list of what to update, replace or remove before the upgrade window.
How we scope
- Agree in writing which Grafana instances, versions and installation methods the audit covers.
- Confirm the target Grafana version and which dashboards, folders and teams are in scope.
- List every installed plugin, its source, and the data sources and panels that depend on it.
How we build
- Run the audit against a restored copy of your configuration and plugin set, not production.
- Flag Angular panels and data sources, and check each plugin for a supported release on the target version.
- Test dashboards that use replacement candidates and record which queries or variables need rework.
How we hand over
- Deliver an inventory with plugin versions, owners, compatibility status and recommended action for each item.
- Document the update order, the commands used to list and update plugins, and the rollback point to take first.
- Walk your platform and dashboard owners through the findings so the upgrade plan reflects their priorities.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after the audit.
- Confirm with us during scoping how plugin changes after the audit will be re-checked against later Grafana releases.
