Migrate from Nagios XI to Icinga

Migrate from Nagios XI to Icinga: what the move involves

If your Nagios XI renewal is driven by per-node pricing or by a wish to control the monitoring stack, the move to Icinga 2 is mostly a configuration rebuild with plugin reuse. Your existing check plugins can usually run unchanged, because Icinga started as a fork of Nagios and keeps Nagios plugin compatibility. What you will rewrite is the object layer: host and service definitions, contacts, notifications and the web views your operators rely on. Most teams do this work with an internal platform or monitoring team, often supported by an implementation partner for the Director setup, the distributed zones and the cutover plan. Effort and risk scale with the number of hosts, the amount of hand-written XI wizard output and the number of custom dashboards and reports that must be recreated.

Plan the migration in layers. Start by inventorying every active check, its plugin path and its arguments, then mark which plugins are standard Nagios plugins and which are custom scripts. Map host and hostgroup membership to apply rules with assign where expressions, which the Icinga 2 migration guidance recommends in place of static host lists. Icinga 2 can be configured with the Icinga Director, configuration management tools or plain text in the Icinga DSL, so decide early which of these your team will maintain, because that choice sets the ongoing administration workload. Run both systems in parallel for a period and compare alert output before retiring XI, and confirm the exact package source for your operating system before you build the servers.

Licensing and packaging are the decisions to settle before procurement. Icinga 2 is licensed under GPL version 3 or later from v2.16.0, while earlier versions remain GPLv2 or later, so confirm which release line your team will standardize on and check it against your own licensing review. Installation packages for RHEL, SLES and Amazon Linux require a paid Repository Subscription, while packages for other operating systems remain free, so the operating system mix in your estate may decide whether a subscription line item appears in the budget. Ask Icinga which subscription tier covers your server count and whether support is needed for the cutover window, and confirm these terms in writing with the vendor.

Which Nagios XI capabilities map cleanly to Icinga

This table maps each Nagios XI capability to its closest Icinga 2, Icinga Web 2 or Director equivalent and marks it as clean, needs rework or gap. Use it to decide which parts of your current XI setup move directly, which need redesign, and which need to be confirmed with a proof of concept before you commit to a migration plan.

XI capability	Icinga equivalent	Status and what to confirm
Host and service checks	Icinga 2 checks defined through host and service objects or apply rules	Clean for standard checks. Confirm that each check runs correctly under Icinga 2 scheduling and that check intervals match your XI settings.
Nagios plugins	Existing plugins run as Icinga 2 check commands	Clean for most plugins. Test any plugin that depends on Nagios-specific environment variables or custom macros, and confirm command definitions in the Icinga DSL.
Notifications and contacts	Icinga 2 notification objects with apply rules and user groups	Needs rework. Contacts and escalation logic must be rebuilt as notification apply rules, and time periods must be re-verified after import.
Configuration wizards	Icinga Director for importing and managing objects, plus configuration templates	Needs rework. XI wizards have no direct one-to-one equivalent. Confirm which device types your team adds regularly and whether they will be scripted, templated or handled through the Director.
Dashboards and reports	Icinga Web 2 dashboards and reporting modules, with Dependency Views from the Module Subscription	Gap for some views. Confirm which XI dashboards and scheduled reports your operations and audit teams rely on, then check whether Icinga Web modules or custom dashboards cover them.
REST API	Icinga 2 REST API for objects, status and actions	Needs rework. Confirm each integration that calls the XI API, because endpoints, payloads and authentication differ and must be rewritten.
Distributed monitoring	Icinga 2 zones with master, satellite and agent roles	Needs rework. Redesign zones and endpoints from your XI remote poller layout and confirm the high-availability pattern with two masters.
User and role management	Icinga Web 2 authentication and role-based access, with SAML available through the Module Subscription	Needs rework. Map XI users, roles and host or service group permissions to Icinga Web 2 roles. Confirm your directory integration, since SAML is listed as upcoming in the Module Subscription.
XI add-ons and custom components	Icinga Web modules, custom plugins or scripted integrations	Gap until reviewed. Inventory every add-on and custom script in use, then confirm whether an Icinga module or a custom build is needed for each one.

Reusing Nagios plugins and converting definitions to apply rules

