Grafana Angular plugin migration services

Replacing Angular panels and data sources in Grafana: what the move involves

Most built-in Graph and Table-old panels have documented automatic migrations, so dashboards that use only those panels are usually a review and test exercise. The bulk of the effort sits elsewhere: third-party Angular plugins and dashboards with custom scripting. No automatic path covers these, so each one needs an owner, a replacement or update decision, and a test against the data it reads. Treat the move as an inventory and test project first and a conversion project second.

Start by listing every dashboard that uses an Angular-era panel, every installed plugin, and every data source those dashboards query. Record which plugins are still maintained, which have a newer React-based version, and which have no successor at all. Look for dashboards that rely on custom scripting, hand-edited panel JSON or plugin-specific options, since automatic migrations will not carry those settings across. Keep the inventory in version control so the list stays current as teams add or retire dashboards during the transition.

Effort depends mostly on how many dashboards and third-party plugins are in use, and on how many teams own them. Confirm the Angular support end date for your target Grafana version in the Grafana upgrade guidance and in the release notes before you set a plan. Test migrated dashboards in a copy of the instance that has the same plugins, data sources and permissions as production. When you ask a partner for a quote, provide the inventory so the scope, deliverables and testing are agreed in writing.

Which Angular panels and data sources map to current Grafana

This table compares common Angular panels and data sources with their current Grafana equivalents and the migration work each one needs. Read each row as a starting point, then confirm the mapping against the Grafana release notes for your target version, since visual output can shift after migration.

Angular item	Current equivalent	Migration notes
Graph panel	Time series or bar chart panel	Automatic migration converts most Graph settings. Check axes, legends, stacking, thresholds and series overrides, since these often render differently.
Table-old panel	Table panel	Automatic migration maps column styles and formatting to the current table. Review cell display modes, column order and sorting after conversion.
Built-in data sources (for example Prometheus, Loki, MySQL, PostgreSQL)	Built-in data sources on current plugin code	No Angular rewrite is usually needed. Confirm each data source version and query editor behavior in the target release notes.
Third-party Angular panel	Updated plugin or replacement panel	Check whether the vendor publishes a React-based version. If none exists, plan a replacement panel and rebuild the affected dashboards.
Third-party Angular data source	Updated plugin or replacement data source	Confirm plugin availability and maintenance status with the publisher before upgrading. Unmaintained plugins may stop loading on newer releases.
Dashboard JSON with hard-coded Angular options	Panel JSON using current options	Search exported JSON for legacy panel types and Angular-only keys. Edit or re-create these panels so they load without errors after migration.

Documented tools for finding and converting Angular dependencies

Grafana's Angular deprecation leaves a few documented paths: automatic dashboard migrations, plugin version views, dashboard JSON, provisioning and as-code tooling. Each one covers part of the work, and none of them proves a dashboard still renders correctly, so the cards below separate what each tool does from what you still have to check.

Automatic Graph and Table-old migrations

Grafana can convert legacy Graph panels to the current Time series panel and Table-old panels to the current Table panel when a dashboard is opened or saved in a supported version. The conversion handles the common option mapping, but it does not rewrite queries, transformations or custom field overrides that rely on Angular-specific behavior. Check each converted panel against its original, especially thresholds, axis settings and legend options. Confirm the exact migration behavior and any settings it skips in the documentation for your target version.

Plugin catalog and version checks

The plugin catalog and the plugin management views in Grafana show which plugins are installed, their versions and whether they are signed or served from a catalog entry. Use them to list third-party panels and data sources that still declare Angular support, then compare each version against the release notes from its maintainer. A plugin that is installed but unmaintained may show no warning yet still fail after an upgrade. Confirm each plugin's compatibility statement with its author before you plan an update or replacement.

Dashboard JSON for search and bulk review

