What a migration to Prometheus involves
A migration to Prometheus maps every existing check, threshold and alert route from the current system onto Prometheus scrape targets, exporters and PromQL alerting rules, then runs both systems side by side until the new alerts are trusted. The work is rarely a direct copy. A Nagios or Zabbix check that tests a process on a host usually becomes an exporter metric, a scrape job and a rule that fires on a symptom, and each of those steps needs an owner and a test.
Teams usually start a migration for a specific reason. Common triggers include a licensing change in the current product, a check-based polling model that no longer scales with the estate, a hosted monitoring bill that is hard to forecast as series counts grow, or a move to Kubernetes where targets appear and disappear constantly. Name the trigger first, because it decides what must be proven before cutover, such as whether a forecastable cost or dynamic service discovery is the outcome that counts.
In-house or partner? Teams with strong PromQL skills and experience writing or configuring exporters can often do the migration themselves, especially for a bounded estate. Teams that must keep paging continuous across a large estate usually benefit from an outside plan and strict parallel-run discipline, because gaps in alert coverage are the main risk. Ask any partner to show its inventory method and its exit criteria for the parallel run before agreeing on scope.
Prometheus has no paid enterprise edition, so the cost of migrating sits in the work and the people, not in a license. Expect one-time effort for inventory, rule rewrites, exporter work and dashboards, plus recurring effort for storage, upkeep and on-call. When requesting a quote, ask how many checks and alert routes are in scope, which exporters are new, and how the parallel run and cutover are measured.
What the migration work includes
A migration from Nagios, Zabbix, Graphite or a hosted service is delivered as a set of linked workstreams. Each one produces an artifact the team can review before the old system is switched off.
Source inventory of checks and hosts
We catalog every host, active and passive check, dashboard, and alert in the current system, with its owner, notification target, and how often the team actually looks at it. Unused or duplicate checks are flagged for retirement rather than carried over. Ask for the inventory format and the owner sign-off step before any mapping starts.
Check-to-exporter mapping sheet
Each legacy check is mapped to a Prometheus source: a node or application exporter, an SNMP exporter module, a Blackbox probe, or an application metric. The sheet records gaps where no equivalent exists, which usually need custom instrumentation. Confirm which exporters your platforms support and who maintains them.
Rewritten alerting and recording rules
Threshold alerts from the old system are rewritten as PromQL alerting rules, and expensive dashboard queries are moved into recording rules. Rules are reviewed for symptom-based paging and tested against historical metric shapes where data exists. Ask how rule changes are versioned and reviewed.
Alertmanager routing for notifications
Existing notification paths, such as email groups, chat channels, paging services and escalation schedules, are rebuilt as Alertmanager receivers and routing trees. The work covers grouping, inhibition and silences so that a single outage does not produce a flood of pages. Confirm the receiver endpoints and credentials your teams will need.
Dashboards rebuilt in Grafana
Dashboards are recreated in Grafana or the UI your team has chosen, using the new metric names and labels rather than copying old graph definitions. Panels that depended on Graphite functions are translated to PromQL and checked with the people who read them. Confirm early which dashboards must exist on day one.
Parallel-run comparison report
Both systems run side by side for an agreed period, and a report compares which alerts fired, when they fired, and who was notified. Differences are classified as expected, a rule defect, or a missing check. Ask how long the parallel run will last and who signs off on the results.
Cutover runbook with rollback
The runbook defines the order of cutover steps, the owner of each step, the go and no-go checks, and the rollback steps that re-enable the old notification paths. It is rehearsed before the production switch. Confirm the approval chain and the window your change process allows.
Decommissioning list for the old system
The decommissioning list names every server, agent, database, plugin, certificate, and scheduled job to retire, with a date and the evidence that it is no longer needed. It also covers archived data retention requirements. Ask whether your compliance obligations require keeping the old system read-only for a period.
Historical data and backfill
Historical data from Graphite or the old tool generally does not carry over one-to-one, because series names, units and sampling differ. Any backfill should be scoped as a separate decision that is confirmed against the source data format, the import method and the storage needed. Do not promise historical continuity until that check is complete.
What drives migration effort and how to keep it down
This table lists the migration drivers that change effort for a Prometheus move, why each one matters, and how to keep it manageable.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Monitored hosts and services | Each target needs a scrape job, labels and an exporter or agent, so inventory size sets much of the work. | Export the host and service inventory from Nagios or Zabbix, group targets by role, and migrate in waves. |
| Checks and alerts with custom logic | Nagios plugins with bespoke code and Zabbix triggers built on calculated items need analysis and rewriting as PromQL rules or exporters. | Classify each check as retire, replace or keep, and rebuild only alerts that page someone or feed a live process. |
| History and dashboard volume | Prometheus keeps local data for 15 days by default according to its storage docs, so older history needs a separate plan and dashboards must be rebuilt. | Decide which history must move to long-term storage, and rebuild only the dashboards teams still open each month. |
| SNMP and Blackbox exporter use | These exporters take targets from URL parameters, so anyone who can reach them can direct requests to arbitrary endpoints, adding access control work. | Restrict network access to exporter endpoints, define allowed modules and targets, and keep device classes in separate scrape jobs. |
| Teams and notification paths | Each team's escalation, on-call schedule and receiver must map to an Alertmanager route, and mistakes cause missed or duplicate pages. | Map the routing tree with team owners before writing rules, then define each receiver once and reuse it across routes. |
| Hosted service export limits | If the current service is hosted, its export rate limits, formats and retention windows set how much history and configuration can be moved. | Confirm export formats, rate limits and data retention in writing with the vendor before scoping the history move. |
| Parallel-run length set by change control | Your change control process decides how long both systems alert side by side, and that overlap doubles alert review and on-call effort. | Agree exit criteria for the parallel run early, and compare alert outcomes rule by rule so the overlap ends on evidence. |
| Compliance evidence needs | Assessors may expect records of monitoring coverage, alert changes and approvals, and the migration must produce that trail as it runs. | Keep rules and alert changes in version control with approvals, and record the coverage mapping as each wave completes. |
Migration phases and what each produces
The sequence moves every check and alert from the old system to Prometheus with a documented record at each stage, so nothing is retired before its replacement has been reviewed.
Inventory every check and alert
Export the current check, alert, escalation and contact configuration from the source system and assign an owner to each item. Work is done by your monitoring team with DeployOpen reviewing the export. The step closes with a register listing every check, its owner, its notification route and a decision to migrate, merge or retire it.
Classify checks by metric type
Sort each inventoried check as an exporter-backed host or service metric, a probe (blackbox-style reachability or response check), or an application metric that the team must instrument. Classification drives which exporters or instrumentation work is needed. The step closes with a classified register that lists the exporter or instrumentation task behind each entry.
Build the Prometheus tier
Configure scrape jobs, service discovery or static targets, TLS and authentication for scrapes, and Alertmanager with its routing placeholders. Set local retention to match the window you have chosen, noting that the default local retention is 15 days and any longer history needs a separate storage decision. Pin the Prometheus version to a supported minor release or the current LTS line at build time. The step closes when every target in the register shows as up and Alertmanager receives a test alert.
Rewrite alerts as PromQL rules
Translate each migrated alert into a PromQL alerting rule, with recording rules where they simplify repeated expressions. Test every rule against replayed history or live data, checking that it fires when it should and stays quiet otherwise. The step closes with a rule set and a test record showing the result for each alert.
Run both systems in parallel
Keep the old system active while Prometheus also notifies, so the same events reach both. Review each difference in timing, grouping, severity or missing coverage and record the decision for it. The step closes with a difference log in which every entry has an agreed resolution and a sign-off from the owning team.
Cut over notification routes team by team
Move each team's notification routes from the old system to Alertmanager one team at a time, confirming that its on-call receivers get the expected alerts. Retire the old routes for that team only after its check passes. The step closes with a cutover record per team showing the date, the routes moved and the confirmation from that team.
Decommission the old system with retained exports
Stop the old monitoring system once every team has cut over, and keep exports of its configuration, historical data and alert definitions under your retention policy. Confirm with your records owner which exports must be kept and for how long. The step closes with an archive manifest and a written confirmation that no live notifications depend on the old system.
What teams keep in-house and what they outsource
This table shows who usually owns each part of a migration to Prometheus, the skills each part needs, and where a partner tends to add the most value, so you can compare it with your own team's capacity.
| Work part | Usual owner | Skills required |
|---|---|---|
| Inventory and ownership sign-off | In-house | Knowledge of every legacy check, its owning team and its consumers, plus incident management experience to confirm which alerts people actually act on |
| Exporter and probe selection and build | Shared | Linux service operations, network knowledge for SNMP and Blackbox probes, and familiarity with exporter configuration and TLS |
| PromQL rule rewriting and testing | Often outsourced if the team lacks PromQL depth | PromQL fluency, promtool rule unit testing, and the ability to translate threshold checks into symptom-based expressions |
| Alertmanager routing and on-call design | In-house, because routing reflects team ownership | Incident management, escalation design, and knowledge of which teams own which services and on-call rotations |
| Dashboard rebuild | Shared | Grafana or equivalent dashboarding, PromQL for panel queries, and an understanding of what each operations audience needs to see |
| Parallel-run review and cutover sign-off | In-house, with partner support | Comparison of old and new alert histories, incident management, and authority to approve the switch from the legacy system |
| Decommissioning and evidence capture | Shared | Linux service operations, change management, and records retention practice so that retired monitoring and its approvals stay auditable |
What usually goes wrong and how to prevent it
These failure modes recur in Prometheus migrations, often after go-live when the old tool is switched off. Each card names the prevention step to build into the plan before cutover.
Alerts ported literally
Nagios checks often fire on a host state, such as a disk or process being down, and a direct translation pages on that cause. Rewrite each alert around a user-facing symptom, such as error ratio or request latency, and keep cause-based signals as tickets or dashboard panels. Review every rule with the team that owns the service before cutover.
Silent gaps from unmapped checks
Every Nagios check should appear in a mapping sheet with an exporter, a Prometheus rule, or a documented decision to drop it. Checks with no equivalent, such as custom plugin output or thresholds tuned to a single host, disappear quietly if nobody tracks them. Run a comparison of both systems during parallel operation and sign off each unmapped check by name.
Exporters and endpoints exposed too widely
Exporters can publish more labels and metrics than the team intends, including internal hostnames or identifiers. Exporters such as SNMP and Blackbox take targets from URL parameters, so anyone who can reach them can make them send requests to arbitrary endpoints. Restrict network access, enable TLS and authentication, and keep admin and lifecycle APIs disabled unless a specific need is documented.
Local storage treated as durable history
Prometheus keeps local data for 15 days by default, and its local storage is not clustered or replicated. Teams that expect the long history of their old tool, or a standby that takes over automatically, will find neither out of the box. Set retention to match audit and capacity needs, plan remote write to durable storage, and run redundant Prometheus instances with Alertmanager clustered.
Cutover without a rollback path
Switching paging to Prometheus in one step removes the fallback when a rule is wrong. Keep Nagios or Zabbix checks active and notifying during a parallel period, then move one service group at a time. Record the criteria for reverting each group and who may trigger the revert, and keep the old configuration in version control until retirement is agreed.
Billing counts moved into Prometheus
The Prometheus docs say it values reliability over precision and is not a good choice where 100% accuracy is required, such as per-request billing. Counters moved from a billing path can undercount during restarts, scrape gaps, or excluded targets. Keep authoritative billing records in a system built for exact counts, use Prometheus for operational trends, and confirm the accuracy requirement with finance before porting.
How the migration changes by starting point
Nagios checks are commands that return a state, so each check becomes either a scrape target or a probe, and its alert logic moves into PromQL rules.
- Host and service checks that read local state map to node_exporter or a dedicated exporter. Confirm that each plugin's output has a metric equivalent before you retire it.
- Reachability checks for HTTP, TCP or ICMP endpoints map to Blackbox probes, which take their target from URL parameters.
- Restrict access to the Blackbox exporter. The Prometheus security model warns that anyone with HTTP access to it can make it send requests to arbitrary endpoints.
- Escalations and acknowledgements have no direct equivalent. Plan them as Alertmanager routing and receiver configuration.
- Keep Nagios running until each check has a matching alert that has fired correctly in a test.
Zabbix templates bundle items, discovery rules and triggers, so the migration works template by template rather than host by host.
- Map each template to exporters by listing its items and triggers. Each trigger becomes an alerting rule, and each duration condition must be rewritten with an explicit evaluation window.
- Low-level discovery maps to Prometheus service discovery or file-based targets. Confirm coverage for every discovered object type, such as file systems, interfaces and database instances.
- Zabbix history stays in its own database. Prometheus does not import it, so keep that database readable for the retention period your auditors and incident teams need. Confirm in writing whether any backfill is in scope.
- Zabbix proxies that collect from remote sites need a planned equivalent, such as a Prometheus server per site with a central view.
- Zabbix actions, including notifications and escalations, move to Alertmanager. Test each route with a live notification before cutover.
Graphite metric paths are dot-separated strings, so the migration starts with a naming decision: which path segments become labels and which remain part of the metric name.
- Map path segments to labels. Choose a consistent label set, such as environment, service and host, and check that it matches how dashboards and alerts filter today.
- Retention differs. Graphite retention comes from its storage schemas and aggregation rules. Prometheus keeps local data for 15 days by default, so longer history needs remote write to an external long-term store.
- Historical data may not carry over. Ask the implementation partner for a written statement on whether backfill is in scope and in what format the history will arrive.
- Rewrite dashboards. Graphite functions have no direct PromQL equivalents in many cases, so list every function in use and rebuild each panel.
- Validate in parallel. Compare new series against Graphite values for the same window before retiring any path.
A hosted service adds three constraints that self-hosted sources do not: limits on export, vendor-specific agents and contract terms that govern the exit.
- Export limits. Confirm the rate, volume and query caps on the export interface before estimating how much history can move out. Ask whether export is included in the contract or charged separately.
- Vendor agents. Proprietary agents stop when the service is turned off. Replace each one with an exporter or an OpenTelemetry Collector, and check which metrics the agent collects that the replacement will not.
- Contract exit terms. Read the termination, data return and deletion clauses, and confirm the notice period. The notice period sets the latest date for a parallel run.
- Alert definitions are often stored in the vendor's interface. Export them through the vendor's API if it offers one; otherwise, rebuild each one as a PromQL rule and record the mapping.
- Keep the hosted service active until the parallel run has passed its acceptance checks, if the contract allows it.
Kubernetes-hosted targets change discovery, while restricted networks change how software, rules and notifications reach the environment.
- Use Kubernetes service discovery for pods and services, with labels or annotations that mark what should be scraped, so targets follow deployments without manual edits.
- Short-lived jobs may need the Pushgateway. Its series persist after the job exits, so set a cleanup step for stale series.
- Mirror everything internally. Copy container images, Helm charts, exporter binaries and rule packages into internal registries and repositories, and pin each version you deploy.
- Test rules offline. Alerting and recording rules cannot be checked against a public service. Build a test instance inside the network with sample data, and run the rule checks shipped with your Prometheus version before deployment.
- Scope probes and receivers. Blackbox probes reach only the zones you permit, and Alertmanager receivers must be reachable from inside the network. Confirm both during design.
What the client needs to provide
Most of the schedule is set by what the client supplies, not by Prometheus configuration. Before a migration starts, the team needs read access to the existing monitoring system's configuration and exports, including Nagios object files, Zabbix template and host exports, Graphite storage schemas and rules, or the hosted service's alert definitions and notification settings. Without these, the mapping of checks to exporters cannot begin, and the inventory of what is actually monitored stays guesswork.
Every alert and every notification route needs a named owner. Each alert that will be rewritten as a PromQL rule needs a person who can confirm its intent, its threshold and whether it still matters. Each receiver, escalation path and on-call rotation needs an owner who can approve the Alertmanager routing tree. Missing owners are the most common cause of delay in this work: rules sit in review, and teams cannot decide whether a noisy check should be retired or kept.
Ask for a list of the services and teams that depend on current alerts, plus network and firewall changes approved for scrapes and for SNMP or Blackbox targets. Blackbox and SNMP exporters take targets from URL parameters, so the client should also name a hosting location for those exporters and a secret store for SNMP community strings, bearer tokens and other credentials. Confirm the store with your security team before any configuration is written.
Agree a parallel-run window in writing, with a start and end date, the alerts that must match between the two systems, and who reviews the differences. Name the decision makers for cutover and for decommissioning the old system, including who signs off on retaining historical data. A cutover without these names usually stalls at the point where both systems fire, and the old system is never switched off.
Questions buyers ask before hiring outside help
What drives the cost of a Prometheus migration, and what should a quote include?
Cost follows the size of your monitoring estate and the number of alert rules that must be translated. Prometheus carries no license fee because it is Apache-2.0 licensed with no paid enterprise edition, so spend comes from implementation, infrastructure, storage and staff. One-time items include inventory, exporter and rule work, dashboards, testing, the parallel run and cutover. Recurring items after cutover include compute and disk, any long-term storage, upgrades and on-call coverage. Ask each quote to split these lines and to name who performs each one.
How long does a Prometheus migration take to complete?
No duration is given here, because the timeline depends on the scope agreed for your environment. The factors that set the schedule include the number of checks and hosts, how many Nagios, Zabbix, Graphite or hosted alert rules must be rewritten and validated, how many teams must approve dashboards and notifications, how long both systems run in parallel, and how change approvals work in your organization. Most engagements are fixed-scope, so the written scope states deliverables and timelines before work starts.
What does a Prometheus migration need from our internal team?
Your team supplies access, knowledge and decisions. Expect to provide exports or access to the current monitoring servers, named owners for critical services, change approval paths, network paths from Prometheus to its targets, and a place to run the new stack, such as cloud accounts, clusters or data center hosts. Service owners must confirm what each alert is for, which thresholds still matter and who should be paged. Someone must also accept the cutover criteria and sign off on dashboards. Confirm the exact list in the written scope, since it depends on your current tools and access model.
Can our internal team complete a Prometheus migration without an outside partner?
Yes, a capable internal team can migrate to Prometheus alone if it has the time, the skills and the discipline to run both systems in parallel. The work covers PromQL rules, exporters, service discovery, Alertmanager routing, storage and security settings, and the team must then operate the result. Ask whether engineers can take on the migration alongside current on-call duties, whether anyone has rewritten alert rules before, and who will own upgrades on the 6-week minor release cycle or the one-year LTS line. Some teams bring in a partner only for inventory, rule translation and testing.
Can Prometheus replace our hosted metrics service for every use case?
It depends on the use case, and some workloads need a different tool or an added component. Prometheus is built for operational monitoring, and its documentation says it values reliability over precision, so it is a poor fit where every sample must be exact, such as per-request billing. Local storage is single-node and keeps data for 15 days by default, so longer queries need remote write to external storage. Hosted services may also offer integrations or retention your teams depend on daily, so map each use case deliberately and confirm it in the written scope.
What happens to our existing monitoring history after cutover?
Existing history should not be assumed to move automatically. A new Prometheus server collects data from the point of cutover and keeps local data for 15 days by default, so history stays in Nagios, Zabbix, Graphite or the hosted service unless you export or import it. Common options include keeping the old system read-only for an agreed period, importing selected series where the source format allows it, or accepting a gap in trend data. Decide per dataset which history you need for capacity planning, audits or incident review, and ask the quote to state how each one will be handled.
How DeployOpen runs a Prometheus migration
DeployOpen moves metrics and alerting from Nagios, Zabbix, Graphite or a hosted monitoring service onto Prometheus in infrastructure you control, running the old and new systems side by side before any cutover. Work starts from a written scope that covers the checks, alerts and dashboards in play.
How we scope
- Inventory every existing check, alert and dashboard in the source system, including the ones nobody has reviewed in years.
- Map each check to a Prometheus exporter, a scrape target or a pushed job, and record the gaps that need custom work.
- Agree the written scope in advance, with fixed deliverables for rule rewrites, dashboards and the parallel-run period.
How we build
- Rewrite alerts as PromQL alerting rules, so paging conditions are tested against real series before they replace the old checks.
- Set retention and local storage sizing for the Prometheus server, and decide where long-term data is kept if it must outlive local retention.
- Run old and new monitoring in parallel, compare alert behavior over time and document each difference before cutover.
How we hand over
- Deliver version-controlled configuration, rule files, Alertmanager routing and dashboards that your team can review and change.
- Document the cutover record, including which alerts moved, which were retired and who approved each change.
- Walk your operations team through runbooks for scrape failures, alert tuning, silences and the decommissioning of the old system.
How we support
- Keep the Prometheus deployment current on the minor release cycle or the long-term support line, with upgrade testing for rules and storage.
- Offer ongoing support as a retainer that covers patching, incident help and rule changes after go-live, scoped in writing.
- Confirm with your team which support hours, response paths and escalation contacts apply before the retainer starts.