Most of the Nagios plugins your XI installation runs can be reused in Icinga 2 without modification, because Icinga started as a fork of Nagios and keeps plugin compatibility. In practice, each plugin becomes an Icinga CheckCommand object that points at the same executable and arguments. The work is in the wrappers around them. Custom scripts that XI calls through its own command definitions, or that depend on XI-specific environment variables, need to be found in the $USER1$ plugin path and tested under the Icinga service account. Start by exporting every command from XI, marking which ones are stock plugins (check_http, check_disk, check_ping) and which are local wrappers, then run each wrapper by hand as the user Icinga will use. Confirm that its exit codes and output format still match what Icinga expects before you wire it into any host. The migration guidance for Icinga 2 says its advice also applies to Nagios, and it recommends apply rules with assign where expressions in place of host and hostgroup member lists. This changes how you think about the inventory. Instead of copying each XI host and service line, you tag hosts with custom variables (for example, a role or a location) and let a rule such as assign where host.vars.role == "web" create the services for every matching host. Rules are reviewed as code, and a new host gets its checks automatically. Write the rules from the intent of each XI service group, not from the exported list, and check the result by comparing the generated service count per host against XI for a sample of hosts. Do not carry over check intervals, thresholds, or performance data settings without review. XI often has interval and retry values tuned by hand over years, and some checks may be scheduled too often or not at all in the new setup. Confirm the check_interval, retry_interval and max_check_attempts values for each service class. Decide which plugins must emit performance data for graphing, and confirm that the Icinga Web and any time-series writer you choose receive it in the format you expect. Keep a written list of these decisions so the cutover can be checked against it.

What data and integrations move, and what must be rebuilt

A Nagios XI to Icinga 2 move carries configuration objects across more reliably than it carries history or integrations. Hosts, services, contacts, time periods and commands are rebuilt as Icinga objects, while dashboards, reports, ticketing and notification links are rebuilt by hand. Treat each category below as a separate line item in the migration inventory.

Host and service objects

Export the host and service definitions from XI for review, then decide which ones become Icinga host objects, service apply rules and Director imports. Most Nagios definitions map to host and service objects, but hostgroup and servicegroup lists should be replaced with apply rules using assign where expressions. Check each check command and its arguments, because a definition that works in Nagios can still need an updated argument order or a custom command object in Icinga.

Contacts and notification commands

Contacts, contact groups and notification commands define who is alerted and how. Recreate them as Icinga user and notification objects, then test each notification command against a sample alert before cutover. Pay attention to email relays, SMS gateways and any scripts that depend on environment variables set by Nagios, since those variables must be confirmed in Icinga's notification context.

Time periods and dependencies

Time periods control when checks and notifications run, and dependencies stop alert storms when a parent such as a router or core switch fails. Rebuild both as explicit Icinga objects and confirm that each dependency points to the intended parent. Dependencies that were defined in XI wizards may not be exported in a form you can reuse directly, so compare the exported list with the live XI configuration.

Performance data and history

Historical performance data held by XI is not assumed to transfer to Icinga. Confirm with your compliance and operations owners how long trend data and alert history must be kept, then decide whether to keep XI read-only for that period, export reports, or send metrics to a time-series store. Do not treat cutover as a retention plan.

Dashboards and reports

XI dashboards, scheduled reports and availability views are part of the XI product layer rather than the Nagios engine. Icinga Web 2 offers its own views, and the Dependency Views module is a paid Icinga Module Subscription, so confirm which reports your teams need before you plan rebuilds. Ask a quote to include dashboard and report recreation as a separate scope item.

Ticketing and external integrations

Ticketing hooks, ServiceNow or Jira connectors, chat alerts and API consumers that call XI are not carried over automatically. List every integration that receives XI events or calls its API, then rebuild each one against Icinga's interfaces and test it end to end. Confirm the ServiceNow and Microsoft Teams modules' availability against the current Icinga subscription page before you depend on them.

Migration sequence from inventory to decommission

This sequence moves Nagios XI monitoring to Icinga 2 in controlled stages, so each host, check and notification is proven in Icinga before Nagios XI is switched off. Each step produces a named artifact that the next step depends on.