Every dashboard can be exported as JSON, and the panels array records each panel's type, datasource and plugin identifiers. Searching exported files for legacy panel types such as graph or table-old, or for plugin IDs you no longer ship, gives a complete inventory across folders and organizations. Use a script to list matches by instance, then review the results manually. The JSON does not show whether a query still returns the same data, so pair the inventory with a rendering test on each dashboard.

Provisioning files for startup loading

Provisioning loads dashboard JSON files and plugin definitions from disk when Grafana starts, so updated dashboards and plugin lists can be applied the same way on every instance. Store the provisioned dashboards in version control, point the dashboard provider at the directory, and restart or reload to apply changes. Provisioned dashboards are read-only in the UI, which helps stop drift but also means edits must go through files. Confirm the provider options and reload behavior for your version before relying on them for a cutover.

API and as-code options

The Grafana HTTP API can update dashboards and list plugins, and Grafana documents further as-code options including Terraform and Git Sync. These tools apply the same converted dashboards across several instances from one reviewed source, which matters when Angular removal must happen on a fleet. They do not decide which panels to replace or test the results, and API calls that overwrite dashboards without a version check can erase a teammate's changes. Confirm the resource types, authentication method and dashboard versioning behavior in the documentation for your target release.

How the migration runs from inventory to decommissioning

The sequence moves Angular-dependent dashboards and plugins from an unknown starting point to a tested, cut over state, then removes the Angular code once nothing uses it. The order depends on your target Grafana version and on how your teams own their dashboards.

Inventory Angular dependencies across all instances
Start by listing every dashboard, panel, data source and installed plugin that relies on AngularJS, across every Grafana instance and organization you run. Use the Grafana UI and the instance's plugin list, search dashboard JSON for legacy panel types such as Graph and Table-old, and record the owning team, folder and last-viewed date for each item. The step is done when you have one inventory file that maps every Angular-dependent asset to an owner and a migration path, and that file has been reviewed by at least one person outside the platform team.
Classify each item by migration path
Sort the inventory into three groups: panels that Grafana migrates automatically, such as Graph and Table-old, panels that need manual rebuilding with a React-based equivalent, and third-party plugins that need an updated version, a replacement or retirement. Confirm the automatic migration behavior and any known gaps against the release notes for your target version, because those details change between releases. The output is a classified list with a named decision owner for every third-party plugin.
Pilot on representative dashboards
Pick a small set of dashboards that cover each migration path, including at least one that uses a third-party plugin and one with template variables, annotations and alert rules attached. Run the automatic migration or manual rebuild on a copy in a non-production instance, then check that queries, transformations, thresholds, links and permissions survive. The pilot is complete when each sample has a written pass or fail result and every failure has a recorded fix or a decision to exclude it.
Test with the owning teams
Hand each team its migrated copies and ask them to validate the panels against the data they actually use, since only the owners know what a correct chart looks like. Record their sign-off per dashboard, along with any changes to field overrides, units, legends or drill-down links. The step is done when every dashboard in the wave has a named owner's approval or a documented exception.
Run old and migrated dashboards in parallel
Keep the original Angular dashboards in place and show the migrated versions alongside them for a defined observation period set by your change process. Compare the rendered values, time ranges and alert evaluations for the same inputs, and log any difference that is not explained by the migration. Do not retire an original until the comparison shows no unexplained differences and the owning team confirms that the migrated view answers the same questions.
Cut over folders or instances in batches
Move dashboards in batches by folder or by instance, starting with low-impact teams and ending with dashboards that feed on-call or executive views. Update links, bookmarks, provisioning files and any API automation that references the old dashboard UIDs, and keep a rollback copy of each batch. The batch is closed when its dashboards load without Angular errors, its links resolve, and the owners have confirmed the cutover in writing.
Remove Angular plugins after no dependencies remain
Once a final inventory scan shows no dashboard, folder or provisioning file still references an Angular panel or plugin, uninstall those plugins and remove any configuration that enables them. Repeat the inventory scan after removal and keep the results with the change record. The step is complete when the scan is clean and the removal is recorded, and any later dashboard that depends on an Angular plugin is caught by the same process.

