29. 06. 2026
Atlassian
When our work on the NetEye 4.48 upgrade started, one technical dependency quickly became impossible to ignore: Grafana dashboards that still relied on the legacy IDO MySQL database had to be moved to IcingaDB first. That wasn’t the interesting part, though. The interesting part was how to do it safely.
These dashboards are part of NetEye Cloud and are in active use by customers. That meant I couldn’t treat the migration as just a simple mechanical task. I needed a process that kept downtime close to zero, avoided unnecessary manual work, and was predictable enough to trust.
That’s where AI came in. I didn’t use it to make decisions for me. I used it to reduce repetitive work, speed up analysis, and help me validate the migration more consistently.
Why This Migration Mattered
The migration was driven by the move away from the legacy IDO-backed dashboards and toward IcingaDB. In practice, that meant updating data sources, rewriting queries, and making sure every dashboard still behaved the same way after the switch.
For a customer-facing NetEye Cloud environment, that raises the bar immediately. A migration is only acceptable if it’s not just correct, but also stable, repeatable, and easy to verify.
What I Wanted from the Process
I had three goals in mind:
Near-zero downtime
The dashboards had to stay available while the migration was happening. A long maintenance window or a manual cutover with uncertain timing was not an option.
Minimal manual work
The more manual a migration becomes, the more chances there are to miss something. I wanted to keep the process as automated as possible.
Consistent validation
Every dashboard had to be checked in the same way, both functionally and visually, so I could trust the results instead of just hoping it looked right.
The Migration Flow
I treated the migration as a controlled pipeline rather than a collection of isolated edits.
1. Identify the affected dashboards
The first task was to find every dashboard still pointing to the legacy IDO data source. This step mattered because the upgrade path would be blocked if even a single old reference remained in place.
2. Classify dashboards by pattern
Not every dashboard was unique. Many followed recurring structures: template variables, host and service panels, time series panels, summary panels, and tenant-specific variants. Grouping dashboards by pattern made the whole migration much easier to reason about.
3. Use AI to understand dashboard intent
This was where AI helped the most.
Instead of manually reverse-engineering every dashboard from scratch, I used AI to read the existing structure and explain what each dashboard was actually doing: What the panels were meant to show, which parts were functionally important, which queries were reusable patterns, and where the dashboard depended on IDO-specific schema details.
That saved a significant amount of time, especially on dashboards with many panels or more complex variable logic.
4. Let AI draft the transformation
Once the intent was clear, I used AI to help draft the migration itself.
It helped me with:
- Rewriting SQL queries from IDO to IcingaDB
- Mapping old fields to the new schema
- Updating template variables
- Spotting repeated query patterns across similar dashboards
- Suggesting which parts could be migrated mechanically
That didn’t mean I accepted the output blindly. It just meant I started from a much improved first draft.
How I Guided AI
AI was useful because I used it in a very targeted way. I didn’t ask it to “fix the dashboard” in one shot. I split the work into small prompts, each one focused on a single step in the migration flow.
The first kind of prompt was about understanding intent. I used AI to read a dashboard and explain what the panels were meant to show, which operational question they answered, and which parts were semantically important. That was especially useful for dashboards with many panels or reused structures, because it let me work from meaning instead of from raw JSON.
The second kind of prompt was about translation. Once I knew what a dashboard was doing, I asked AI to help me rewrite the SQL from IDO to the IcingaDB schema, map old field names to the new ones, and identify repeated patterns that could be migrated mechanically. In practice, that gave me a better first draft, not a final answer.
The third kind of prompt was about review. I used AI to compare pre- and post-migration screenshots, highlight visible changes, and point out places where a dashboard might still be functionally correct but visually off. That was useful because a dashboard can return the right data, yet still confuse users if the layout, spacing, or labels drift too much.
The fourth kind of prompt was about validation. Before approving a dashboard, I asked AI to produce a concise checklist of what should be verified: datasources, query output, variable behavior, panel consistency, and visual matches. This helped me keep the review process uniform across all dashboards.
The important part was the follow-up. Every AI-generated suggestion was checked against the actual dashboard, the actual query, and the actual screenshots. AI reduced friction, but it never replaced verification.
Applying the Changes Safely
The migration was executed through a controlled workflow so I could preserve service availability. The idea was simple: Work on a copy or migration branch of the dashboard, update the data source reference, adapt the queries, validate the output, and only then send out the result.
That kept the live service stable and avoided surprise changes on customer-facing dashboards.
Functional Validation
AI reduced manual work, but it didn’t replace validation.
Each migrated dashboard was checked to make sure that the data source was correct, the queries returned the expected values, filters and variables still behaved as intended, the dashboard still answered the same operational question, and the result remained consistent with the original dashboard.
Functional correctness was mandatory, but it was only half of the story.
Visual Validation with Playwright
For dashboards, functional validation alone is not enough. Visual consistency matters too.
To make the review more reliable, I used Playwright to capture screenshots before and after the migration. That gave me a concrete way to compare panel layout, chart rendering, labels and legends, spacing and alignment, and visible regressions caused by query or datasource changes.
This step was especially useful for catching problems that a query-level check would not reveal immediately. A dashboard can return data but still be wrong if the presentation changes in a way that confuses the user or hides important information.
The screenshot step made the process safer because it combined functional validation to verify the data, and visual validation to verify the rendering.
What AI Did and What It Didn’t Do
AI was used as an accelerator, not as an authority.
AI handled
- Reading the existing dashboard structure
- Summarizing each panel’s purpose
- Proposing query translations
- Highlighting schema differences
- Producing migration drafts
- Reducing repetitive manual editing
- Helping interpret screenshot differences and likely causes of visual drift
Human review handled
- Deciding whether a dashboard was semantically correct
- Confirming that business meaning was preserved
- Validating edge cases
- Approving the final migration
- Making sure the process stayed aligned with my SaaS reliability goals
- Confirming that visual checks matched the intended dashboard behavior
That split was intentional. It gave me speed without giving up control.
Why This Approach Worked
The main reason this approach worked is that the migration was treated as an operational process, not as a one-off coding exercise.
That made it possible to keep the process repeatable, reduce the risk of human error, lower the amount of manual editing, preserve customer-facing availability, and move quickly without sacrificing safety.
In a SaaS context, that balance matters more than raw speed.
Conclusion
Migrating IDO Grafana dashboards to IcingaDB was mandatory for the NetEye upgrade path, but the way I handled it was an explicit choice.
I chose a workflow designed for near-zero downtime, low human interaction, and high safety. AI was a key part of that workflow because it helped me understand the dashboards, draft the transformation, and reduced repetitive work. Playwright-based screenshot checks added an extra layer of confidence by verifying not only the data, but also the visual result.
Human review stayed in the loop only where it was truly needed. That combination gave me what I wanted: A migration that was fast, controlled, and safe enough for customer-facing SaaS dashboards.
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
Daniel Vedovato
I'm a NOC Engineer at Würth IT Italy, where I work on critical infrastructure monitoring and automation.
Before joining Würth IT, I spent nearly seven years managing ICT infrastructure at an international airport. This experience gave me a solid grounding in high-availability systems and the kind of monitoring that actually matters when things go wrong at 3 AM.
My day-to-day revolves around Icinga, NetEye, and making monitoring pipelines smarter and less noisy. I'm also deeply interested in the practical side of running AI infrastructure on-premises and integrating it into existing observability stacks.
Author
Latest posts by Daniel Vedovato
02. 04. 2026
AI, NetEye, Unified Monitoring
Monitoring Ollama in NetEye with ollama-metrics and check_prometheus