What a Grafana migration involves
Dashboards, alert rules and data source connections do not move unchanged from Kibana, Datadog or another Grafana instance. Each platform has its own query language, data model and alerting logic, so a Kibana visualization built on Lucene or KQL queries, a Datadog monitor, and a Grafana panel that queries Prometheus or Loki are different objects that must be rebuilt, not copied. Plan for the migration as a rebuild of queries and alerts, with the export of existing definitions used as a starting inventory rather than a finished import.
The usual triggers are license or cost pressure on a hosted service, data residency requirements that keep telemetry inside your own infrastructure, consolidation of several Grafana instances into one governed platform, and a move off a hosted service such as Grafana Cloud or another vendor's hosted dashboards. Each trigger shapes scope. Cost pressure favors reducing the number of dashboards and alerts carried over, while residency and consolidation require every data source connection to be re-established inside the target environment with its own credentials.
Small estates with one data source family, such as a single Prometheus or a single SQL database, and a few dozen dashboards can often be done in-house by a team that already knows the data. Multi-source estates with many alerts, duplicated dashboards and undocumented ownership usually benefit from a partner's inventory and cutover discipline, which means mapping every dashboard and alert to an owner, a data source and a keep, merge or retire decision before any build starts.
The target database is part of the migration, not an afterthought. Grafana stores its configuration in SQLite by default, can use MySQL 8.0 or later or PostgreSQL 12 or later, and its installation documentation states that SQLite does not scale for production. Confirm which database and version your organization will run, plan the import of users, folders and dashboard metadata into it, and confirm that the database is backed up and tested before cutover. Automatic conversion tools can help with parts of the inventory, but confirm exactly which object types they convert and review every converted query and alert before relying on it.
What the work includes
The migration runs as seven workstreams that move your dashboards, alerts and configuration onto a self-hosted Grafana you control. Scope, deliverables and timelines are agreed in writing before work starts.
Inventory of source objects
We catalog every dashboard, alert rule, data source, user, team and folder in the source system, with owners, usage and dependencies. The inventory register shows which objects are live, which are stale and which depend on a data source that will change. It sets the scope that the rest of the work is priced against.
Target architecture and database choice
We design the self-hosted Grafana layout, including install method, data source network paths and whether one instance or a high availability pair is needed. The configuration database decision is made here: SQLite suits small single-node use, while MySQL 8.0 or later or PostgreSQL 12 or later is required for production and high availability. Confirm your preferred database engine and its support model early.
Data source connections and query rebuilds
Each source query is rewritten for its new data source, such as Prometheus, Loki or a SQL database, because Kibana queries, Datadog metric expressions and source-specific Grafana panels do not translate one to one. We verify label names, time fields, units and aggregation behavior against the source data. Check that the new sources hold the same retention window the old dashboards relied on.
Alert rule conversion to Grafana Alerting
Source alert rules are converted into Grafana Alerting rules, with contact points for each receiver and notification policies that route alerts by label. Thresholds, evaluation intervals, pending periods and mute timings are reviewed, since they often differ between platforms. Duplicate notifications are addressed where more than one instance will evaluate rules.
Configuration database migration
Users, teams, folders, permissions and Grafana's own configuration are moved from SQLite into the chosen MySQL or PostgreSQL database. The migration is rehearsed on a copy, row counts and object references are compared, and the rollback path is kept until the cutover is accepted. Confirm backup and restore procedures for the new database before this step runs.
Parallel run and validation
Rebuilt dashboards and converted alerts run beside the source system for an agreed period. Panel values are compared against the source, and alert tests confirm that each rule fires and reaches the right receiver. Each difference is logged with a decision on whether it is a defect, a deliberate change or a source quirk to accept.
Cutover, rollback and handover
The cutover runbook sets the order of DNS, alert ownership and user access changes, with a tested rollback to the source system. Operators receive handover notes covering provisioning files, upgrade steps, backup and restore, and the support model. Ongoing support and upgrades can be arranged as a separate retainer.
What drives cost and duration
This table lists the factors that change how much work a Grafana migration takes, why each one matters and how to keep it under control before the quote is written.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Dashboards and panels | Each dashboard is rebuilt or converted by hand unless it can be exported and adapted. Panel count, custom plugins and nested rows multiply review time. | Inventory dashboards by owner and usage, retire unused ones before migration, and group similar dashboards into templates with variables. |
| Source systems and query languages | Kibana queries on Elasticsearch or OpenSearch indices, Datadog metrics, logs and APM, Prometheus, Loki and SQL each need a different data source and query rewrite. Every source adds validation work. | List every source per dashboard, consolidate duplicate data sources, and confirm which sources must remain live after cutover. |
| Query complexity and scripting | Templated queries with variables are usually portable. Heavy scripting, Kibana Painless fields, Datadog formulas or custom transformations need manual logic and testing. | Classify queries as simple, templated or scripted early, and agree in writing which scripted logic is in scope. |
| Alert rules and notification routes | Each alert rule needs its condition rebuilt in Grafana Alerting, plus contact points, notification policies, silences and mute timings. Routing errors can page the wrong team. | Export alert definitions, remove stale rules, and map routes to a short list of contact points before rebuilding. |
| Folders and permission rules | Folder structure, dashboard permissions and data source access must be recreated. Permissions are often inherited from the source tool in ways that are not documented. | Document the current access model per team, then design the Grafana folder layout and roles once and reuse them. |
| Users, teams and identity mapping | Each user and team must be mapped to a Grafana role or team. Team sync and SCIM are Enterprise-only features, so open-source mapping may be manual. | Export team membership from the identity provider, decide which groups map to roles, and confirm which features your edition supports. |
| Environments and promotion | Dev, test and production instances multiply configuration, data source credentials and validation runs. Provisioned resources must be promoted consistently. | Limit the number of environments in scope, and use provisioning files so the same definitions deploy to each environment. |
| Cutover window constraints | Parallel running, freeze periods and on-call hand-offs set the minimum time for validation and rollback. A narrow window increases rehearsal and staffing needs. | Agree the window and rollback criteria in advance, run a rehearsal on a copy of the configuration, and keep the old tool readable during the transition. |
| Compliance evidence needs | Assessors may ask for records of who approved each dashboard and alert, how access was tested and how changes were traced. Collecting this evidence adds documentation work. | Confirm the control requirements with your assessor first, then capture approvals and configuration changes in the migration tracker as the work happens. |
Migration phases and outputs
The sequence moves dashboards and alerts from the source platform to self-hosted Grafana in controlled stages, with a documented output and check at each phase so cutover is a decision rather than a leap.
Inventory the source estate
Catalog every dashboard, alert rule, contact point, data source and user group in Kibana, Datadog or the existing Grafana, then pull usage data to mark dashboards and alerts that nobody opens or that no longer fire as candidates for retirement. The output is a signed inventory with a keep, rebuild or retire decision per item, agreed with the owners.
Design the target topology
Map each source data source to its new home, such as Prometheus, Loki or a SQL database, and decide the Grafana configuration database. SQLite is the default but does not scale for production, so the MySQL or PostgreSQL choice is recorded here along with the access model for folders, teams and admins. The output is a target design document that the security and platform owners approve.
Build the instance and connect data sources
Install Grafana in the infrastructure you control, configure the chosen database, identity and TLS, and add data source connections with least-privilege credentials. Provisioning files are written from the start so the setup can be rebuilt. The output is a reproducible instance where every data source passes a connection test and the configuration lives in version control.
Rebuild and compare dashboards
Rebuild each retained dashboard against the new data sources, translating queries from the source query language. For each panel, run the query in both systems over the same time range and compare the values query by query, recording any difference and its cause. The output is a comparison log per dashboard, with signed-off exceptions for known gaps.
Convert and test alerts
Translate each alert rule into Grafana Alerting, then define contact points and notification policies that match the original routing. A test plan fires each rule with a controlled condition and confirms that the notification reaches the intended channel and recipient. The output is a test record for every alert, showing the expected and actual destination.
Run both systems in parallel
Operate the old and new systems side by side, either with both alerting on the same conditions or with alerts muted in one of them, and compare firing history and notification delivery over the agreed period. Duplicates and missed alerts are logged and fixed before cutover. The output is a parallel run report with each discrepancy resolved or accepted.
Cut over with rollback criteria
Before switching, write down the criteria that trigger a rollback, such as a missed notification or a dashboard that shows wrong values, and keep the source system ready to resume. Switch users, links and alert ownership in one controlled change, then monitor. The output is a cutover record with the go decision, the rollback criteria and the outcome.
Decommission and hand over
Retire the source dashboards, alert rules and credentials that are no longer needed, revoke access and document the final state, including runbooks for upgrades and backups. The handover covers who owns each dashboard folder and alert route. The output is a decommissioning record and an operations handover package accepted by the receiving team.
What to keep in-house and what to outsource
This table shows which migration work your own teams should hold and which a partner can build, with the skills each side needs, so you can plan the split before the cutover date is set.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Dashboard and alert ownership | Business owners confirm what each dashboard answers and what each alert means, and who acts on it | Inventory of existing dashboards and alerts, with usage and duplication notes | Service owners, on-call leads, domain knowledge of the systems monitored |
| Data source access and credentials | Approval of read-only accounts, network paths and secret storage policy | Configuring data source connections and provisioning definitions for the new Grafana | Database and metrics platform administration, secrets management |
| Query rebuilds per source | Review of rebuilt queries against known-good values from the old tool | Translating Kibana, Datadog or Grafana queries into PromQL, LogQL or SQL for the target sources | PromQL, LogQL, SQL, Lucene or Datadog query syntax, Grafana panel design |
| Alert conversion and routing | Sign-off that each converted rule fires for the same condition and reaches the right responders | Conversion of alert rules to Grafana Alerting, contact points and notification policies | Grafana Alerting, Alertmanager concepts, incident routing practice |
| Database migration and backup | Choice of MySQL or PostgreSQL, backup retention and restore sign-off | Moving Grafana configuration from SQLite to the chosen database and testing restores | MySQL or PostgreSQL administration, backup tooling, Grafana configuration |
| Identity and folder permission mapping | Decisions on who may view or edit each folder and which groups map to which roles | Mapping identity provider groups to Grafana folders, teams and roles, and verifying access | Identity provider administration, Grafana RBAC, access review practice |
| Cutover coordination with on-call teams | Scheduling, go or no-go decisions, and on-call staff confirming alerts arrive where expected | Runbook drafting, parallel-run checks and rollback procedure | Incident management, change control, communication with responders |
| Post-cutover ownership | Named owners for dashboards, alert rules, and the Grafana instance after handover | Documentation, provisioning files and optional retainer support for upgrades and fixes | Platform operations, version management, provisioning as code |
What usually goes wrong
Most Grafana migrations from Kibana, Datadog or another Grafana fail in the gaps between platforms rather than in the core build. The risks below are the ones teams most often discover after cutover, with a prevention step for each.
Alerts dropped or duplicated in parallel
During the parallel run, an alert can fire on the old platform and never reach the new contact point, or fire on both and page the same on-call engineer twice. Map every notification route, then run each migrated rule against known test conditions and compare which channels received it. Confirm that the old platform is muted only after the new route is verified end to end.
Thresholds and windows that shift meaning
A threshold of 5 percent over 5 minutes can evaluate differently when the new data source samples at another interval, uses a different rate function, or counts missing data as zero. Datadog monitors, Kibana rules and Grafana alert rules each define evaluation windows and no-data handling in their own way. Record the original expression, interval and no-data behavior for each rule, and check the new rule against the same historical incident.
Dashboards that look right but differ
A rebuilt panel can show a plausible line that is quietly wrong, for example a different aggregation such as average versus sum, a rounded bucket size, or a time zone offset in the x-axis. These differences rarely produce errors, so they go unnoticed. Compare the rebuilt panel with the source panel over the same time range for several representative periods, and confirm the time zone and aggregation on both sides.
Inventory that misses incident-only dashboards
Dashboards opened only during postmortems, quarterly reviews or executive reporting often lack owners and do not appear in usage lists. Leaving them out means the team loses a view it needs during the next serious incident. Build the inventory from usage logs or access history where available, and ask each team lead which views they open during incidents and reviews.
SQLite kept as the production database
Grafana stores its configuration, users, dashboards and alert state in SQLite by default, and the installation documentation states that SQLite does not scale for production. Running a migrated instance on SQLite can work in a pilot and then fail under concurrent use or during high availability setup. Plan the move to MySQL 8.0 or later, or PostgreSQL 12 or later, before cutover, and test restore from that database.
Data source credentials copied insecurely
Teams often paste database passwords, API tokens and cloud keys from the old platform into shared notes, spreadsheets or plain provisioning files. These copies outlive the migration and widen access beyond what the original owners intended. Create dedicated read-only service accounts for each data source, store secrets in your approved secrets manager, and rotate the copied credentials once the old platform is retired.
Permissions that do not map across platforms
Kibana spaces and roles, Datadog teams and Grafana folders and permissions are not one-to-one. A straight import can grant engineers edit rights they never had or hide dashboards from the teams that depend on them. Write a mapping table from each source role to a Grafana folder and permission level, and verify access with one test user per role before users are moved.
Cutover without a tested rollback
A cutover plan that only describes moving forward leaves no safe path when the new alerting or dashboards fail in production. Define the rollback trigger, the state to restore, and the owner who decides, then rehearse it in a staging copy with the real data sources. Confirm how long the old platform stays available and which alerts remain active during the rollback window.
How the work differs by starting point
Kibana users usually arrive with dashboards built on Elasticsearch or OpenSearch indices, so the main effort is translating queries rather than moving panels. Expect these tasks to change:
- Query translation: Rewrite Lucene or KQL searches and aggregations as queries for the Grafana data source that holds the same data, and confirm which index patterns map to which data sources.
- Visualizations and saved searches: Rebuild Kibana visualizations as Grafana panels and turn saved searches into Explore queries or log panels, since the layouts do not carry over automatically.
- Alerting: Inventory any Kibana alerting or Watcher usage first, then confirm each rule's logic, schedule and notification target before converting it to Grafana Alerting.
- Access model: Map Kibana spaces and roles to Grafana folders and permissions, which are structured differently.
- Validation: Compare result counts for the same time range in both tools before retiring any Kibana dashboard.
Datadog migrations involve several data types, and some of them depend on export limits you need to check with the vendor. Expect these tasks to change:
- Metrics and logs: Decide where each Datadog metric and log stream will live in your own stack, then rebuild queries against those backends.
- Monitors: Convert Datadog monitors into Grafana alert rules by hand or with scripts, and confirm thresholds, evaluation windows and notification routing for each one.
- Dashboard widgets: Map each Datadog widget type to a Grafana panel type, since some widgets have no direct equivalent and need a different visualization.
- Notebooks and SLO definitions: Confirm with your team whether these are in use and how they would be recreated, because their export options may be limited.
- Vendor export limits: Check with Datadog what can be exported and in which format before you commit to a conversion approach.
Consolidating from another Grafana instance is mostly about preserving identity, structure and configuration, not rewriting queries. Expect these tasks to change:
- Folders and permissions: Carry folder structure and permission assignments across, and confirm that team and user references resolve in the target identity setup.
- Provisioning and data source UIDs: Check whether data source UIDs are kept in the target, because dashboards and alerts that reference them break when the UIDs change.
- Plugin versions: Inventory every plugin on the source, confirm which versions the target release supports, and replace any that are no longer compatible.
- Target release: Choose the target release against the upgrade guidance so the consolidated instance is on a supported minor release.
- Alert state: Confirm how alert rules and contact points move, and avoid running the same rules on both instances during cutover.
Moving the configuration database from SQLite to MySQL 8.0 or later, or PostgreSQL 12 or later, is required before running production or high availability. Expect these tasks to change:
- Migration tooling: Confirm which export and import method your Grafana version supports for the target database, and test it on a copy before the production move.
- Downtime window: Plan a window in which Grafana is stopped for a consistent copy, and ask your team to size it from a test run rather than an estimate.
- Connection and sizing: Provision the database with backups and access controls set before the cutover, since the database becomes the single source of configuration.
- Verification: Compare dashboard, user, folder and alert counts before and after, and sign in as several test users to confirm permissions.
- Rollback: Keep the SQLite file untouched so you can restore the previous state if verification fails.
Deployment model changes how the migration is delivered, even when the content is the same. Expect these tasks to change:
- Helm or Docker deployment: Choose between the Helm chart and Docker images for Kubernetes, and set persistence, database and secret configuration in values files kept under version control.
- Offline packages: In air-gapped networks, mirror the required container images, Helm charts, operating system packages and plugins into your internal registry before the build starts.
- Plugin handling: Confirm which plugins can be installed offline, pin their versions, and record their checksums for review.
- Network paths: Confirm that data sources, identity providers and notification endpoints are reachable from the cluster or isolated network.
- Upgrade path: Plan how future images and plugins will reach the isolated network, because every update follows the same mirror process.
What you need to provide
The migration cannot be scoped until you hand over an inventory of what exists today. Provide read access or exports from each source platform: Kibana saved objects and Lens or visualization definitions, Datadog dashboards, monitors and notebooks through an API key with read scope, or the JSON of each existing Grafana instance. Pair that with a data source list that names every system a dashboard or alert reads from, the owner of each one, and the connection details needed to rebuild it in the new Grafana, such as hostnames, ports, database names and the authentication method. Confirm early which of these platforms keeps data in a store Grafana can reach at all.
A usage view is what separates a clean migration from a long one. Ask for a list of dashboards and alerts with recent view counts, last-modified dates and the teams that use them, so unused or duplicated items can be retired rather than rebuilt. For alerts, name a business owner for each alert family who can confirm the threshold, the notification route and whether the alert still matters. Also provide the identity model: the group names that should map to Grafana teams and folder roles, and the users who need admin rights on the new instance.
Name the target environment and database service before design begins. Specify where Grafana will run, whether on virtual machines, Kubernetes or Docker, and which MySQL 8.0 or later or PostgreSQL 12 or later service will hold its configuration. Decide who owns that database choice and who signs off the rollback criteria, meaning the conditions under which you return to the old platform. Provide an on-call contact list for the cutover window and a change calendar that shows freeze periods, so the team knows when a switch is permitted.
Credentials must go through your secret handling, such as a vault, the cloud secret manager or an approved password tool, and never through email, chat tickets or shared documents. Agree on that channel in the kickoff. Confirm with your security team how that channel will deliver database passwords, data source tokens and API keys to the implementation team, and who can revoke them after cutover.
Frequently asked questions
What drives the cost of a Grafana migration and how is a quote built?
The cost depends mainly on how many dashboards, alert rules and data sources are in scope and how much of each query must be rebuilt for the new data sources. A written quote follows from a scoped inventory of the source platform, including its dashboards, alerts, users and integrations. The main components are discovery, query and panel rebuilding, alert rule translation, database and infrastructure setup, identity integration, testing, parallel running and cutover support. Most of this is one-time project effort, while the infrastructure you run and any retained support recur. Ask each provider to itemize these components, state their assumptions about source exports and data sources, and list what you must supply.
How long does a Grafana migration take, and what sets the timeline?
No duration is given here, because the schedule depends on the size of your source platform and the environment it runs in. The main drivers are the number of dashboards and alerts to rebuild, how many distinct data sources must be connected, whether a production MySQL or PostgreSQL database must be provisioned, how many identity and notification integrations need work, and how many approval cycles your business requires before cutover. The length of parallel running and the availability of your data owners also set the end date. Ask for a milestone plan in the written scope that shows these dependencies and the client decisions each phase needs.
Can our team run a Grafana migration in-house, and what skills are needed?
Many teams can do this in-house if they have the time and the right skills, but the work is more than a server install. You need people who understand the source platform's query language and alert logic, who can write queries for Grafana data sources such as Prometheus, Loki or SQL databases, who can operate Linux servers, load balancers and a relational database, and who can manage Grafana provisioning and identity. Someone must own alert routing and sign-off. You will need to provide a source inventory, access to the source platform and data sources, a target environment, named owners for each dashboard group and agreed test windows. A fixed-scope partner can take over parts of this work.
Do Kibana and Datadog dashboards and alerts convert to Grafana automatically?
Conversion is partial, and the answer depends on the source product, its version and the export formats it offers. Tooling and export formats must be confirmed for each source before planning. Most queries are rebuilt, because Kibana and Datadog queries target different data models and must be rewritten against the data sources Grafana connects to. Alert rules usually need translation into Grafana Alerting, with new contact points and notification policies. During scoping, ask the provider to convert a representative set of dashboards and alerts so you can measure the rebuild effort before committing to a fixed scope.
Why must SQLite be replaced with MySQL or PostgreSQL for production Grafana?
Grafana's installation documentation says SQLite does not scale for production, and high availability requires a shared database. Grafana supports MySQL 8.0 or later and PostgreSQL 12 or later for its configuration store. The migration moves the stored configuration, including dashboards, users, folders and data source settings, into the new database. The work includes provisioning the database with backups and tested restores, setting the connection in Grafana configuration, running a test import in a non-production environment, and checking that users, permissions and alert rules match the source after the move. Plan a maintenance window for the final switch.
How do you avoid duplicate alerts and recover if cutover fails?
During parallel running, only one system should send notifications for each alert rule. A common approach keeps the source platform as the sole notifier while Grafana evaluates the same rules against test contact points, then compares results before routing is switched. Grafana's high availability documentation notes that alerting needs additional configuration to avoid duplicate notifications, so that setup must be tested in your environment before go-live. For a failed cutover, the plan should define rollback criteria, keep the source platform running until sign-off, retain a verified backup of the Grafana database and provisioning files, and name a single decision owner. Write these steps into the scope before work starts.
How DeployOpen delivers Grafana migrations
DeployOpen moves dashboards, alerts and data source connections from Kibana, Datadog or another Grafana into a self-hosted Grafana you run in infrastructure you control. The work follows a written scope, rebuilds each query against its new data source, and ends with a documented cutover and handover.
How we scope
- Inventory every dashboard, alert rule, data source and user group in the source system before any build starts.
- Map each Kibana, Datadog or Grafana query to the data source that will serve it in your Grafana, and record gaps.
- Agree the written scope, deliverables and timeline in advance; engagements are fixed-scope, with ongoing support available as a retainer.
How we build
- Rebuild queries for your data sources and convert alert rules into Grafana Alerting contact points and notification policies.
- Choose the configuration database for production, with MySQL or PostgreSQL in place of the SQLite default, and document the reasoning.
- Define data sources, dashboards and alerting resources as provisioning files so the migrated configuration can be reviewed and reproduced.
How we hand over
- Test each migrated dashboard and alert against the source system's output, and record every difference you approve.
- Run a planned cutover with a rollback path, parallel running period and a named owner for each dashboard and alert.
- Deliver written documentation covering the architecture, provisioning layout, migration decisions and operating runbooks.
How we support
- Offer ongoing support, upgrades and patch handling as a retainer that follows Grafana's release and support windows.
- Plan high availability and alerting deduplication where more than one Grafana server will serve users.
- Confirm with your team the owners for data sources, alert routing and access reviews once the migration closes.