What drives the cost and duration of an Angular migration

This table lists the factors that move the cost and schedule of replacing Angular panels and data sources, and the direction each one pushes. Read the first rows as the size of the inventory and the last rows as the conditions that slow sign-off and testing. The main takeaway is that the number of dashboards matters less than how many use custom Angular code or unmaintained third-party plugins.

Driver	Effect on cost or time	How to keep it down
Dashboards and panels using Angular	More dashboards and panels raise inventory, conversion and test effort in roughly direct proportion	Run an inventory first, retire unused dashboards and group the rest by owner
Third-party Angular plugins	Each plugin needs a replacement, an update or a removal decision, and maturity varies widely	List each plugin with its version, maintainer status and the panels that use it
Custom JavaScript or Angular code in panels	Hand-written code is the slowest item to convert and needs developer time and review	Replace custom code with built-in panels or Grafana plugins where the output allows it
Data sources needing a version change	Data sources that depend on older plugin versions add upgrade, credential and query retesting work	Confirm each data source plugin version and its supported Grafana release before the migration window
Teams that must sign off	Each owning team adds review rounds and waiting time, often the longest delay in the project	Agree sign-off owners and a fixed review window before the inventory starts
Access to dashboard owners and test data	Missing owners or non-production data stops testing and forces rework	Name owners in the plan and provide a staging copy of each data source with representative data
Provisioned or manually edited dashboards	Provisioned dashboards need changes in files and deployment pipelines, while manual edits need per-instance work and drift checks	Confirm how dashboards are stored, then change files in source control instead of the UI where possible
One-time versus recurring costs	Inventory, conversion and testing are one-time, while plugin upkeep and dashboard reviews recur after the move	In the quote, separate the one-time work from any ongoing support or retainer for plugin maintenance

What usually goes wrong with Angular panel replacements

Angular panel replacements tend to fail in quiet ways: the dashboard loads, but the numbers, links or alerts behind it have changed. The risks below share one root cause, which is that the old panel behavior was never written down, so nobody checked it after conversion.

Converted dashboards show different values

A panel can render without errors and still display different numbers after conversion. Differences often come from default units, decimal handling, null-value treatment, time shift settings or how a series is aggregated when the panel is re-rendered. Before cutover, pick a set of high-value panels, record their current values for a fixed time range from the old dashboard, and compare them with the converted version. Treat any mismatch as a blocker until someone explains it.

Third-party plugins without React releases

Some community panels and data sources were written only for AngularJS and have no React-compatible release. Their dashboards may load with a plugin error or disappear from the panel picker. Build an inventory of every plugin ID in use, check each plugin's release notes and repository for React support, and decide per plugin whether to update, replace with a built-in panel or retire the dashboard. Record the decision with an owner before the migration window opens.

Variables and transformations behave differently

Template variables, repeat settings, chained transformations and field overrides may evaluate in a different order or with different defaults after conversion. A variable that once returned all values may now return none, and a repeated row may collapse. Test each dashboard with its variables set to their common values, including multi-value and All selections, and confirm that every transformation still produces the same table columns and row counts.

Alerts and links depend on panel IDs

Alert rules, dashboard links, bookmarks, and scripts sometimes reference a panel by its numeric ID or by a URL fragment. Conversion can change or reassign those IDs, so an alert that once opened the right panel may open a blank page or nothing at all. Export every dashboard JSON before conversion, list each panel ID referenced by an alert, link or script, and verify those references after the migration.

Breakage found only after cutover

Teams that use a dashboard rarely check it on the day it changes, so faults often surface days later during an incident review or a month-end report. Shift validation left by assigning each critical dashboard to a named owner who signs off on a side-by-side comparison in a staging instance. Keep the pre-migration backup available so the old version can be restored if a dashboard fails in production.