Build the object inventory
Export every host, hostgroup, service, command, contact, contact group, time period and notification rule from Nagios XI, and record which plugin each service calls. Tag each object by owner, business service and criticality, and mark objects that are unused, duplicated or created by XI wizards. The team lead and the service owners sign off on the list. Done when the object inventory covers every active host and check, with each one assigned an owner and a keep, merge or retire decision.
Confirm plugin compatibility
Run each custom and third-party plugin on a test Icinga 2 agent or satellite with the same arguments XI uses, and compare exit codes, performance data and timeout behavior. Plugins that read XI-specific paths or depend on XI wrappers need a rewrite or a direct command definition. Done when every plugin in the inventory has a recorded pass or a named remediation task, and the platform team has reviewed the list.
Stand up a pilot zone with the Director
Install Icinga 2, Icinga Web 2 and the Icinga Director on a non-production master, then create a dedicated zone with one satellite or agent for a small group of low-risk hosts. Rebuild their host, service and notification objects using apply rules with assign where expressions instead of copying XI host lists, and import them through the Director. Confirm the Icinga Web 2 install version and package source, since packages for RHEL, SLES and Amazon Linux are covered by the paid Repository Subscription. Done when the pilot zone runs its checks, the Director deployment succeeds without errors, and the configuration is stored in version control.
Run a parallel check comparison
Keep Nagios XI running and configure Icinga to check the same pilot hosts and, once validated, the wider inventory. Compare state transitions, check results, flapping behavior and notification counts over a period agreed in advance by the operations and service owner teams. Investigate every mismatch and record whether the cause is a threshold, timeout, plugin or scheduling difference. Done when a parallel-run comparison report lists each mismatch with a root cause and a fix or accepted difference, and the service owners have accepted the results.
Test notifications and rebuild dashboards
Recreate contact groups, notification commands and escalation logic in Icinga, then test them with planned alerts to on-call staff and the ticketing or chat endpoints in use. Rebuild the dashboards and scheduled reports that operations and management depend on in Icinga Web 2, and confirm the data matches the XI reports they replace. Confirm any integrations that depend on the XI REST API, since they need a separate replacement plan. Done when a test notification reaches every intended recipient, each required dashboard and report has an owner and a sign-off, and open API dependencies are listed.
Sign the cutover checklist and switch over
Move the remaining zones in batches, each with its own rollback step, and disable the matching XI checks and notifications only after the batch passes the comparison criteria. Record each batch in a cutover checklist that names the approver, the rollback owner and the time of the switch. Keep XI in read-only mode during the cutover window so that its history remains available to the team. Done when the signed cutover checklist shows every batch is live on Icinga, with no active XI notifications for migrated objects.
Archive the XI configuration and decommission
Take a full backup of the Nagios XI configuration, database and performance history, store it in an encrypted location with a documented retention period set by your records policy, and verify that the backup can be read. Remove XI from the monitoring network, revoke its credentials and firewall rules, and update the configuration management and asset records. Confirm the license and maintenance status with your Nagios contract owner before the final shutdown. Done when the archived XI backup has passed a restore test, the server is decommissioned, and the asset register shows the change.

Setting up distributed zones with masters and satellites

Start by mapping every XI remote collector or distributed site to an Icinga zone before you move any host. In Icinga 2, a zone is a named group of nodes that share responsibility for a set of checks. Nodes take one of three roles: a master that holds the authoritative configuration and notifications, a *satellite* that runs checks for a remote network segment and buffers results if the link to the master drops, and an *agent* that runs local checks on a host and reports back. Write down which XI collector covers which network, which zone will replace it, and which node will act as its parent. This inventory is the document your team will check against during cutover, and it is where you decide whether a site needs a satellite at all or can be reached directly from the master.

Decide early whether the masters will run as a high-availability pair. The Icinga 2 distributed monitoring documentation describes two master nodes in an HA setup, and two sync modes for distributing configuration: top-down command endpoint, where the master pushes check execution to endpoints, and top-down config sync, where the master distributes the configuration itself to child nodes. The mode you choose changes where configuration files live, so test both on a non-production zone before you commit. Confirm the exact options, supported roles and any changes in the current release notes for the Icinga 2 version you plan to deploy, because these details have changed between releases.

Before cutover, verify the network paths and certificates. Each parent and child node needs a reachable TCP connection on the Icinga 2 cluster port, which is 5665 by default, and firewall rules must allow it in the direction your design expects. Each node needs a certificate signed by the same Icinga certificate authority, and the zone and endpoint objects must name each other consistently. Run a connection test from each satellite to its parent and confirm that the certificate fingerprints match what you recorded. Plan for the case where a satellite loses its link, because its buffered results are what keep your history gap-free, and confirm how long your XI setup retained results during its own collector outages so the two systems are not compared on unequal terms.

How the migration differs by estate size and starting point

