Life of an IT Engineer: Before and After IaaS Insights
DJ Bissinger
How AI transforms disaster recovery from a months-long project into an intelligent, living strategy.
Life of an IT Engineer: Before and After IaaS Insights
How AI transforms disaster recovery from a months-long project into an intelligent, living strategy
For most IT engineers, disaster recovery isn't something they work on once and forget. It's a constant balancing act between keeping the business running today while preparing for the day everything goes wrong.
Every password reset. Every server upgrade. Every software patch. Every user issue competes for the same limited hours in the day.
Unfortunately, disaster recovery planning often loses that battle.
After speaking with Sales Engineer James Pendergrass, who handles onboarding disaster recovery environments (among many other responsibilities) at Net3 Technology, one theme became clear:
Creating a disaster recovery plan isn't technically difficult—it's operationally exhausting.
IaaS Insights changes that.
Before IaaS Insights: Living in Documentation Hell
Imagine you're handed the responsibility for protecting an entire company's infrastructure.
But before a single recovery test can occur, the engineer must manually collect:
Firewall configurations
VPN settings
Network rules
Server inventories
IP addresses
Application dependencies
Special boot procedures
Recovery notes
Vendor documentation
The goal is simple: Create documentation detailed enough that anyone with basic technical knowledge could rebuild the environment from scratch after a complete disaster.
Simple goal. Extremely difficult execution. Gathering this information takes weeks, given the myriad other responsibilities the engineer has.
The Real Challenge Isn't Technology.
Most organizations don't understand their own infrastructure. Servers have been running for years. Applications have been modified. Employees have left, and new ones have been hired. Documentation is outdated.
Pendergrass explained that roughly 70% of environments require extensive detective work. Customers know a server is important - but not necessarily what it actually does or what depends on it.
That begins a frustrating cycle of scheduling meetings, contacting vendors, finding previous administrators, testing dependencies, failing over servers one at a time, discovering what broke, and then repeating the cycle.
The documentation is less about writing and more about investigating… which can take months. One onboarding project took James four months to complete because each discovery step necessitated back-and-forth communication with the customer.
Typical onboarding projects require:
Weeks gathering networking information
Multiple discovery meetings
Firewall analysis
Dependency mapping
Test failovers
Documentation revisions
Meanwhile, he was still responsible for:
System failures
Patching
Password resets
Software upgrades
Customer support
Daily operational emergencies
Disaster recovery becomes "that important project" everyone agrees should be done...
...but nobody has uninterrupted time to finish.
The Most Painful Part: Discovery & Testing
When asked what consumes the most time, the answer was immediate:
Networking and discovery.
Not because the work is technically difficult, but because nobody has all the answers.
The onboarding engineer often must coordinate multiple people simply to determine:
Which machines work together
Which applications depend on each other
Which firewall rules are actually required
What needs to recover first
Every unanswered question means more emails, more meetings, more scheduling, and more delays - and every delay pushes disaster preparedness further into the future.
Only after weeks - or months - of documentation can the real work begin. The entire environment is failed over into an isolated recovery environment.
Every server is tested.
Every application.
Every connection.
Every dependency.
Smaller environments might complete testing in several hours, while larger environments typically require two to three full days of validation.
Only after successful testing is the disaster recovery plan considered complete. Until something changes... and the entire document begins to age immediately.
After IaaS Insights: From Static Documents to Living Intelligence
After working with IaaS Insights, James found that the biggest change wasn't automation - it's awareness.
Instead of maintaining a Word document that slowly becomes outdated, IaaS Insights continuously understands the environment.
If James changes:
CPU allocation
Virtual machines
Infrastructure
Resources
IaaS Insights knows.
The documentation stays in sync with reality rather than becoming obsolete the moment it is saved.
The Engineer Stops Chasing Information
The initial onboarding still matters, and information still needs to be collected.
But now, the software actively guides the process, and instead of wondering what information is missing, the platform tells you.
Examples include prompts like:
You haven't discovered assets yet.
Upload your firewall configuration.
Create application groups.
Complete dependency mapping.
Rather than relying on emails and human memory, the platform walks engineers through each required step.
That alone removes countless scheduling conversations.
AI Does the Heavy Lifting
Once connected, IaaS Insights automatically discovers infrastructure.
One demo environment returned:
57 virtual machines
Their configurations
Hardware resources
Existing infrastructure
From there, IaaS Insights AI-driven power begins making recommendations. Instead of manually grouping applications, the software analyzes dependencies and builds application groups automatically - getting engineers roughly 90–95% of the way there, with final validation still left to human expertise.
Runbooks Become Intelligent
Traditional DR runbooks are static documents.
IaaS Insights generates them dynamically.
Because it understands:
Infrastructure
Dependencies
Downtime costs
Application priorities
Asset groups
…it can automatically generate recovery steps in the proper order.
Instead of maintaining pages of documentation manually, engineers simply tell the platform to generate the runbook based on the current environment.
Business Decisions Become Data-Driven, Not Opinion-Driven
One capability stood out during the interview.
IaaS Insights doesn't just understand technology. It understands business impact.
Organizations can calculate:
Cost per minute of downtime
Employee productivity loss
Revenue impact
Application criticality
One real-world example described an organization that lost $1.1 million during an eight-hour outage before implementing higher-availability disaster recovery.
Now disaster recovery decisions aren't based on opinions; they're backed by financial data.
The Time Savings
Perhaps the biggest surprise from the interview was the difference in project timelines:
Traditional Process
Discovery: Weeks
Customer collaboration: Weeks to months
Complex environments: Up to four months
Documentation continuously ages
Heavy engineer involvement throughout
With IaaS Insights
Automatic infrastructure discovery
Guided onboarding
AI-generated asset groups
Dynamic runbook creation
Living documentation
Typical environment configured in about one hour
Projects that previously stretched across months can often be completed within about a week, largely because the platform eliminates much of the manual back-and-forth and continuously guides the process.
Before vs. After
Before IaaS Insights | After IaaS Insights |
· Static Word/PDF runbooks | · Living, continuously updated platform |
· Manual server inventory | · Automatic infrastructure discovery |
· Manual dependency mapping | · AI-assisted application grouping |
· Endless customer meetings | · Guided onboarding workflow |
· Emails asking for missing information | · Built-in prompts for missing data |
· Manual recovery documentation | · AI-generated runbooks |
· Documentation becomes outdated | · Environment stays synchronized |
· Reactive planning | · Continuous disaster readiness |
· Weeks or months of effort | · Hours to days for many tasks, with projects often completed in about a week |
The Bigger Picture
James’ experience revealed something important:
IaaS Insights doesn't eliminate the engineer.
It eliminates the repetitive work that keeps engineers from applying their expertise.
Engineers still validate recommendations.
They still understand business priorities.
They still make the final decisions.
But instead of spending months gathering information, updating documents, and coordinating meetings, they spend their time improving resilience, reducing downtime, and planning strategically.
For organizations with lean IT teams, that shift may be the biggest advantage of all.
IaaS Insights transforms disaster recovery from a static documentation exercise into a living, intelligent system - one that saves time, reduces manual effort, improves accuracy, and helps engineers focus on protecting the business instead of chasing paperwork.