Unsupported plugins left installed

A plugin that no longer works with the current Grafana version may stay installed, which leaves unsupported code running on the server and makes future upgrades harder to plan. Compare the installed plugin list against the dependencies of every dashboard, remove plugins that no dashboard uses, and record the remaining plugin versions and their vendor support status in the change record. Check the plugin list again after each Grafana upgrade.

Questions buyers ask before replacing Angular panels in Grafana

How much does replacing Angular panels in Grafana cost?

The cost depends on how many dashboards, panels and third-party plugins are in scope, and on how much of each dashboard needs rework after the automatic migration. Most of the cost is skilled labor: someone has to inventory dependencies, run the conversions, rebuild panels that do not convert cleanly, and test results with the people who use them. A written quote should list the dashboards and plugins in scope, the migration method for each, the testing approach, the number of review rounds, what the client team provides, and the handover documents. Ask whether the quote covers an inventory phase separately, because the inventory often changes the rest of the estimate. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does an Angular panel migration take?

Duration is set by the number of affected dashboards, how many panels need manual rebuilding, how many third-party plugins need a replacement decision, and how quickly dashboard owners can review results. Teams with a small set of dashboards that use only the built-in Graph and Table-old panels usually finish faster than teams with many custom plugins and shared folders. Grafana's upgrade guidance sets the pace of the product itself: major releases arrive once a year in April or May, minor releases every other month, and each minor release is supported for 9 months. Plan the work around the Grafana version you run now and the version you plan to move to, and confirm the planned schedule with your own release calendar.

What does our team need to provide for the migration?

The work needs named dashboard owners who can confirm what each dashboard should show, and a test instance where changed dashboards can be opened against the same data sources as production. Engineers need read access to the Grafana instance to export dashboard JSON and list installed plugins, and write access to a staging instance to run conversions. Someone must own the decision on each third-party plugin, because replacing it can change queries, thresholds and alert behavior. Ask for a single contact who can approve scope changes and sign off on test results for each team that uses the dashboards.

Can our own team replace the Angular panels without a partner?

Yes, many teams do this internally, especially when the dashboard count is small and an engineer already knows the data sources. The main risks are time, testing depth and knowledge of the plugins in use. Internal teams often underestimate the review effort, because each dashboard needs someone to confirm that values, units, thresholds and time ranges still match what users expect. A partner is useful when the team lacks capacity, when several custom plugins need replacement, or when the work must be documented for audit evidence. Before you decide, list your dashboards and plugins, estimate the testing effort with the owners, and compare that list with the team's available hours.

What should we do with a plugin that has no maintained replacement?

First confirm whether the plugin still runs on the Grafana version you plan to use, because a plugin can work for a while after its upstream project stops. If no maintained replacement exists, the options are to rebuild the panel's output with built-in panels, to move the logic into a data source query or a recording rule, or to write a custom plugin for your own environment. Each option has a cost in build time, ongoing maintenance and security review. Custom plugins must be signed and maintained by someone in your organization, and their scope should be written down before any work starts. Record the decision for each affected dashboard so that owners know what changed and why.

How do we test migrated dashboards without checking every panel by hand?

Start by exporting the original dashboard JSON, converting it, and comparing the two versions for panel types, field overrides, units, thresholds, transformations and queries. Automated comparisons catch structural changes quickly, but they do not confirm that values look right, so pair them with a focused review of the panels that drive decisions or alerts. Keep a list of query results from the old and new dashboards for the same time range, and check that the same alerts fire in staging. Provisioning files in version control make it easier to repeat tests after each change. Confirm with your partner or internal team exactly which checks run, which are manual, and who signs off the results.

Does DeployOpen certify that migrated dashboards meet our compliance requirements?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For a dashboard migration, that means documenting what changed, keeping test records, and showing that owners approved the results. Independent auditors and certification bodies decide whether your controls meet a framework. Ask your auditor which evidence they expect before the work starts, so that the test plan and change records match what they will review.