A single XI server with a few dozen hosts is the simplest case. Most of the work is re-expressing a small set of host and service definitions as Icinga 2 objects, checking that the Nagios plugins you rely on run unchanged, and rebuilding notifications. Because the estate is small, you can usually run Icinga 2 beside XI for a short parallel period and compare results before cutting over.

Plugin reuse: Most standard Nagios plugins can be called from Icinga 2 command definitions, so the check logic often moves without rewriting.
Configuration: Plain Icinga DSL files are enough at this size. The Director is optional and can be added later.
Web interface: Icinga Web 2 replaces the XI front end, so dashboards and views need rebuilding by hand.
Packages: On RHEL, SLES or Amazon Linux, package installation requires the Repository Subscription. Other operating systems use free packages.
Support: The Forever Free edition covers unlimited hosts and services, so a small estate may need no paid line at all.

Before you start, confirm your operating system, since it determines whether the Repository Subscription applies to your install path.

What drives migration cost and duration

This table lists the factors that set the effort and running cost of moving from Nagios XI to Icinga 2, with the one-time and recurring costs each one affects. Read it as a checklist: count your own inventory against each driver before asking any partner for a quote. The main takeaway is that the largest variable is usually custom plugins and wizard-built checks, not the host count.

Driver	Why it changes cost or effort	How to keep it down
Host and service count	Each host and service needs an apply rule, a check or an inventory decision. Icinga's Forever Free edition has unlimited hosts and services, so count affects effort, not licensing, on that tier.	Group hosts by role and use apply rules with assign where expressions instead of per-host objects, as the Icinga migration chapter recommends.
Custom plugins and wizard-built checks	Nagios XI wizards generate check definitions that do not carry over automatically. Custom plugins must be tested under Icinga, and any that depend on XI-specific paths or APIs need rework.	Export a list of every command definition, confirm which plugins are stock Nagios plugins, and retire checks nobody reads before migrating them.
Distributed sites and zones	Each remote site adds a satellite or agent, zone configuration, certificates and firewall rules. Master and satellite roles add design and testing work.	Document the current collector layout first, then build one zone at a time and validate it before adding the next.
Dashboards and reports	XI dashboards and scheduled reports must be rebuilt in Icinga Web 2 or a separate tool. The count of dashboards and report recipients sets the rebuild effort.	Inventory dashboards by user group, keep the ones with active viewers, and agree a reduced set with stakeholders.
Notification integrations	Email, SMS, chat and ticketing hooks each need their own command, contact and escalation logic. Integrations outside the core set may need custom scripts.	List every notification path with its owner and test each one in a staging zone during the parallel run.
Operating system and package source	On RHEL, SLES and Amazon Linux, Icinga's subscription FAQ says installation packages require a paid Repository Subscription. Other operating systems use free packages.	Confirm your operating system before scoping. Ask whether the Repository Subscription cost applies to your servers, using the Icinga subscription page as the published reference.
Staff skills in Icinga DSL	Teams used to XI web wizards need time to learn the DSL, the Director or configuration management. Lower skills raise the cost of the configuration phase and of later changes.	Train two or three administrators early, and keep configuration in version control so knowledge is not held by one person.
Parallel-run length	Running Nagios XI and Icinga side by side doubles alert paths and servers for the overlap period, and duplicate alerts need managing.	Set exit criteria for the parallel run in advance, such as matching alert history for an agreed period, and mute duplicates on the old system once they are met.

What usually goes wrong and how to prevent it

Most failed Nagios XI to Icinga migrations fail in the inventory, the parallel run, or the decommissioning step rather than in the Icinga configuration itself. The cards below cover seven failure points, each with a check to run before the cutover date is fixed.

Missed hosts in the inventory

Nagios XI hosts often include devices added through wizards, hosts that exist only in older config fragments, and hosts that are monitored but not documented. A migration that starts from the wizard list or a spreadsheet will silently drop them. Export the live object configuration from the XI server, compare it against the CMDB and against the hosts that actually send results, and record each difference as a decision: migrate, retire or document as out of scope.

Notifications doubled or missing

During a parallel run, both XI and Icinga can check the same services and send alerts to the same on-call channels, so engineers receive duplicates. If notification filters are copied incorrectly, alerts can also fail to fire at all. Disable notifications on one side for each host group, route the Icinga side to a test channel first, and run a scripted test alert for every contact and escalation path before the old side is silenced.

Custom plugin dependencies that fail

