How to migrate from Grafana Cloud to self-hosted Grafana without losing alerts or history
Leaving Grafana Cloud for a self-hosted stack means rebuilding the parts Grafana's migration assistant does not handle, which only moves content into the cloud. Export and repoint are manual work. Your team exports dashboards, folders, data sources and alert rules through the Grafana HTTP API, recreates them on a self-hosted Grafana, and then moves the telemetry flow itself. Platform engineers or SREs usually own this, with the Grafana or observability admin signing off on the data sources and alert routing. The effort depends on how many dashboards, alert rules, tenants and data sources you run, and how much of the configuration was built by hand in the UI. Confirm that inventory first, because it sets the scope.
Start with the ingest path, since that decides where history lands. If Grafana Alloy or Prometheus remote write sends metrics to Grafana Cloud, point the same agents at your own Prometheus or Mimir endpoint and run both destinations in parallel for a period. Prometheus keeps local data for 15 days by default and is not clustered or replicated, so long-term history needs remote write into Mimir or another external store. For logs, Loki's retention is disabled by default, so set retention_enabled deliberately and confirm your object storage target before cutting over. Traces need a separate decision because Grafana Cloud's trace store is not covered by the Loki or Prometheus steps. Ask your team to confirm each backend's retention against your audit needs.
Treat alerts as the highest-risk item. Export alert rules through the API, then check the Grafana Alloy or Prometheus rule files, notification policies and contact points. Alertmanager should be pointed at every instance, not behind a load balancer, and in high availability Grafana alerting needs extra configuration to avoid duplicate notifications. Run the new rules in parallel with the old ones and confirm that each page reaches the right responder before disabling the cloud copy. Keep the cloud stack readable until your retention and audit requirements are met, and plan the cutover around the Grafana release cadence so you do not upgrade mid-migration. Ask DeployOpen or your team to write the cutover runbook before any export starts.
Which Grafana Cloud capabilities move cleanly and which need rework
This table maps each Grafana Cloud capability to its self-hosted equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes to see what must be rebuilt or confirmed before cutover. The main takeaway is that dashboards, data sources and log and metric ingestion can usually be rebuilt from exported definitions, while SAML, team sync and SCIM need Grafana Enterprise or a different identity approach.
| Capability | Self-hosted equivalent | Status and what to do |
|---|---|---|
| Dashboards and folders | Grafana dashboards and folders exported through the HTTP API | Needs rework: export as JSON, then confirm folder UIDs and data source references match the new instance |
| Alert rules | Grafana alerting with provisioned alert rules | Needs rework: export rules, then review contact points, notification policies and duplicate notification settings in HA |
| Data sources | Grafana data sources defined in provisioning files | Clean for Prometheus and Loki; confirm each source URL and credential is re-entered on the self-hosted side |
| Alloy or Prometheus remote write | Repointed remote write to self-hosted Prometheus or Mimir | Needs rework: change the endpoint and auth in configuration, then check for gaps while both paths run |
| Loki logs | Self-hosted Loki with object storage | Gap for history: Grafana Cloud data does not carry over, so plan a cutover window and retention for existing logs |
| Tempo traces | Self-hosted Tempo or another OpenTelemetry trace backend | Gap for history: trace data stays in the cloud, so confirm the trace backend and retention before retiring the source |
| User authentication | LDAP, generic OAuth, Entra ID, Okta or GitHub on any edition | Needs rework: SAML, team sync, active sync and SCIM require Grafana Enterprise, and some identity setups need a new configuration |
| Provisioning and as-code | Provisioning files, Terraform or Git Sync | Clean if definitions are stored as code; otherwise rework is needed to recreate resources from exports |
What data and configuration to export and rebuild
Grafana Cloud migration to self-hosted Grafana is mostly a rebuild of configuration, not a data copy. The cards below cover what you can export, what you must recreate by hand or as code, and where metrics and log history stop at the cloud boundary.
Dashboards and folders via HTTP API
Dashboards and their folder structure can be pulled from the Grafana HTTP API and re-imported into your self-hosted instance, keeping folder hierarchy and permissions in mind. Check that every dashboard references a data source by a UID that exists on the target, because a dashboard that points at a missing UID loads with broken panels. Inventory dashboards that use cloud-only plugins before you export, since those panels may not render without the plugin installed. Confirm your API token scope on the source stack before you start the export.
Alert rules and contact points
Alert rules, notification policies and contact points usually need the most rework. Notification secrets such as webhook URLs, SMTP passwords and paging keys are often not returned in exports, so plan to re-enter them on the new stack. Set up alerting on the self-hosted Grafana with HA in mind, because the high availability docs note extra configuration is needed to avoid duplicate notifications. Test each route with a controlled alert before you cut over.
Data source definitions
Data sources such as Prometheus, Loki and Tempo endpoints must be redefined to point at your own Mimir, Prometheus, Loki and tracing backends. Credentials tied to Grafana Cloud stacks, including cloud access policy tokens, will not work on your infrastructure and need new service accounts. Keep data source UIDs stable so existing dashboards and alert rules keep resolving after the move. Confirm which data source types your team uses before drafting the mapping.
Provisioning files for startup loading
Grafana can load data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup, so the rebuilt configuration can live in Git rather than in the UI. Grafana also documents Terraform and Git Sync as as-code options. Store provisioning files alongside your deployment manifests so a new node or a disaster recovery rebuild starts from the same state. Review secret handling in these files, because credentials placed directly in them are a common leak path.
Metrics and log history stays in the cloud
Configuration exports do not carry metrics or log history from Grafana Cloud. Historical series and log data remain in the cloud backends unless you copy them through a separate process, and that process is not covered by the dashboard or alert exports. Ask Grafana Labs what history export options exist for your tier, then decide whether to keep the cloud stack read-only for a defined period or accept a history gap. Document the gap for analysts and auditors.
Confirm what history carries over
Whether any history can move depends on the backend you build: Prometheus local storage defaults to 15 days of retention and is not clustered, while Mimir and Loki hold longer history in object storage. Confirm with your team which series and log streams need backfill, and test whether remote write or a backfill tool can load them into your target. Treat any carried-over history as a separate project with its own validation step.
The migration sequence from inventory to decommission
The sequence moves Grafana Cloud workloads to a self-hosted Grafana, Prometheus or Mimir, and Loki stack in a controlled order, so each stage has a recorded owner, a verified output and a rollback path before the next stage begins. Teams that skip the parallel run usually find gaps in alert coverage only after Grafana Cloud is gone.
Inventory dashboards, alerts and telemetry senders
Export the full estate from Grafana Cloud through the HTTP API: dashboards, folders, data sources, contact points, notification policies and alert rules. In parallel, list every sender of telemetry, including Grafana Alloy agents, Prometheus servers using remote write, Loki log shippers, and any applications exporting OTLP directly. Record each item with an owner and a destination in the new stack. The step is done when the inventory is stored in version control and every alert rule has a named owner who has confirmed it still matters.
Stand up the self-hosted stack
Install Grafana with a production database rather than the default SQLite, since Grafana's installation docs say SQLite does not scale for production. Deploy the metrics and log backends you have chosen, such as Prometheus or Mimir for metrics and Loki for logs with object storage for chunks and index. Configure authentication through your identity provider, noting that SAML and SCIM are Enterprise or Grafana Cloud features, and confirm which OAuth or LDAP option your team will use. Done when a test dashboard loads from a test data source and a test user can sign in.
Convert exports to provisioned configuration
Translate the exported dashboards, data sources and alert rules into files that Grafana loads at startup, using the provisioning format in YAML or JSON. Replace Grafana Cloud data source URLs and credentials with references to the self-hosted backends, and move secrets into your secrets manager rather than plain files. Store the files in Git so changes are reviewed. Done when a clean Grafana instance rebuilds the full set from the repository without manual clicks.
Pilot with one team's dashboards
Choose one team whose dashboards and alerts cover a bounded set of services. Repoint only that team's telemetry, then compare panels on the old and new Grafana side by side for the same time range. Check that PromQL and LogQL results match, that alert thresholds fire on a controlled test, and that the team can work through its normal on-call tasks. Record every difference and fix it in the provisioned files. Done when the team signs off in writing on the pilot checklist.
Run the parallel feed to both stacks
Configure Grafana Alloy or Prometheus remote write so the same samples and log streams reach Grafana Cloud and the self-hosted backends at once. Keep Grafana Cloud alerting active during this period so you can compare alert firing history between the two. Watch for gaps in ingestion, label differences, and retention differences, since Loki retention is disabled by default and must be set on purpose. Done when a full review cycle shows matching alert behavior and no unexplained data gaps.
Cut over users and alerts
Announce the new Grafana address, move user access and team mappings, and switch alert delivery to the self-hosted Alertmanager or Grafana alerting path, with one notification route active at a time to avoid duplicate pages. If you run Grafana in high availability, confirm the alerting configuration that prevents duplicate notifications. Disable the Grafana Cloud contact points only after the self-hosted route has delivered a test page. Done when each on-call rota has received a successful test and users have logged in to the new instance.
Decommission Grafana Cloud
Stop the remote write and log shipping to Grafana Cloud, then keep a read-only export of dashboards, alert rules and exported data for the period your records requirements specify, which your compliance lead should confirm. Revoke Grafana Cloud API keys and access tokens, remove the stored credentials from agents, and close or downgrade the account according to the terms in your contract. Done when no sender points at Grafana Cloud, the keys are revoked, and the archive has been verified as readable.
How the migration differs by team size and starting point
A small team with a handful of dashboards and one Prometheus source has the simplest path. The work centers on a short inventory, one pilot dashboard, and a planned switch of the collector or remote write target. Because few alert rules and users exist, the export through the HTTP API is usually quick to review by hand, and the new Grafana instance can be small. Cost is mostly staff time and the server you run Grafana on, and it recurs mainly through upgrades and patching.
- Inventory: List every dashboard, folder, data source and alert rule in Grafana Cloud, plus the Alloy or Prometheus remote write target that feeds it.
- Pilot: Import a few dashboards into a self-hosted Grafana and compare panels against live data before moving anyone.
- Cutover: Point remote write at your own Prometheus, then update user links and bookmarks in one short window.
- Logs: If you use Loki in the cloud, decide whether a small single-binary Loki instance covers the daily volume before adding it.
- Database: Use a single Grafana server with SQLite for a test, but plan MySQL or PostgreSQL before production.
Confirm with your team the owner of each dashboard and whether any users depend on cloud-only sign-in options before cutover.
A large team with many alert rules, several Grafana stacks and multiple teams sharing data sources needs a longer inventory and a staged cutover. Dependencies between folders, contact points and notification policies are the main source of risk, because an alert that fires in the cloud and in the self-hosted stack at once can cause duplicate notifications. Each stack may use its own remote write path, so each one needs its own cutover plan. Costs grow with the number of environments to run, back up and upgrade, and with the staff needed to review changes.
- Inventory: Export folders, dashboards and alert rules per stack through the HTTP API and record which team owns each one.
- Alerting: Silence or disable cloud notifications for each rule group before enabling the same rule in the self-hosted Grafana, to avoid duplicates.
- Pilot: Migrate one non-critical stack first and run it for a full review cycle before the others.
- High availability: Plan two or more active-active Grafana servers behind a load balancer on a shared MySQL or PostgreSQL database, and test alerting and Grafana Live limits.
- Authentication: Check which SSO features you used in the cloud, such as team sync or SCIM, because some are only in Grafana Enterprise and Grafana Cloud.
Confirm the list of stacks, owners and alert contact points with each team before setting any cutover date.
A team that already runs Prometheus or Loki locally, often as a sidecar or a log shipper, has a smaller move because the data stores are already in place. The job becomes connecting Grafana to those existing sources and removing the cloud write path. Gaps tend to appear in retention, long-term storage and multi-tenancy, which the local setup may not cover. Cost shifts toward storage capacity and operations rather than new software, since Prometheus itself has no paid edition.
- Data sources: Add your local Prometheus and Loki as data sources in self-hosted Grafana and compare query results against the cloud copy for the same time range.
- Retention: Prometheus defaults to 15 days of local storage, so set retention by time or size to match what you need, and note that local storage is not clustered or replicated.
- Loki: Retention is disabled by default in Loki, so set it explicitly and confirm which deployment mode fits your daily volume.
- Security: Loki has no built-in authentication, so place an authenticating reverse proxy in front of it before exposing it to users.
- Remote write: Stop duplicate sends only after the local store has matched the cloud copy for a full cycle.
Confirm your current retention and daily log volume with the team that owns the existing stores, because these figures decide the storage and deployment mode you need.
What drives migration cost and duration
This table lists the factors that most change how much work a Grafana Cloud exit takes and how long the parallel run lasts. Read each row as a lever: the first column names the driver, the middle column explains why it matters, and the last column gives the step that keeps it under control.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Dashboard and alert rule count | Each dashboard, folder and alert rule must be exported, checked for data source references and retested against self-hosted data | Inventory everything first, delete unused dashboards, and convert rules into provisioned YAML or JSON files in Git |
| Number of telemetry senders | Every Alloy, Prometheus or application exporter with a remote write endpoint must be repointed and verified | Group senders by team, change endpoints through configuration management, and cut over one group at a time |
| Log volume and retention needs | Loki storage, compaction and query load grow with ingest and retention, and retention is off by default in Loki | Set retention deliberately before backfill, scope retention by tenant or stream, and size object storage from a measured sample |
| Mimir or Loki operating skills | Teams without experience in these systems spend time on sizing, tuning, upgrades and incident response that Grafana Cloud handled | Confirm skills before scoping, plan training or external support, and document runbooks during the parallel run |
| Object storage choice | Loki's recommended production stores are Amazon S3, Google Cloud Storage and Azure Blob Storage, and other S3-compatible stores need extra validation | Pick a storage backend that matches your existing cloud or data center standards and test restore and retention early |
| Authentication integration | Grafana Cloud users and SSO mappings must move to self-hosted auth, and SAML, team sync and SCIM are Enterprise-only features | Confirm which identity providers your self-hosted edition supports, map teams and roles in advance, and test login for every user group |
| Length of the parallel run | Dual shipping and side-by-side dashboards add cost and effort for as long as both systems run, and alert duplication must be prevented | Set exit criteria in writing, such as query parity and alert parity checks, and silence duplicate notifications from the old stack early |
| Items to ask for in a quote | A quote should show the work at component level, not as one lump sum | Ask for the inventory method, the number of senders and dashboards in scope, storage and retention assumptions, the identity integration plan, and the exit criteria for the parallel run |
What usually goes wrong and how to prevent it
Most failed exits from Grafana Cloud are not technical surprises. They are gaps in alert routing, access control, database choice, retention and storage design that surface after cutover. The cards below cover the checks to make before users and on-call rotations depend on the new stack.
Duplicate alert notifications
During a parallel run, Grafana Cloud and your self-hosted Grafana can both evaluate the same alert rules and notify the same contacts. Your team gets two pages for one incident and may start silencing alerts that are actually useful. Before the parallel run starts, decide which instance is the sole notifier, and disable notification policies on the other. Grafana's high availability docs also say that a multi-node setup needs extra configuration to avoid duplicate notifications, so check this with the same test alert on each node.
Loki without built-in authentication
Loki has no authentication layer of its own. Its documentation says you must run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Teams that point Alloy or other shippers straight at Loki, or leave the HTTP port reachable from the network, expose every tenant's logs. Confirm that only the proxy can reach Loki, that the proxy enforces identity, and that it sets the X-Scope-OrgID header per tenant when auth_enabled is true.
SQLite as the Grafana database
Grafana stores configuration, dashboards, users and alert state in SQLite 3 by default. The installation docs say SQLite does not scale for production, and high availability requires MySQL 8.0 or later or PostgreSQL 12 or later. A default install that works in a test lab can lose or lock configuration under real use. Set the database in the Grafana configuration before importing dashboards, because moving an existing SQLite instance later is extra work.
Loki retention disabled by default
Loki's compactor applies retention, but retention is off until retention_enabled is set. Logs therefore accumulate in object storage indefinitely after migration, and storage cost grows without a limit. Grafana Cloud may have applied retention you did not configure yourself, so review what you were keeping there. Set retention globally, per tenant or per stream selector, and remember that each stream rule must be at least 24 hours.
Prometheus local storage is not clustered
A single Prometheus server keeps its time series on local disk, and the storage docs say it is not clustered or replicated and should be managed like any other single-node database. If that one server fails, the metrics you wrote during the outage are lost unless you have remote write to long-term storage. Plan for a second replica or a Mimir deployment for durable history, and decide how long you need local retention before setting it, since the default is 15 days.
Grafana Live limits in high availability
Grafana's high availability docs list limitations for Grafana Live, the component that streams live updates to the browser, when several active-active servers sit behind a load balancer. Dashboards with live streaming panels may behave differently from single-node installs, which teams often discover only during user acceptance testing. Test streaming panels against the load-balanced setup, and decide whether your users need live updates at all before you commit to a multi-node design.
What the migration needs from your team
Start by naming who owns each part of the move, because most of the work is coordination rather than configuration. One person should own the inventory of everything that lives in Grafana Cloud: dashboards, folders, data sources, alert rules, contact points, notification policies and the Alloy or Prometheus remote write targets that feed them. Export through the HTTP API gives you the raw material, but someone has to decide what is still in use, what is duplicated and what can be retired before anything is rebuilt. Ask your current Grafana Cloud administrator for a list of stacks, users and API tokens, and confirm which teams depend on each folder.
Alert rule owners are the people who must confirm behavior, not just the people who copy YAML. Each rule has a threshold, a evaluation window and a routing path, and a rule that fires correctly in Grafana Cloud can behave differently once it runs against your own Prometheus or Mimir and your own Alertmanager. Ask each owner to sign off on a test window in which both stacks evaluate the same rules and the results are compared. Plan for the alerting HA note in the Grafana docs as well: running two or more Grafana servers requires additional configuration to avoid duplicate notifications, and that work belongs to the platform team.
Platform staff run the new stack: Grafana backed by MySQL or PostgreSQL, Prometheus or Mimir for metrics, and Loki with object storage for logs. The Grafana installation docs make a database mandatory for production, so a database administrator should be part of the plan, along with the people who own object storage and backups. Security staff set authentication, since the Grafana authentication docs say SAML, team sync, active sync and SCIM are limited to Grafana Enterprise and Grafana Cloud, so identity integration needs an early decision. They also apply the security hardening settings and must place an authenticating reverse proxy in front of Loki, which has no built-in authentication. Pricing tiers on the Grafana pricing page do not measure this work. The effort depends on how many dashboards, rules, sources and users you have, so ask any implementation partner for a quote built from your written inventory.
Questions buyers ask before moving off Grafana Cloud
How long does a migration off Grafana Cloud take?
The length depends on the drivers below, and no fixed duration applies to every estate. The main ones are the number of dashboards, folders, data sources and alert rules to export and rebuild, how many Grafana Alloy or Prometheus agents must be repointed by remote write, how much log volume must move to Loki, and how many users must cut over. Sizing the self-hosted backends, building high availability and running both stacks in parallel for validation also add time. Ask any provider for a written timeline tied to a named inventory of these items, and confirm the cutover window with your own change board.
Can an internal team migrate from Grafana Cloud on its own?
An internal team can do it if it already runs Linux servers or Kubernetes, object storage and a managed relational database. Grafana's installation docs list packages, Docker images and Helm charts, but production needs MySQL 8.0 or later or PostgreSQL 12 or later for configuration, because SQLite does not scale for production. Loki needs an object store and a compactor configured for retention, and Prometheus needs a plan for its single-node storage. The team also needs staff for on-call, upgrades and security hardening after cutover. Check those skills against the list before deciding whether to staff the work in-house, hire a partner, or split it between them.
What does the migration assistant move, and what must be exported by hand?
Grafana's migration assistant only moves a self-managed stack into Grafana Cloud, so it does not help you leave. Dashboards, folders and alert rules must be exported through the HTTP API, or rebuilt as code. Grafana's provisioning feature loads data sources, dashboards, plugins and alerting resources from YAML or JSON at startup, and Terraform and Git Sync are documented as-code options, so exported definitions can be kept in version control. Plan manual work for users, teams and single sign-on, because SAML, team sync and SCIM are available only in Grafana Enterprise and Grafana Cloud. Authentication through LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab or Google OAuth works in every edition. Confirm the export coverage with Grafana before you rely on it.
Does leaving Grafana Cloud keep historical metrics and logs?
Historical data does not move automatically. Remote write sends new samples from the cutover forward, so older series stay in Grafana Cloud unless you export them or accept the gap. Prometheus keeps local data for 15 days by default, and its storage is not clustered or replicated, so a self-hosted Prometheus is not a long-term archive on its own. Mimir is the scalable long-term store for Prometheus metrics. In Loki, retention is disabled by default, so logs are kept indefinitely only once retention is enabled on your side, and the compactor applies it. Decide which history you need for audits, incident reviews and capacity planning, keep Grafana Cloud readable for a defined period, and confirm with Grafana which export options your plan includes.
How do you avoid duplicate alerts during the cutover?
Duplicate notifications come from two alerting systems firing at the same time, or from more than one active Grafana node sending the same notification. Grafana's high availability docs say alerting needs additional configuration to avoid duplicate notifications, and Grafana Live has limits in HA, so review both before go-live. For Prometheus alerts, Alertmanager can run as a cluster using its --cluster flags, and Prometheus should point at every Alertmanager instance rather than a load balancer. Plan a single owner per alert during the overlap, pause or remove the Grafana Cloud rules once their self-hosted twins are verified, and test silences and routing with a controlled alert before cutover.
What should an outside partner put in writing before the migration starts?
A written scope should name the deliverables, the timeline and the acceptance checks before any work starts. DeployOpen works on a fixed-scope basis, and a quote follows from that written scope, so ask for the same from any provider. Expect the document to list the inventory of dashboards, folders, alert rules, data sources and agents, the target architecture for Grafana, Prometheus or Mimir and Loki, the high availability and backup design, the cutover and rollback steps, the duplicate-alert plan, and the handover documentation. It should also state what is excluded, including whether ongoing retainers for support, upgrades or continuous testing are part of the price. DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue reports, so the document should say that too.
What do ongoing upgrades involve after moving to self-hosted Grafana?
Upgrades are recurring work, and the cadence is set by each project. Grafana's upgrade guidance describes major releases 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 of a major version for 15 months, so the team must upgrade before support ends. Prometheus starts a new minor release cycle every 6 weeks, and a minor generally stops receiving bug fixes after those 6 weeks, so most teams run an LTS line, which gets bug fixes for one year. Loki's simple scalable mode is being deprecated and will be removed with Loki 4.0, which can force a topology change. Budget for staff time, test environments and change windows, or buy a retainer for them.
How DeployOpen scopes and runs a Grafana Cloud exit
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and a Grafana Cloud exit is scoped the same way. Most engagements are fixed-scope: the scope, deliverables and timelines are agreed in writing before any work starts, and a quote follows from that written scope. For this migration, the scope should name each stack being moved (dashboards and folders, alert rules and contact points, metrics pipelines, Loki log ingestion and the users who need access), the target environment (cloud account, data center or air-gapped network), and the cutover approach. Because Grafana's migration assistant only moves content into the cloud, the export work through the HTTP API and the repointing of Alloy or Prometheus remote write belong in the written scope, not in an assumption.
The decisions to fix in the scope are the ones that drive the rest of the work. Confirm the target backends (self-hosted Mimir or Prometheus for metrics, Loki for logs, and the database behind Grafana), the retention you need for each signal, and whether you will run Grafana in high availability, which needs MySQL or PostgreSQL rather than SQLite. Confirm which identity method your users sign in with after the move, because the authentication docs list SAML, team sync and SCIM as Grafana Enterprise or Grafana Cloud features. Ask the team that will own the platform whether it has an on-call rota for Mimir, Loki and Grafana upgrades. Ongoing support, upgrades and continuous testing are available as a retainer, which can be scoped separately from the migration itself, so you can decide after cutover whether to keep that support in place or run the stack with your own staff.