Updating, replacing or retiring third-party Angular plugins

Updating fits when the plugin still solves a problem your teams depend on and its author has published a release that runs on the Grafana version you are moving to. The work is a version bump in a staging instance, followed by a check that every panel, query option and transformation the plugin provides still renders and returns the same data. Plugin owners are usually the platform team, with application owners consulted on dashboards that rely on specific behavior.

Confirm compatibility first: Check the plugin's catalog listing or the author's release notes for the exact target Grafana version before you change anything.
Test on a copy: Install the new plugin version on a staging instance with a copy of production dashboards and data sources.
Compare outputs: Check that panel values, thresholds, units and links match the production rendering for a representative set of dashboards.
Pin the version: Record the plugin version in your provisioning or configuration files so upgrades are deliberate and reproducible.
Plan for abandonment: If the author has stopped releasing, treat the update as a stopgap and schedule the replacement path.

Before promoting the update, confirm the plugin's signature status and that it comes from a source your organization trusts.

Testing dashboards before Angular support ends

Testing an Angular migration means proving that each migrated dashboard still answers the same operational questions as the original, so the test plan should compare the old and new versions side by side before anyone changes the live copy. For each dashboard, list the queries, panel options, template variables, thresholds, data links and alert references, then check them one by one. Confirm that each query returns the same series for the same time range, that variables such as a host or environment selector still populate and filter the panels they drive, and that threshold colors and units still match what on-call staff expect. Alert rules and panel links deserve particular attention, because a dashboard can look correct while a link points at a deleted dashboard or an alert no longer references the panel it was built from. Keep the original dashboards in place, and do not delete or overwrite them until the owners have signed off in writing.

Rendering needs its own pass. Open each migrated dashboard in a browser as a representative user from every group that relies on it, including people with restricted folder permissions and users on the smaller screens they actually use, and note anything that renders blank, shifts layout or shows a plugin error. Where a third-party plugin is still involved, test it on the Grafana version you plan to run, not the one you used during development. Record each check with the dashboard identifier, the Grafana version, the tester, the date, the result and the screenshot or export that supports it. Store these records with your change request so reviewers can trace what was tested and who accepted the result. Once every owner has signed off, set a dated cutover for disabling the Angular plugins, announce it to the dashboard owners, and confirm with your change board that the date and rollback path are recorded.

How DeployOpen works on this

DeployOpen starts with an inventory of the dashboards, panels and third-party plugins that still depend on Angular in your Grafana instance. We then agree a fixed scope in writing, build and test the replacements in a copy of your environment, and hand over documented, verified dashboards that your team can run.

How we scope

Inventory of dashboards, panels and data sources flagged as Angular in your instance, with owners named for each
Decision per item: automatic migration, plugin update, React replacement or retirement, recorded in the written scope
Agreed test cases and acceptance criteria for each dashboard before any change is made
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts

How we build

Conversion work carried out in a staging copy of your Grafana, never first on production dashboards
Review of the automatic Graph and Table-old migrations, with manual fixes where field overrides or thresholds change
Third-party plugin updates or replacements checked against the Grafana version you run
Dashboard definitions kept under version control, with changes applied through provisioning where your setup allows

How we hand over

Side-by-side verification report comparing panel output before and after each change
Written runbook covering the migration steps, rollback path and remaining plugin dependencies
Knowledge transfer sessions so your team can find and fix Angular usage in future dashboards
Final inventory showing every dashboard status, with open items listed and assigned

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Periodic rechecks of dashboards and plugins as new Grafana releases change compatibility
Retainer scope agreed in writing, covering the Grafana versions and plugins your team uses
Quotes follow from the written scope, so ask for each recurring item to be priced separately

Replacing Angular panels and data sources in Grafana