Nagios plugins are generally reusable, but many custom checks depend on local libraries, interpreters, credential files, or SNMP and SSH keys that exist only on the original XI server. These checks often return UNKNOWN on new hosts without an obvious error. Inventory every command in the XI command definitions, run each plugin manually from the Icinga server and from each satellite zone, and confirm that the service account and file paths match.

Check intervals and load not reviewed

Copied check intervals and retry settings were tuned for the XI instance, not for the new topology. Shorter intervals or aggressive retries on a large host set can overload the Icinga master, the database, or the network path to remote zones. Before go-live, review the check interval and retry values for each service template, measure scheduler and CPU load during the parallel run, and agree the acceptable load ceiling with the platform owner.

Certificates and zone trust misconfigured

Distributed Icinga zones depend on certificates that tie each satellite and agent to its parent. Certificates generated with the wrong hostname, expired intermediates, or a CA trusted only on the master will leave remote zones connected but not synchronizing, or not connected at all. Confirm the endpoint names in the zone objects match the certificate common names, test each connection after restart, and record the CA process in the runbook so renewals do not become emergencies.

Dashboards and reports lose user expectations

Operators and managers rely on XI dashboards, availability reports and scheduled exports that Icinga does not reproduce one for one. Icinga Web 2 and its modules cover much of the monitoring view, but teams often discover missing reports only after the old instance is gone. List the dashboards and reports users open each week, map each one to an Icinga Web view, module or external Grafana panel, and ask those users to sign off on the gaps before cutover.

XI decommissioned before backups are verified

Retiring the XI server removes the only copy of its database, historical availability data, and configuration in some setups. A backup that was written but never restored can fail when it matters most. Restore the XI backup to a separate test host, confirm that the hosts, services, contacts and history load, and keep the old server in read-only mode for an agreed retention period before any deletion or license cancellation.

Questions teams ask before moving from Nagios XI to Icinga

What does moving from Nagios XI to Icinga cost?

The software itself can be free, and the cost sits in people, servers and support. Icinga 2 is open source, and its Forever Free edition has unlimited hosts and services. The main costs are the internal engineers who rebuild configuration, the time to test checks and notifications, new servers for masters, satellites or agents, and any subscription you choose. Migration work is usually one-time, while server hosting, patching and administration recur. Ask a provider for a written scope that separates these items, so you can compare the one-time and ongoing lines with your current Nagios XI renewal and maintenance spend.

How long does a Nagios XI to Icinga migration take?

The duration depends on how many hosts, services, custom plugins, dashboards and reports you have, and on how much of the configuration can be regenerated rather than rewritten. A small environment with standard plugins moves faster than a large one with heavily customized notification logic and reporting. No general timeline can be given here. Ask for a schedule in the written scope that breaks the work into inventory, parallel running, cutover and decommissioning, and confirm how each phase is tested before Nagios XI is switched off.

What does the internal team need to provide during the migration?

Your team needs people who know the monitored estate and the current Nagios XI setup. That means someone who can export or describe host groups, service checks, contacts, escalation rules and maintenance windows, and someone who owns each custom plugin. Plan for time from the on-call and application teams to validate alerts, because a configuration that loads without errors can still page the wrong people. Icinga Web and the Director also need an owner who will approve the new object model and the naming conventions before import.

Can our own engineers do the migration without an outside partner?

Yes, if they have Linux administration skills, experience with Nagios configuration and time to learn the Icinga 2 DSL and apply rules. Icinga's migration guidance applies to Nagios as well as Icinga 1.x, and it recommends apply rules with assign where expressions instead of host and hostgroup lists, which is a rewrite that needs careful testing. Most teams reuse existing Nagios plugins, so the check logic often carries over. An outside partner adds value when the timeline is tight, when the estate is large, or when the internal team lacks spare capacity. Compare both options against the same written list of deliverables.

What do Icinga subscriptions add beyond the open-source software?

Subscriptions add packages, modules and vendor support. Icinga lists a Repository Subscription for RHEL, SLES and Amazon Linux packages, a Module Subscription that currently offers the Dependency Views module, and a Support Subscription with 8x5 or 24/7 coverage. Per Icinga's subscription page, the Repository Subscription is 5,000 euros per year, the Module Subscription is 2,000 euros per year and Support starts from 15,000 euros per year. Icinga's FAQ states that packages for other operating systems remain free. Upcoming Microsoft Teams, ServiceNow and SAML modules are listed as future items, so confirm their availability on the subscription page before you plan around them.

Is the Icinga Director required for configuration?

