Why teams consolidate several Grafana servers into one
Consolidating several team-owned Grafana servers into one managed instance is feasible on documented paths, and the effort depends on how much must be carried over: the number of organizations, data sources, alert rules and identity mappings. Teams usually start this work when separate servers have drifted apart, with different Grafana versions, different plugins, duplicated data source definitions, and users who hold different roles on each server. Each drift point adds a reconciliation step, so the first task is an inventory of every server's version, plugin set, data sources, alert rules and sign-in method, which shows which differences are real requirements and which are leftovers.
The target platform matters before any dashboard moves. Grafana stores configuration in SQLite by default, but the installation docs state that SQLite does not scale for production, so the consolidated instance should run on MySQL 8.0 or later or PostgreSQL 12 or later. Confirm the supported database versions against the current installation documentation before you choose a platform, and plan the target as a high availability pair only if your uptime requirements call for it, since alerting then needs extra configuration to avoid duplicate notifications. Pick the target version with the upgrade guidance in mind as well, because a consolidated instance will inherit whichever release you install first.
Identity mapping is where consolidation most often stalls. Team sync, SCIM provisioning and SAML are available only in Grafana Enterprise and Grafana Cloud according to the authentication docs, so confirm which of these your organization needs before you design the user and team model. Open source editions can still sign users in through the supported OAuth and LDAP options, but team membership may have to be maintained through another process. Decide early whether each team becomes an organization, a folder with permissions, or both, because that choice determines how dashboards, data sources and alert rules are moved and who can change them afterward.
What maps cleanly from separate servers and what does not
This table compares each capability on separate Grafana servers with its counterpart on one consolidated instance. Read the right-hand columns as the work each item creates during the merge, and treat anything marked as manual rework as a line item to plan for. The main takeaway is that dashboards and folders usually move with little friction, while identity, team membership and API credentials need deliberate decisions.
| Capability | Separate servers | One consolidated instance |
|---|---|---|
| Dashboards and folders | Each server holds its own folder tree and dashboard JSON | Recreate the tree as folders inside one organization, then re-import dashboard JSON with provisioning or the API |
| Organizations | Often unused, or one per server by default | Becomes an access boundary: data, dashboards and users in one organization are not visible to another |
| Folders and permissions | Access granted per server, often to whole teams | Folder and dashboard permissions do the separation work inside a single organization |
| Data sources | Defined locally on each server, sometimes with embedded credentials | Re-register once per organization, with credentials supplied through secrets rather than copied from old files |
| Teams and team sync | Teams created by hand on each server | Team sync from an identity provider requires Grafana Enterprise or Grafana Cloud, per the authentication docs; otherwise maintain teams manually |
| Local users | Accounts with passwords stored in each server's database | Map to identity provider accounts by login or email; local users with no match need manual review, owner confirmation or removal |
| Service account tokens and API keys | Legacy API keys tied to one server and organization | Keys do not transfer; create new service accounts and tokens and update each script or pipeline |
| Alert rules and contact points | Defined per server, with local notification channels | Review each rule for duplicate names, folder placement and contact point targets before enabling on the new instance |
Choosing between organizations, folders and separate instances
Keeping each former server as its own Grafana organization preserves the boundaries your teams already have. Each organization gets its own users, teams, dashboards, data sources and alert rules, so a team's objects stay out of sight of other teams unless someone grants access. The cost is cross-team visibility. A dashboard that two teams need has to be duplicated or shared through an additional mechanism, and an operator working across several teams must switch organizations to see everything.
- Dashboard sharing: Shared dashboards need to be copied or exported into each organization, which creates drift over time unless provisioning manages the copies.
- Data source visibility: Each organization needs its own copy of every data source connection, so credentials are configured once per organization.
- Alert ownership: Rules and contact points stay with the owning organization, which makes ownership clear but complicates routing of shared alerts.
- User management: Users who belong to several teams hold several memberships, and removing someone from one team means changing each organization separately.
- Operator effort: Platform staff manage many organizations, each with its own settings and administrators.
Confirm with each team whether it needs a fully separate boundary or only ownership of its own objects, because the answer decides whether this option is needed at all.
Placing all teams in one organization and separating ownership with folders keeps dashboards and alert rules in a single place. Folder permissions decide who can view or edit each group of dashboards, and teams can be granted access to specific folders. Shared data sources live once, which reduces duplicated configuration. The trade-off is that folder permissions must be designed carefully, because anything an organization-wide role can read may be visible to everyone with that role, and data source visibility is less granular than a separate organization gives.
- Dashboard sharing: Shared dashboards sit in a common folder that all relevant teams can read, so there is one copy to maintain.
- Data source visibility: Data sources are organization-wide objects, so anyone who can query a data source can usually reach it from any dashboard they can edit.
- Alert ownership: Alert rules inherit permissions from their folder, so each team can own rules in its own folder while notification routing remains central.
- Role design: Basic roles such as Viewer and Editor apply across the whole organization, so folder permissions should be combined with restricted roles.
- Migration effort: Moving dashboards and folders into one structure requires a mapping of old owners to new folder paths before the import starts.
Check which data sources contain sensitive or regulated data, since those are the cases where organization-wide visibility is hardest to justify.
Keeping a small number of separate Grafana instances is the choice when isolation must be enforced by the platform rather than by configuration inside one system. Each instance has its own database, users, plugins and upgrade cycle, so a failure, misconfiguration or compromise in one stays contained. The cost is operational: every instance needs its own patching, backups, high availability design, authentication setup and monitoring, and each one has to be upgraded on the support schedule Grafana publishes.
- Hard isolation: Network, identity and database boundaries separate the instances, which suits data that must not be co-located with other teams' data.
- Data source visibility: Each instance only lists the data sources it was configured with, so unrelated sources are not visible at all.
- Alert ownership: Each instance runs its own alerting, which keeps alert state and notifications isolated but duplicates routing configuration.
- Recurring cost: Each additional instance adds recurring work for upgrades, certificates, backups and access reviews.
- Compliance evidence: Separate instances produce separate access records, which can simplify evidence for scoped reviews but multiplies the evidence to collect.
Identify which regulatory or contractual boundaries require separation before deciding how many instances to keep.
The right structure depends on who must see what, who must change what, and who must be able to stop an alert. Start by listing the access rules each former server enforced, then test each option against them. Organizations work well when teams rarely share objects. Folders work well when teams share data sources and cross-team dashboards. Separate instances work well when isolation must hold even if configuration is wrong. Many environments combine them, for example one organization for general engineering plus a separate instance for a restricted data set.
- Shared dashboards: Count how many dashboards are read by more than one team, since frequent sharing favors folders.
- Data source sensitivity: Identify sources whose visibility must be limited to a named group, since this often decides between folders and separate instances.
- Alert ownership: Confirm who receives and acknowledges notifications for each rule, and whether that group matches the folder owner.
- Identity mapping: Check how users and teams are authenticated today, because the chosen option affects how teams are mapped during migration. Enterprise identity features such as team sync are covered by the Grafana authentication documentation.
- Operational capacity: Confirm who will run upgrades and backups for each instance you keep.
Document the decision per team in writing before any import, so the migration plan and the access review use the same boundaries.
Documented paths for moving dashboards and data sources
Consolidation comes down to three ways of getting data sources and dashboards from the old servers into one managed instance: exporting JSON, loading files at startup, or managing resources as code. Each path changes who owns the definitions after the move, so the choice should be made before the first dashboard is copied.
Exporting dashboards as JSON
Dashboards can be exported as JSON through the UI or the HTTP API, and the file becomes the portable copy you import into the target. Check that each export includes the data source references, folder placement and variables the dashboard needs, because exports from one server often point at data source UIDs that do not exist on the next. Confirm export behavior for each dashboard type, including library panels and dashboards built with plugins, in the Grafana version you run. Keep a record of which source server each JSON file came from.
Provisioning directories at startup
Grafana's provisioning feature loads data sources, dashboards, plugins and alerting resources from YAML or JSON files when the server starts. A dashboard provider points at a directory, and Grafana reads every JSON file in it, so the target needs a predictable folder layout. Provisioned data sources and dashboards are marked as managed, which means edits made in the UI are not the source of truth and will be overwritten on the next load. Plan the directory structure per team before you copy files in.
Keeping provisioned files in a repository
Because provisioned resources are managed from files, the target instance must hold those files in a version-controlled repository that the team can review and roll back. Store one directory per organization or team, define who approves changes, and decide how the repository reaches the server. Without this step, the consolidated instance drifts from its files and the next restart or redeploy can revert work. Put secrets for data sources in environment variables or a secrets store rather than in the committed files.
As-code options: Terraform and Git Sync
The provisioning docs point to further as-code options, including Terraform and Git Sync. Terraform suits teams that already manage infrastructure this way and want data sources, folders and dashboards reviewed alongside other changes. Git Sync keeps dashboards in a repository and syncs them to Grafana, which fits teams that edit dashboards and want commits to record the history. Confirm which resource types each option supports in your version, and whether it runs against an Enterprise or Cloud feature set, before you commit to one.
Choosing between files and the API
The HTTP API can create and update dashboards and data sources directly, which is useful for one-off moves and scripted batches. Scripts that call the API leave no reviewable file history unless you store the payloads yourself, and they can conflict with provisioned resources on the same server. A common split is provisioning for shared, team-owned definitions and API scripts for a bounded migration. Ask the team to write down which path owns each resource type before the cutover starts.
Testing each moved dashboard
An imported dashboard can look correct and still show no data, because a data source UID, datasource variable or query parameter did not carry over. Compare each dashboard against the original on a sample time range, and check panels that use template variables, annotations and alert links. Record the test results per dashboard so a team can sign off its own content. Confirm export and import behavior for any dashboard type that uses plugins that are no longer maintained, since the target may not render it the same way.
Sequence from inventory to retirement with a parallel run
This sequence moves each team's Grafana content into one managed instance without losing dashboards, access or alert behavior. A parallel run and a documented cutover let the owners confirm the new instance before the old servers are retired.
Inventory servers, plugins, dashboards and identities
List every Grafana server in scope, including its version, database backend, installed plugins, provisioning files, data sources, alert rules, contact points and the users, teams and service accounts that sign in. Record which dashboards depend on Angular plugins or legacy alerting, since those need work before the move. The step is done when each server has a written inventory signed off by its owning team, and every dashboard and data source has a named owner.
Design organizations, folders and access model
Decide which team content maps to a separate organization and which maps to a folder inside a shared organization, based on how permissions, data source visibility and alert routing need to behave. Write the folder naming, permission roles and the rule for who can edit shared content. The step is done when the target layout is documented and each team lead has agreed to it in writing.
Pilot the move with one team
Choose one team with a moderate number of dashboards and data sources, then move its content into the target layout using provisioning files or the Grafana API, depending on how the content is managed. Run the same checks on the pilot that you will run later, and record every manual fix. The step is done when the pilot team confirms its dashboards load, its queries return data and the migration steps are written down as a repeatable procedure.
Map users, teams and authentication
Map each source user and team to an identity in the consolidated instance, and confirm which sign-in method applies. Team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so confirm your edition before relying on them. The step is done when every user group has a mapped team, and an access test shows each person sees only the folders and data sources they should.
Run both systems in parallel
Migrate the remaining teams in waves while the old servers keep running. Compare each migrated dashboard on both systems against the same time range, and confirm that alert rules evaluate and notify the same recipients on each side, with duplicate notifications suppressed during the overlap. The step is done when the owners of each migrated dashboard sign off on matching output for an agreed period.
Verify counts, data sources and alert firing
Run the verification checks before cutover: compare dashboard and folder counts against the inventory, test each data source connection for health, and fire a controlled test alert through each contact point to confirm delivery. Check that provisioned resources are not overwritten by UI edits. The step is done when every count matches, every data source reports healthy and each test notification arrives at its intended recipient.
Cut over links and freeze old servers
Announce a cutover window, freeze edits on the old servers so no new dashboards or alert rules are created there, and update DNS records, bookmarks, embedded links and automation endpoints to point to the consolidated instance. Confirm that OAuth callback URLs and root_url settings match the new address. The step is done when the old servers show no further edits, and a spot check of links from each team lands on the correct content.
Decommission old servers with retained backups
After the agreed post-cutover period, take a final backup of each old server, including its database, provisioning directories and configuration, and store it under your retention policy. Then stop the services, revoke remaining credentials and remove the old DNS entries. The step is done when the retained backups are verified as restorable and the decommissioning record is signed by the platform owner.
Mapping users, teams and permissions without losing ownership
Map users from each local Grafana database to one identity provider before any dashboard moves, because the consolidated instance should authenticate people once and assign them roles by team. Export the user list from every source server and match accounts on a stable attribute such as the verified work email, not the login name, since the same person often has different usernames on different servers. Decide in advance which account wins when one person has several local logins, and record each merge in a spreadsheet that the team can review. Grafana's authentication options in every edition include LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT, so confirm which of these your identity provider supports before you design the mapping. Also confirm that every migrated user signs in once through the new provider so the account is linked, and plan how service accounts used by scripts are handled separately.
Team membership needs a clear rule by edition. Team sync, which copies group membership from the identity provider into Grafana teams, is listed in the authentication docs as available only in Grafana Enterprise and Grafana Cloud, so open-source deployments must maintain teams by hand or through provisioning. Ask whether your organization already holds an Enterprise or Cloud subscription before you design around team sync, and do not assume a feature is present because your identity provider supports it. SAML, active sync and SCIM provisioning follow the same edition rule, so an open-source plan that depends on any of them needs a different approach or a licensing decision first. Rebuild the old owners of each dashboard and folder as explicit team permissions, and check that the consolidated folders still give each team the level of access it had on its old server.
Dashboard ownership is easy to lose during a merge because the original creator often leaves the team, and folder permissions set on the old server do not carry over automatically. Before the move, list every folder with its permission entries and every dashboard with its last editor, then decide who will own each item after consolidation. Preserve folder structure by giving each former server its own top-level folder, and grant the matching team Edit rights only inside that folder. Test the result with a sample user from each team who has the lowest role they need, and confirm they can see their dashboards but not those of other teams. Treat any role or permission that cannot be reproduced as an open risk for the owning team to accept in writing, and record the final mapping as part of the migration evidence.
Questions about alert rules and data source credentials
Do alert rules move automatically when I move dashboards to a consolidated Grafana?
No. Dashboards and alert rules are separate objects, and moving a dashboard does not carry its alerting with it. Grafana-managed alert rules live in the instance that evaluates them, so each rule has to be exported or recreated in the consolidated instance and placed in the right folder and organization. Rules that depend on a data source must point at the migrated data source with the same UID or an updated reference. Plan to inventory every rule on the old servers, record its owner, evaluation group and labels, and confirm the copy evaluates correctly before the old rule is disabled. Rules built on data source-managed alerting need a separate conversion path, which the sibling guides on importing Prometheus, Mimir and Loki rules describe.
How are notification channels and contact points rebuilt after consolidation?
Contact points and notification policies are not copied for you in a merge, so they are rebuilt as part of the migration. Each old server's notification channels are listed with their type, target, and secrets such as webhook URLs, tokens and SMTP credentials. In the consolidated instance you create contact points for each team, then define a notification policy tree that routes alerts by label to the right team. Secrets must be re-entered or supplied through provisioning files or environment-based settings, and the team that owns each destination should confirm it still receives test notifications. Ask whether any team relied on a legacy channel type that no longer maps cleanly, since those need a replacement before cutover.
How do data source credentials get re-entered or encrypted in the new instance?
Credentials are stored with the data source configuration, and Grafana encrypts secure fields with a secret key that belongs to the instance. An export of a data source does not contain usable passwords or tokens, so each one must be supplied again in the consolidated instance. Teams usually keep these values in a secrets store and feed them through provisioning files or environment variables, which keeps them out of version control. Confirm with the database and data source owners which accounts are dedicated to Grafana, whether they have least-privilege read access, and how rotation will work. Record the new data source UIDs, because dashboards and alert rules reference them. Encryption of stored secrets should be checked after the move by testing each data source, not assumed.
How do I avoid duplicate alert notifications while the old and new servers run in parallel?
Run the old and new alert rules side by side only if the old servers' notifications are switched off or routed to a non-paging destination during the overlap. If both instances evaluate the same rule against the same data and send to the same contact point, each team receives two pages. A practical approach is to keep the new rules in a paused or test-only contact point, compare their state history with the old rules for an agreed period, and then move the paging routes in one planned change. Assign one owner to the cutover decision, and write down which instance is authoritative for each rule group at each stage. Silences created on the old server do not carry over, so review active silences before the switch.
Does high availability alerting need extra configuration in a consolidated instance?
Yes. Grafana high availability uses two or more active-active Grafana servers behind a load balancer that share a MySQL or PostgreSQL database, but the Grafana documentation notes that alerting needs additional configuration to avoid duplicate notifications. Each node can evaluate rules, so without coordination the same alert may be sent more than once. Engineers should review the alerting high availability settings in the official high availability guide and test failover with a controlled alert before relying on the instance for paging. The consolidated design should also decide whether alerts are handled inside Grafana, sent to an external Alertmanager, or split by team, because that choice changes the configuration work.
Can our own team handle alert and credential migration without a partner?
Often yes, if the team has someone who understands the existing alert rules, owns the data source accounts and can run a parallel test. The work is mostly inventory, mapping and verification rather than heavy engineering, so the effort depends on how many rules, contact points and data sources exist and how many teams depend on them. A partner is most useful when the number of instances is large, when alert routing is complex, or when the team lacks time to run the cutover safely. Ask any provider for a written scope that lists the rule inventory, contact point rebuild, credential handling and parallel-run checks as separate deliverables, so each cost driver is visible in the quote.
What do I need to ask for in a quote covering alerts and credentials?
Ask the provider to state which alert rules, contact points, notification policies, silences and data sources are in scope, and how each will be inventoried and verified. The quote should name who handles credential re-entry and how secrets are stored and transferred, and whether the parallel run and cutover are included. Confirm which items are one-time work, such as the migration itself, and which recur, such as retainers for upgrades or ongoing alert tuning. Ask how high availability alerting is configured and tested, and whether rollback steps for alert routing are part of the plan. Fixed-scope engagements are agreed in writing before work starts, so unclear items should be resolved before signing.
What usually goes wrong during consolidation
Consolidating team-owned Grafana servers fails less often on the technical move than on ownership, identity and the period when old and new instances run side by side. The cards below cover the risks that recur most and the preventive step to take before each one turns into an incident.
Duplicate dashboard and folder names
Two teams often build a dashboard called Service overview or a folder called Production, and a straight import then overwrites one with the other or creates confusing near-duplicates. Before importing, export every source instance's folder tree and dashboard titles into one inventory, then decide per name whether to merge, rename or keep the dashboard in a separate folder. Record the UID mapping so links and provisioned references still resolve after the move.
Lost dashboard ownership
Dashboards on the old servers usually have an owner in practice, a team lead who knows what the panels mean, but that knowledge rarely survives the move. Once dashboards land in a shared instance without an owning team, nobody updates thresholds or queries when systems change. Assign each folder a named owning team and an approver before cutover, and make that assignment part of the migration sign-off.
Duplicate alert notifications during parallel run
While both the old and new servers evaluate the same rules, on-call engineers receive two pages for one incident, and some teams start silencing alerts that are actually needed. Decide one evaluation source for each alert rule and disable evaluation on the retiring side before enabling the new contact points. The Grafana high availability docs also note that alerting needs extra configuration to avoid duplicate notifications, so test routing with a known-safe alert first.
Credentials that cannot be exported
Data source passwords, API tokens and OAuth client secrets are often stored encrypted in the source database or are not returned by the API at all, so the values have to be re-entered or fetched from a secret store. Teams discover this during cutover when panels show authentication errors. Inventory every data source and its credential owner first, and plan to supply secrets through the new instance's secret handling rather than copying the database file.
Plugin version drift
Each old server may run different plugin versions, and a dashboard that renders correctly on one can break on another once merged onto a single instance. Compare plugin lists and versions across all sources, pin the versions the consolidated instance will run, and retest the dashboards that depend on them. Confirm plugin compatibility with the target Grafana version before the migration window, not after.
Old servers left running with write access
A retired server that still accepts logins, runs alert evaluation or has a data source with write permission can recreate dashboards, change rules or send notifications after the team believes the migration finished. This is also a control gap for auditors who ask who can change monitoring configuration. Set a dated read-only freeze, revoke user and service accounts, disable schedulers and remove network paths before decommissioning, and keep a final export as the record.
What drives the effort and cost of consolidation
This table lists the cost components of merging Grafana servers and the drivers that raise or lower effort for each. Read each row as a question to answer before accepting a quote, since most of the variance comes from inventory size, identity design and how long the old servers must run in parallel.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Number of source servers | Each server needs its own inventory, backup, export and sign-off, and overlapping setups multiply reconciliation work. | A per-server inventory with version, database type and owning team, plus the set of servers in scope. |
| Dashboards and folders | Large dashboard counts raise review effort, and nested folders or duplicate titles must be mapped to organizations or folder structures. | A count of dashboards by source server, the target folder model, and how duplicates and broken panels are handled. |
| Data sources | Each data source needs its URL, credentials, UID and permissions rebuilt in the target, and secrets must move through a secure channel. | A list of data sources with type, plugin version and how credentials are supplied and rotated. |
| Users, teams and identity | Mapping accounts that exist in several servers, merging teams and aligning roles is often the slowest step, and team sync depends on edition. | Confirmation of the identity provider, the mapping rules for duplicate users, and whether team sync is in scope. |
| Alert rules and notification channels | Alert rules, contact points and silences must be recreated or converted, and duplicate notifications must be prevented while both instances run. | A count of alert rules and contact points, the conversion method, and the cutover test for each rule. |
| Plugin count and type | Unsigned, Angular-dependent or community plugins need compatibility checks and may block a target version. | A plugin inventory with versions, signature status and a decision for each plugin. |
| Edition and feature needs | Requirements such as SAML, SCIM or team sync can point toward Grafana Enterprise, which changes licensing and the identity design. | A written statement of required features and the edition each one assumes. |
| Parallel run and cutover | Keeping old servers read-only or running in parallel adds monitoring, sync checks and a rollback window. | The length of the parallel period, the verification steps and the rollback plan. |
| Compliance evidence | Change records, access reviews and retention of the old servers' audit trails must be kept for assessors. | The evidence list the partner will produce, and who keeps the retired servers' logs and for how long. |
Keeping evidence of access and ownership through the move
Consolidation changes who can see and change operational data, so the records of access decisions, dashboard and data source ownership, and retired servers matter as much as the migrated content. Before the first dashboard moves, decide what evidence your internal control and third-party oversight reviews will ask for, and capture it while the old instances still exist. Useful records include the mapping of each legacy user and team to a new organization, folder or role, the approver for each mapping, the provisioning files or API change history that created the new objects, and the date each old server was disabled and its data disposed of. Where the target uses Grafana Enterprise or Grafana Cloud, team sync and SCIM provisioning can also reduce the manual steps, but the reader should confirm with their identity team which provisioning source is authoritative and keep that decision in writing.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. The first step is to confirm with your auditor which framework applies, which control areas they will test (for example, access management and change management for the Grafana platform), and what sample period and format they expect. Some frameworks also reach third-party service providers, so a consolidation that involves an outside partner may need to be reflected in your vendor register and oversight records. Ask the auditor how they want those records retained and whether exported provisioning files, change logs and approval tickets are acceptable as primary evidence.
Plan the retirement of each old instance as a controlled change rather than a clean-up task. Export and archive the final state of dashboards, data sources and users, record who approved shutdown, and confirm that no alert rules, contact points or scripted API calls still point at the old URL. Keep the old database snapshot under the same retention rule as other operational records until the auditor and your data protection owner agree it can be deleted. Treat any personal data in user profiles or audit entries as subject to your retention policy, and check how long the copies of those records remain in backups. Confirm these steps with your compliance lead before the cutover window is scheduled, so the evidence is collected as the work happens.
Common questions before consolidating Grafana instances
How much effort and cost should we expect to consolidate Grafana instances?
Effort depends mostly on how many servers you are merging, how many dashboards, data sources, folders and alert rules each one holds, and how much of the content is unowned or duplicated. No public price applies to this work, and DeployOpen does not publish one. Cost has two parts: a one-time consolidation project (inventory, target design, migration scripts, validation and retirement) and recurring costs for running the single instance afterward, such as hosting, database, upgrades and support. Ask for a quote built from a written scope that lists the instances, the object counts you have measured, and whether alerting and user mapping are included. Also confirm which Grafana edition you run, because team sync and SAML are limited to Grafana Enterprise and Grafana Cloud according to the Grafana authentication docs.
How long does it take to merge several Grafana servers into one?
Duration is driven by inventory quality, the number of teams that must sign off on their content, and how many objects need manual review rather than scripted movement. Teams usually lose the most time to ownership questions and to alert rules that depend on data sources being rewired, not to the copy itself. Build the timeline around phases: inventory, target design, a pilot team, the remaining teams in waves, then a parallel run and retirement. Ask any provider for phase-by-phase dates in the written scope, with the team dependencies named, and treat any single number without a measured inventory as an estimate to be confirmed.
What does our team need to provide before consolidation starts?
You need to supply the access and decisions that only your organization can make. Typical inputs are:
- Admin access to each source Grafana and to the target, plus the database credentials if you plan a database-level copy.
- An export or inventory of dashboards, folders, data sources, alert rules, contact points and service accounts.
- A named owner for each team's content and a decision on which content to retire.
- The identity provider configuration, group names and the role each team should hold in the target.
- Change windows, a rollback plan and the list of systems that embed or link to the old dashboard URLs.
If you operate under a framework such as DORA or NIS2, also confirm whether the instances appear in your ICT service register or inventory before anything is moved.
Can we do the Grafana consolidation ourselves with our own team?
Yes, many teams do this internally, especially when the number of instances is small and the platform team already runs Grafana. The work is manageable when you can export dashboards and data sources through provisioning files or the HTTP API, reconcile folders, and test alert routing. It gets harder when several teams use conflicting names, when alert rules must be re-pointed, or when the team lacks time to validate results. Compare the internal effort with the cost of a fixed-scope engagement, which DeployOpen agrees in writing before work starts. Whichever route you choose, assign one owner for the target design and one for verification.
Can dashboards be moved to the new instance without rebuilding them?
In most cases, yes, because Grafana dashboards are stored as JSON and can be exported and imported through the API or provisioning. The exceptions are the items that do not travel with the JSON: data source references that use a UID that differs in the target, folder permissions, library panels, plugin versions that the target does not have, and dashboards that depend on AngularJS plugins. Check the UIDs and plugin dependencies during the inventory, because those drive whether a dashboard moves cleanly or needs edits. Ask the reader to confirm each exception against their own dashboard set rather than assuming a clean copy.
How do we verify that nothing was lost during the move?
Verification compares what existed before with what exists after, object by object. Build a checklist from the inventory and check for each team:
- Dashboard count, folder structure and JSON content, with UIDs confirmed.
- Data sources reachable and returning the same query results on sampled panels.
- Alert rules present, enabled, evaluating and routed to the right contact points.
- Users, teams and role assignments matched against the identity provider.
- Links, embeds and API clients updated or redirected.
Run both instances side by side for a period agreed with the owners, and record sign-off per team before any old server is switched off. Keep backups of each source instance until the sign-off is complete, and note that the database backup approach depends on your chosen database.
What risks come with retiring the old Grafana servers?
The main risks are losing alert delivery, breaking links that teams rely on, and removing data that someone still needs. Old servers often send alerts that nobody remembers, so list every active alert rule and notification path before shutdown. Access records and audit history may also be needed for compliance evidence, so decide how long to keep the source databases and backups. Where personal data from EU sources is involved, the GDPR records of processing and any transfer tool should reflect the new location. Confirm the retention period and the owner of the archive in writing before you retire anything.
How DeployOpen scopes and delivers a Grafana consolidation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Grafana consolidation is scoped, built and handed over in your cloud accounts, data centers or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory each team-owned Grafana server, its version, database, plugins, data sources and alert state before proposing a target design.
- The written scope names which organizations, folders, dashboards, data sources and users move, and which are retired or left in place.
- We ask you to confirm the identity provider, user mapping rules and who approves access for each team before quoting.
How we build
- We build the consolidated instance on MySQL or PostgreSQL, since SQLite is not suitable for production or high availability.
- Data sources, folders and dashboards are defined as provisioning files or migrated through the API, with each step recorded in version control.
- We test each migrated dashboard, data source and alert against the source instance, and document any differences found before cutover.
How we hand over
- You receive the design record, migration scripts, provisioning files, a mapping of old to new folders and teams, and the verification results.
- We document the retirement plan for the old servers, including how long they stay read-only and how backups are kept.
- Your team is walked through how to add a team, folder or data source to the consolidated instance under the new structure.
How we support
- Post-cutover fixes and questions can be covered under a support or maintenance retainer if you choose one.
- Retainers can also cover Grafana patch and minor upgrades, which Grafana documents as frequent releases requiring regular planning.
- Ongoing security testing of the consolidated instance is available as a separate engagement, scoped in writing.
