Grafana 10 to 11 upgrade: why the 10.4 step matters
The upgrade from a self-hosted Grafana 10.4 instance to 11 is only safe after two things are done on 10.4.x: legacy alerting has been migrated to Grafana Alerting, and AngularJS data sources and panels have been removed or replaced. Grafana 11.0 removes legacy alerting entirely and will not start while legacy alerting settings are present, so an instance that skips this step will fail at startup, not degrade gracefully. AngularJS is turned off by default in 11.0, so any dashboard that depends on an Angular panel or data source will stop loading. Both checks belong on 10.4.x, where the old behavior still runs and you can compare alert rules and dashboards before and after the change.
Your team should confirm three things before scheduling the move. First, inventory every alert rule, contact point and notification policy that still runs on legacy alerting, and confirm each one has a Grafana Alerting equivalent that routes to the same receivers. Second, list every installed plugin and data source that depends on AngularJS and decide whether each is replaced, updated or retired. Third, read the 11.0 breaking changes page in full against your own configuration, since it covers more than these two items. The Grafana 11.0 breaking changes page is the reference for the exact behavior of each change.
On release cadence, Grafana's upgrade guidance says major releases arrive once a year in April or May, minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. Plan the 10.4.x preparation against the patch releases available when you start, and confirm the current support dates for 10.x and 11.x with Grafana's upgrade documentation, since those windows decide how long your 10.x instance can remain on a supported line while the migration work is scheduled.
What changes in Grafana 11 and what you must do
This table lists the four breaking changes in Grafana 11.0 that affect a 10.4 upgrade, the impact each has on a running instance, and the action to take before or after the upgrade. Read the rows in order, because the legacy alerting row is the one that can stop Grafana from starting at all.
| Change | Impact | Action needed |
|---|---|---|
| AngularJS off by default | AngularJS data sources and panels no longer load because AngularJS support is turned off by default in 11.0. | Inventory Angular panels and data sources before upgrading, then replace or update each one. Confirm any exception you need with the Grafana 11.0 breaking changes page. |
| Legacy alerting removed | Grafana 11.0 removes legacy alerting entirely and will not start while legacy alerting settings remain. | Migrate every alert to Grafana Alerting on 10.4.x before upgrading, and remove legacy alerting settings from the configuration first. |
| Anonymous devices counted as licensed users | In Grafana Enterprise 11.0, anonymous devices count as active licensed users, which can change your license count. | Check whether anonymous access is enabled, estimate the device count with your license contact, and decide whether to keep anonymous access before upgrading. |
| Forward slashes in folder names | After the 11.0 subfolders change, folders with forward slashes in their names can in rare cases send alert notifications to the default receiver. | Find folder names containing forward slashes, rename them where practical, and test alert routing for those folders after the upgrade. |
What to inventory and back up before you upgrade
Most Grafana 10 to 11 upgrade problems are discovered after the package is already installed. The cards below cover the state you need to capture and the inventory you need to finish first, so a failed start can be rolled back and a clean start is predictable. Work through them in order, because the alerting and plugin findings decide whether the upgrade can proceed on the planned date.
Configuration database backup
Back up the database that holds Grafana's configuration, dashboards, users and alert state before anything else changes. Use the engine you actually run: a copy of grafana.db for SQLite, or a logical dump or snapshot for MySQL or PostgreSQL. Confirm the backup restores into a scratch instance, because a file that cannot be opened is not a backup. Record the exact Grafana version it came from, since a rollback depends on it.
Configuration and provisioning files
Copy grafana.ini or the environment variables that override it, along with the provisioning directory that defines data sources, dashboards, plugins and alerting resources. Provisioned objects reload at startup, so a stale copy can silently revert a change. Store these files in version control if they are not already there, and note any secrets that come from files or environment variables rather than the ini file.
Installed plugins
List every installed plugin with its version and source, including panels and data sources installed by hand from archives. Plugins are not always restored by a database backup, so keep a copy of the plugin directory. Identify which entries are AngularJS plugins, because those are the ones that stop loading in 11.0 and need a replacement or a removal plan before the upgrade window opens.
AngularJS panels and data sources
Grafana 11.0 turns AngularJS support off by default, so AngularJS data sources and panels no longer load. Export every dashboard and walk the panel types in use to find the ones that depend on AngularJS. Record which dashboards would show an empty panel after the upgrade, who owns each one, and whether the replacement is an existing core panel or a plugin the team must approve.
Legacy alerting settings
Grafana 11.0 removes legacy alerting entirely and will not start while legacy alerting settings are present. Inventory every legacy alert rule, notification channel and related setting, then migrate them to Grafana Alerting on 10.4.x before the upgrade begins. Confirm that the migrated rules fire and route to the expected contact points, because a rule that migrated without its routing is a silent gap in monitoring.
Folder names containing slashes
Folders with forward slashes in their names can, in rare cases, send alert notifications to the default receiver after the subfolders change in 11.0. List every folder whose name contains a slash, including nested folders, and note the alert rules stored in them. Rename the folders where the business allows it, or test those rules in the staging instance and confirm each one reaches the intended receiver after the upgrade.
Test environment that mirrors production
Build a staging instance from the production backup, with the same database engine, plugins, provisioning files, authentication settings and reverse proxy path. Run the upgrade there first and check login, dashboards, data source queries and alert routing. Confirm that the anonymous access settings match production, since Enterprise licensing counts anonymous devices as active licensed users in 11.0. A staging copy that differs in these areas will not predict the production result.
Why legacy alerting must be migrated on 10.4.x first
Grafana 11 removes legacy alerting entirely and will not start while legacy alerting settings are present. That makes the migration to Grafana Alerting a prerequisite for the major upgrade, not a task to finish afterward. The Grafana 11.0 breaking changes documentation says users must complete the migration on 10.4.x before upgrading, so the work belongs in a 10.4 change window with its own rollback point. Plan it as a separate step with a named owner, because a failed migration discovered during the 11 upgrade leaves you with a service that cannot start.
Verify the result on 10.4 before you touch the binaries. In the Grafana UI, open Alerting and check that every migrated rule appears under alert rules, with the expected evaluation group, labels and folder placement. Then review contact points and confirm each receiver has the correct integration type, endpoint and secrets. Finally, inspect notification policies and confirm the default route and nested routes match what the legacy setup did. Send a test notification to each contact point and fire a test alert through a non-production rule so you see the full path end to end.
Confirm imported behavior against the vendor documentation rather than assuming parity. Check how the migration handled silences, mute timings, alert rule labels and any custom templates, and verify the details in the Grafana 11.0 breaking changes guide. Ask whether any rules fell back to a default receiver, since folders with forward slashes in their names can, in rare cases, route notifications to the default receiver after the 11.0 subfolders change. Record each rule and receiver you checked so the sign-off is evidence, not memory.
How to sequence the Grafana 10.4 to 11 upgrade
The sequence puts backups and legacy alerting migration ahead of the binary swap, so the test instance proves the upgrade before production changes and each stage has a defined way back.
Back up the database, config and plugins
Before anything changes, take a copy of the Grafana database (SQLite grafana.db, or the MySQL or PostgreSQL database if you run one), the configuration files, the provisioning directory and the plugins directory. Store the copies outside the host being upgraded and record the exact running version. Check: you can restore the backup to a separate host and log in with an existing account. This copy is your rollback point for every later step, so keep it until production has run cleanly on 11.x for an agreed period.
Migrate legacy alerting to Grafana Alerting on 10.4
Grafana 11.0 removes legacy alerting entirely and will not start while legacy alerting settings are present, so this migration must finish on 10.4.x before any upgrade. Run the in-product migration on the current version, then review the migrated rules, contact points and notification policies against the originals. Check: every legacy rule has a Grafana Alerting equivalent, and a test notification reaches each contact point. Rollback: if a migrated rule behaves differently, restore the pre-migration backup and rebuild that rule by hand before retrying.
Inventory and replace AngularJS plugins
In Grafana 11.0 AngularJS support is off by default, so AngularJS data sources and panels stop loading. List every installed plugin and every dashboard panel type in use, then mark which ones depend on AngularJS. Replace or update each one with a maintained equivalent, or plan a documented exception if the plugin is abandoned. Check: a dashboard inventory shows no panel that depends on an AngularJS plugin without a replacement. Rollback: keep the old plugin versions in the backup so the 10.4 instance can still render those dashboards if the upgrade is halted.
Check folder names that contain slashes
Grafana 11.0 changed how subfolders are handled, and folders with forward slashes in their names can, in rare cases, send alert notifications to the default receiver. Search for folder names containing slashes, then rename them or review the alert rules inside them and the notification policies that route to those folders. Check: each affected rule is tested against its intended contact point after the change. Rollback: restore the folder names from the backup if a rename breaks dashboard links or automation that refers to them.
Upgrade a test instance from the same backup
Restore the production backup to a separate test host with the same data sources, plugins, authentication settings and reverse proxy path, then upgrade that copy to 11.x. Keep the test host on the same database engine as production so that migration behavior matches. Check the upgrade log for startup errors and confirm the instance starts with the expected configuration. Rollback: discard the test host and restore again from backup, which costs nothing in production.
Verify data sources, panels and alert delivery
On the test instance, open each data source and run its health check, then load a sample of dashboards that cover each panel type and data source. Trigger a test alert through each contact point and confirm delivery, and check that alerts from the folders reviewed earlier go to the expected receiver. Also confirm the subfolder routing and any reverse proxy path, since a misrouted path can break login. Check: a written list of passing and failing items with an owner for each failure. Rollback: fix failures on the test host and repeat from the restore step.
Verify authentication and anonymous access
Test each sign-in method in use, such as LDAP, OAuth, SAML or the auth proxy, using accounts that represent each role. If you run Grafana Enterprise, review anonymous access, because anonymous devices count as active licensed users from 11.0, and confirm the license count with your Grafana Labs contact before cutover. Check: each role can sign in, sees the expected folders and cannot reach restricted data. Rollback: revert the authentication configuration from the backup if sign-in fails, and do not cut over until it passes.
Upgrade production with a defined rollback point
Schedule the production change in a window agreed with the people who depend on Grafana, and take a fresh database and configuration backup immediately before the upgrade. Upgrade the production instance using the same steps proven on the test host, then repeat the data source, panel, alert and sign-in checks. Record the backup identifier and the time of the upgrade in the change record. Check: the production checks pass and alerts fire to their receivers. Rollback: stop the 11.x instance, restore the recorded backup, and start the 10.4 version, noting that data written after the upgrade is lost unless you export it first.
How the upgrade differs by deployment method
Package installs on Debian and Ubuntu, RHEL and Fedora, SUSE or Windows keep Grafana as a service on a host you manage, so the upgrade replaces packages on that host. The configuration file, data directory and plugin directory stay where the package placed them, which makes the host and its files the unit of backup and rollback. On SQLite, the state sits in a local file. On MySQL or PostgreSQL, the state sits in a database you back up separately. Confirm the package names and versions in the Grafana installation docs before you change any host.
- Back up files and database first. Copy
grafana.dbon SQLite installs or dump the MySQL or PostgreSQL database, and archivegrafana.iniand the plugins directory before changing packages. - Finish the alerting migration on 10.4.x. Grafana 11 will not start with legacy alerting settings, so migrate to Grafana Alerting while the host still runs 10.4.x.
- Inventory plugins before the package step. AngularJS is off by default in 11.0, so Angular panels and data sources will not load after the upgrade.
- Keep provisioning files under version control. Data sources, dashboards and alerting resources defined in YAML or JSON load at startup, so they can be reapplied after a rebuild.
- Treat rollback as a restore. Confirm downgrade steps with the vendor before you rely on them, and keep the pre-upgrade backup as the restore point.
Before changing production hosts, start the upgraded package on a test host with a copy of the data and confirm that the service starts cleanly.
In Docker deployments the image tag is the version. Upgrading means starting a new container from a new image tag against the same data volume and configuration, so persistent storage matters more than the container itself. Replacing the container does not move the state, which is why the volume and the database need to be known and backed up before the tag changes. Confirm the image tags and the directories the image expects in the Grafana installation docs.
- Pin an explicit version tag. Avoid floating tags such as latest, so a container restart does not move the instance to a new major version without a planned change.
- Confirm the data volume survives replacement. Grafana's data directory, including
grafana.dbon SQLite, must sit on a named or bind-mounted volume that is not removed with the container. - Back up the volume and any external database. Snapshot the volume and dump the external database before you change the image tag, so both halves of the state are covered.
- Check how plugins and provisioning are supplied. Confirm whether plugins are installed at start, baked into a custom image or mounted, and mount provisioning files the same way they were mounted before.
- Test the new image against a copy. Start the 11.x image with a copy of the volume and the backed-up database, then review the Grafana 11.0 breaking changes against the instance.
After the change, check the running container's image tag, volume mapping and environment variables so the new container reads the same state the old one did.
On Kubernetes, Grafana is usually deployed through a Helm release, and the release values, chart version and persistent volumes together describe the running instance. A helm upgrade changes the workload definition, but it does not back up the state that the workload depends on. Persistence and the external database decide whether the rollback path is a restore or a rebuild. Check the chart you use against the Grafana version it deploys, since chart and application versions are separate.
- Map the chart version to Grafana 11. Review the values file for image tag overrides, so the release installs the Grafana version you planned.
- Verify persistence before the upgrade. Confirm that the chart's persistence settings are enabled and point to a volume that outlives the pod, and check this in the rendered values rather than assuming the chart default.
- Back up the database before running helm upgrade. Back up the external MySQL or PostgreSQL database, or the persistent volume for SQLite, because the release values do not contain dashboards or users.
- Review plugin values for Angular dependencies. Plugin lists in the values file must be checked against the AngularJS change in 11.0 before the release is applied.
- Keep provisioning in source control. Declare provisioned data sources, dashboards and alerting resources in Git and deliver them into the cluster, so they can be reloaded after a rebuild.
Review the rendered manifests with a dry run in a staging namespace before applying the release to production.
A high availability setup runs two or more active-active Grafana servers behind a load balancer, with MySQL or PostgreSQL as the shared database. The upgrade becomes a rolling change across nodes, and the shared database is the single place where most state lives. SQLite cannot serve this model, so the upgrade plan starts from one of the supported production databases. Read the high availability docs before changing the first node.
- Take one database backup before the first node changes. A single backup of the shared database covers every node, and it should be complete before any node moves to 11.x.
- Upgrade one node at a time. Drain a node from the load balancer, upgrade it, and return it to service before moving to the next, so users stay on healthy nodes.
- Confirm alerting does not send duplicates. The high availability docs note that alerting needs additional configuration to avoid duplicate notifications, so verify that setup on the upgraded nodes.
- Test Grafana Live behavior. Grafana Live has limitations in high availability, so test any live-streaming panels after the first node returns to service.
- Confirm the migration path for legacy alerting. The alerting migration must be complete on 10.4.x before any node is upgraded, because a mixed cluster should not start with legacy settings.
Before returning the cluster to full traffic, confirm alerting routing, live panels and session behavior across every node.
What makes a Grafana 11 upgrade take longer
This table lists the inventory items that most change the effort of moving from Grafana 10.4 to 11. Use it to size the audit before you schedule the upgrade, and count each item in your own instance rather than relying on a generic estimate. The main takeaway is that legacy alerting and AngularJS content are the two items most likely to block the upgrade outright.
| Driver | Effect on effort | What to check |
|---|---|---|
| AngularJS panels and data sources | AngularJS is off by default in 11.0, so each affected panel or data source needs a replacement, a migration or a deliberate re-enable decision | Count every AngularJS panel and data source across dashboards and plugins, and list the dashboards that use them |
| Legacy alert rules and settings | Grafana 11.0 removes legacy alerting and will not start with its settings, so migration to Grafana Alerting must finish on 10.4.x first | Export the number of legacy alert rules, confirm the 10.4.x migration path, and test notification routing after migration |
| Folders with forward slashes | Rarely, folders with slashes in their names can route alert notifications to the default receiver after the subfolders change | List folder names containing a slash, then check which alert rules and contact points they feed |
| Enterprise licensing and anonymous access | In Enterprise 11.0 anonymous devices count as active licensed users, which can change license counts and cost | Confirm whether anonymous access is enabled, count anonymous device usage and check the license terms with Grafana Labs |
| Authentication integrations | Each identity provider, SAML, team sync or SCIM setup needs its configuration retested against the new version and edition | Inventory every login method in use, note which need Enterprise, and retest each sign-in path in a staging copy |
| Dashboards needing review | The count of dashboards that use removed or changed panels, data sources or alert links sets the review workload | Run a dashboard inventory, tag those that depend on AngularJS or legacy alerting, and assign owners for sign-off |
| Staging and rollback copy | A tested copy of the database and plugins adds setup time but makes the upgrade reversible | Confirm backup scope for the database, configuration and plugins, and time a restore in a non-production environment |
Questions buyers ask before a Grafana 10 to 11 upgrade
What drives the cost of a Grafana 10 to 11 upgrade?
The cost follows the number of things that must change, not the version number alone. The main drivers are how many AngularJS panels and data sources you run, how much legacy alerting you must move to Grafana Alerting before the upgrade, how many dashboards and folders use forward slashes in their names, how many environments (test, staging, production) you need to walk through, and how much of the stack is automated with provisioning or infrastructure as code. Each of these adds scoped work. Ask any provider for a quote that lists those items separately, with the work to migrate or replace each one, and whether the price covers a rollback plan and post-upgrade checks. A quote from a fixed written scope is the only basis for a figure.
How long does a Grafana 10 to 11 upgrade take?
No duration is fixed for every environment, so treat any single number with caution. The time depends on how much legacy alerting must be migrated first, how many AngularJS plugins must be replaced or retired, how many environments you test in, and how quickly your change windows and approvals run. Ask for the timeline to be split into phases: inventory, alert migration on 10.4.x, a test upgrade, production cutover and post-upgrade verification. Ask the provider which phases depend on your team's availability, such as access to data sources, DNS and load balancer changes, and sign-off from application owners.
Can our in-house team run the Grafana 10 to 11 upgrade?
Yes, many teams do this themselves, provided they have people who can read Grafana's breaking changes for 11.0, inventory their plugins and data sources, and test dashboards and alerts after the change. The hardest parts are usually the alert migration and the subfolder routing check, because they affect whether notifications reach the right receiver. If your team has no staging environment, no backup and restore practice, or no one who owns the alert rules, a partner can cover those gaps. Decide this by checking the skills and time your team can commit before the change window, not by the version alone.
How does alert migration change the effort of the upgrade?
Alert migration is the item most likely to change the schedule. Grafana 11.0 removes legacy alerting entirely and will not start with legacy alerting settings, so you must migrate to Grafana Alerting on 10.4.x before you upgrade. The effort depends on how many legacy alert rules, notification channels and contact points you have, whether they route through a shared Alertmanager, and whether any of them depend on folder names. Ask the provider to inventory every legacy alert, map each one to a Grafana Alerting rule and receiver, and test notifications end to end in a non-production instance before the production upgrade.
What must our team provide before the upgrade starts?
Plan to provide access and decisions, not only time. Typically this means a current Grafana instance you can reach from a test environment, the database that stores Grafana's configuration (SQLite, MySQL or PostgreSQL), a list of installed plugins and data sources, copies of provisioning files or infrastructure code, named owners for dashboards and alert receivers, and a change window with a rollback decision maker. For Grafana Enterprise, you also need to confirm how anonymous users are counted under the 11.0 licensing change. Ask the provider to list these inputs in the written scope so gaps are visible before the work begins.
What does a fixed-scope Grafana upgrade engagement cover?
A fixed-scope engagement covers the work named in a written agreement: scope, deliverables and timeline agreed before work starts. For this upgrade, a typical scope lists the inventory of plugins, data sources and alerts; the alert migration on 10.4.x; the test upgrade and its verification; the production upgrade with a rollback plan; and the handover documentation. It should state what is excluded, such as replacing abandoned community plugins or changes to the underlying data sources. DeployOpen plans and implements self-hosted Grafana inside your own infrastructure and documents the result, and it can offer ongoing support as a retainer if you want it afterward.
Which Grafana 11 risks should we confirm before quoting?
Confirm four points with any provider. First, whether AngularJS panels and data sources will stop loading, since 11.0 turns AngularJS support off by default. Second, whether all legacy alerting has been migrated, because Grafana will not start with legacy alerting settings. Third, whether your Enterprise licence counts anonymous devices as active licensed users. Fourth, whether any folder names contain forward slashes, since the 11.0 subfolders change can, in rare cases, send alert notifications to the default receiver. Check each item against the Grafana 11.0 breaking changes documentation and your own environment before agreeing on a date.
How DeployOpen scopes a Grafana upgrade
DeployOpen starts every Grafana 10 to 11 engagement with an inventory of the running instance, not with the upgrade itself. The inventory covers the installed version, the database behind it (SQLite, MySQL or PostgreSQL), every AngularJS panel and data source, any legacy alerting configuration, the Enterprise or open-source edition in use, and the number of users who sign in, including anonymous access. Those findings decide the work. An instance with no Angular plugins and no legacy alerts is a different job from one with both, and the written plan says which case applies before any change is made. The plan is then agreed as a fixed scope with deliverables and a timeline in writing, so the client knows what is included and what a change request would add.
The client provides the inputs that make that scope accurate. Name a technical owner who can approve changes to the production instance, a business owner for the dashboards and alert routes that must keep working, and someone who can confirm which teams depend on each data source. DeployOpen needs read access to the Grafana server, its configuration files and the database, plus a staging copy that matches production closely enough to rehearse the upgrade. Ask for a change window and a rollback decision maker in writing. Confirm with your own team whether the instance runs behind a subpath proxy, since that setting shapes the subfolder check. Any figures for effort or cost come from the written quote after the inventory, not before it.
After the upgrade, ongoing support can run as a retainer, which covers monitoring the instance, applying patch releases, reviewing plugin updates and handling issues found in the weeks after cutover. Retainer scope, response expectations and what is excluded should be written into the agreement, the same way the upgrade scope is. Ask for the retainer terms as a separate line in the quote so the one-time migration cost and the recurring support cost stay visible to finance. Before deciding, check the current Grafana release cadence in the grafana/grafana releases page, because the patch level you land on affects how much support work follows.
How DeployOpen works on this
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Grafana 10 to 11 upgrade is handled in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every Grafana 10.4 data source, plugin, dashboard and alert rule that depends on AngularJS or legacy alerting.
- Confirm the database engine, deployment method and whether the instance runs in high availability or in Grafana Enterprise.
- Agree in writing the upgrade path, test environment, rollback point and which items the client or DeployOpen owns.
How we build
- Migrate legacy alerting to Grafana Alerting on 10.4.x in a staging copy, then verify rule counts and notification routing.
- Replace or retire AngularJS panels and data sources, and test folder names containing forward slashes against alert routing.
- Take and verify a database and configuration backup, then run the 11.0 upgrade and check subfolder routing before production.
How we hand over
- Deliver a written record of changed plugins, migrated alert rules, configuration keys and the final versions deployed.
- Document the rollback procedure, including the backup used, and the checks that confirm the upgrade succeeded.
- Walk your operations and security teams through the Enterprise anonymous user licensing question and the items you must confirm.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the upgrade is complete.
- Review Grafana release notes and patch releases with your team so later upgrades start from a current inventory.
- Plan the next major upgrade against the published support windows for each minor and major release.