No. The Icinga 2 README says configuration can be managed with the Icinga Director, with configuration management tools, or with plain text in the Icinga DSL. The Director gives a web interface for importing objects and managing templates, which many teams prefer when they move from a GUI-driven product like Nagios XI. Teams that already manage configuration as code may skip it. Decide early, because the choice affects how you import objects, how you handle change control and who can edit production checks.

How does distributed monitoring change after leaving Nagios XI?

Icinga 2 organizes distributed monitoring into master, satellite and agent roles arranged in zones. It supports two master nodes in a high-availability setup, and offers top-down command endpoint and top-down config sync modes. Your current remote collectors or Nagios XI distributed setup will not map one to one, so the network design, certificates and zone layout need to be planned before cutover. Confirm the mode you intend to use, how failover behaves in your network and how the configuration reaches each satellite, against the Icinga distributed monitoring documentation.

What should we ask for in a written scope before we sign?

Ask for a list of hosts, services and plugins in scope, the target Icinga version and operating system, and whether Icinga Web, the Director and any distributed zones are included. Require a list of dashboards and reports to rebuild, a test plan that compares alert behavior with Nagios XI during parallel running, a cutover and rollback plan, documentation of the final configuration and a training session for operators. Also confirm which subscriptions are priced separately, what happens if the scope changes, and who signs off on decommissioning Nagios XI. Scope, deliverables and timelines are normally agreed in writing before work starts.

Rebuilding dashboards, reports and notifications in Icinga Web

Nagios XI dashboards, reports and notification wizards do not move across as files. In the Icinga stack they are rebuilt in Icinga Web 2, the frontend that Icinga 2 requires, and in whichever modules your subscription covers. Start by listing every XI dashboard, saved report, scheduled report and notification escalation your operators actually open, and export the host and service groups each one depends on. Many XI views are simply filters on hostgroups and servicegroups, so once the groups exist as Director-managed objects, most views can be recreated as filters rather than as custom code. Confirm your Icinga Web 2 version against the Icinga Web 2 releases page before you start, because the module list and the frontend move together.

Dependency Views is the module that the Icinga subscription page currently lists as available under the Module Subscription, and it is the one to plan around if your XI estate relies on parent and child host relationships. Microsoft Teams, ServiceNow and SAML authentication are listed as upcoming modules. Do not design notification paths or single sign-on around them until you have confirmed with Icinga that they are released and supported for your version. Until then, keep XI's existing mail and paging channels running in parallel, and rebuild Teams or ServiceNow hand-offs as scripted notification commands only after a test alert has reached the destination end to end. Ask Icinga whether SAML is available for your edition, and state the answer in your migration record.

Rebuild the views operators use during an incident first: a problem overview showing unhandled critical and warning services, a view of hosts that are down with their dependencies, a per-business-service view for the applications your on-call team owns, and an acknowledgement and downtime view for maintenance windows. Then rebuild the scheduled reports that management and audit read, such as monthly availability by service, and check that each produces the same figures as the XI report for one overlapping period. Notifications come last: recreate each XI contact, contact group and escalation as Icinga notification objects, send a test alert for every severity and every escalation level, and record who received it. A parallel run of one to two reporting cycles is the practical check that the new views and notifications match what XI showed.

How DeployOpen scopes and runs the migration

DeployOpen plans and implements self-hosted Icinga 2 inside your own infrastructure, starting from an inventory of your existing Nagios XI hosts, checks and notifications. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory of Nagios XI hosts, service checks, plugins, contacts and notification rules to be migrated
Written decision on which Nagios plugins stay as-is and which checks are rebuilt or retired
Agreed list of dashboards, reports and Icinga Web views that must be rebuilt, with acceptance criteria

How we build

Converting host and service definitions into Icinga DSL apply rules with assign where expressions
Importing hosts, services and templates through the Icinga Director, with the Director configuration reviewed by your team
Designing master, satellite and agent zones for the distributed topology agreed in the scope

How we hand over

Documentation of the zone layout, apply rules, Director configuration and plugin inventory for your operators
Parallel run results comparing alert behavior against Nagios XI before the cutover is approved
Runbooks covering backups, upgrades of Icinga 2 and Icinga Web 2, and rollback to Nagios XI

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Scope changes, such as adding satellites or new plugin checks, are priced and agreed in writing
Your team keeps administrative control of the Icinga environment in your own infrastructure throughout

Migrate from Nagios XI to Icinga