Microsoft 365 Copilot has been built on top of OpenAI’s large language models since its inception in November 2023. 

Their strategic partnership has allowed millions of secured business prompts using the paid version of Copilot, and recently, through the free Copilot Chat.  

In parallel, OpenAI is investing in ChatGPT Enterprise to compete with AI lab rivals Anthropic (Claude) and Google (Gemini), and to some extent, Microsoft itself.  

As the frenemies plan the next seven years of their alliance, a substantive debate continues to surface: which service is better for businesses?

I’ve discussed with several IT leaders, and include the prevailing sentiment below.

This was validated by one particular CIO, who is one of the few that provides his organization with the option to use either ChatGPT Enterprise or Copilot (and in addition, Claude or Gemini).

What follows are the drivers that we agreed on.

Why Businesses Are Adopting
Microsoft 365 Copilot

When comparing ChatGPT Enterprise and Microsoft’s paid version of Copilot, five of the key differences highlight Copilot’s strengths, while one reflects a perceived advantage for ChatGPT.

There are five positives for Copilot: 

1. Microsoft 365 Copilot works natively in the apps where people are working (i.e. Word, Teams, etc.). It’s not another ‘place’ to go and get things done. 

2. Teams meeting transcript recap is the most popular feature, but only works with Copilot. 

3. Copilot scans the entire Microsoft 365 tenant, not just the files you upload to process (which is the case with ChatGPT). 

4. Microsoft’s security stack (i.e. Purview and SharePoint Advanced Management) can protect the data that an organization deems private, and which shouldn’t be accessible via GenAI. People can upload anything into ChatGPT without such controls (although Purview does provide some protection against shadow AI).  

5. The free Copilot Chat is a decent option for people who don’t warrant the entire license, while providing a consistent, secure enterprise standard.  

Where Users Perceive ChatGPT Has An Edge

That leaves the sixth difference as a subjective advantage in ChatGPT’s favor:

6. People tend to find its answers seem better, without being able to put a finger on why. 

Said the CIO, who kindly confirmed these exact points, “I think you have summarized this pretty well. Really, what it comes down to is ChatGPT’s responses just seem to be a lot better than Copilot.”  

Dissecting ChatGPT’s Subjective Advantage

Why does ChatGPT “seem” to provide better responses? I put ChatGPT and Microsoft 365 Copilot head-to-head using three (3) basic business prompts. 

Rather than subjectively comparing and rating their responses myself, I had a third LLM (Gemini) evaluate the outputs for objectivity.

Test Methodology  

Three of the exact same prompts were requested of both models:  

• Creative marketing 

• Strategic analysis 

• Technical document editing 

After generating the six outputs, I copied them and removed any identifying details. I then submitted the anonymized outputs to a neutral third-party AI (Gemini) for scoring. Gemini applied a four-part, 1-to-5 scoring rubric to each output, allowing for a maximum of 20 points per test and 60 points total.

Test Results

As do many humans, Gemini observed clear differences in how each system produced its responses. It scored ChatGPT at 60/60 and Microsoft 365 Copilot at 54/60. Both are high scores, and the six-point gap reflects differences in how the two systems interpret and apply instructions, not differences in underlying intelligence.

These nuances matter for understanding output quality, but they represent only one dimension of evaluating enterprise AI. To understand why the scores differed and why many organizations still prefer Copilot for productivity, security, and governance, we looked more closely at how each system approached the prompts.

Why the Scores Diverged

The most significant functional difference was ChatGPT’s ability to perfectly adhere to all rules simultaneously. 

Marketing Prompt: Completeness vs. Utility

In the marketing prompt, I asked both systems to create an invitation to a webinar provided by financial advisors for prospective clients.

Copilot’s marketing email scored lower (17/20) because its response failed to explicitly mention one of the important services in the prompt (estate planning).

On the other hand, Gemini gave ChatGPT full marks since it seemed to treat the prompt as a non-negotiable set of rules. ChatGPT’s response was longer, but more complete.

Copilot, while excellent, demonstrates a tendency to prioritize high-level utility over flawless execution of every specific constraint, which, in at least one test, led to incomplete final content.  

Strategic Analysis Prompt: Extra Customization Wins

In the strategic analysis test, both systems were pointed to a blog and asked to provide novel, high-value strategy tips. Copilot scored 19/20, and ChatGPT received Gemini’s full marks.

The final point difference was in the application of that strategy.

M365 Copilot “Provided excellent strategic concepts and an actionable checklist. This highlights its power in grounded analysis and structured business frameworks.” 

Meanwhile, ChatGPT “Achieved the final point by including an ‘Implications for Your Context’ section, which proactively connected the strategic takeaways to the user’s specific consulting business.”

ChatGPT not only analyzed the blog, gave insights, but also gave additional insights to me (the user), which again made the response much longer, but provided a surprising final layer of customized value. 

Job Description Prompt: Strategic Alignment

Finally, I uploaded a job description into both systems and asked them to interpret and improve the document.

Both AIs fulfilled the rules, but ChatGPT’s output was strategically more valuable, yielding 20/20. 

Copilot’s 17/20 score reflects that its metrics for the job role focused on process-oriented measures (e.g., SOW count), whereas ChatGPT’s metrics aligned strategically with the ultimate business goal (e.g., revenue generated and win rate).

Gemini interpreted the difference:
“This suggests ChatGPT is better tuned for strategic extrapolation, interpreting the job’s context to propose high-value edits that directly relate to executive performance metrics, making its output immediately more useful for senior HR/Recruiting teams.” 

When you look across all three tests, the strengths and limitations become clearer; and that’s where broader business considerations enter the picture.

Final Takeaways on ChatGPT vs Copilot

Content and extrapolation aren’t the only decision criteria for businesses. Clearly, Copilot’s integrations and security are top of mind for many CIOs (and especially CISOs).  

Yet users often have the final word, and often make their decisions in the shadows, so IT leaders would do well set clear guidelines for adoption: 

ChatGPT is best for: 

• Flawless creative execution. 

• Complex multi-rule tasks. 

• Executive-level communication. 

• Any deliverable where zero errors and high strategic nuance are required. 

Choose M365 Copilot for:  

• For daily productivity in all the M365 apps. 

• When responses need to be based on more than a single (open or uploaded) document. 

• Where information security and enterprise data protection are important. 

• When your organization wants freemium GenAI capabilities (with Copilot Chat for $0 and paid M365 Copilot licenses where warranted). 

But no matter which GenAI platform(s) you endorse, it is most vital to pick one (or more), fund it for authorized users, and clearly set expectations about not using public AI for work data.  

Empower Your Organization with the Right AI Strategy

Choosing the right GenAI platform is a strategic decision. eGroup can help ensure your team is using tools that drive productivity, security, and real business outcomes.

SharePoint (and OneDrive) have quietly powered collaboration for years, sometimes so quietly we forget to dig deep– but in our Fall roadshow, I teamed up with Jesus Shelby, Director of Cloud & Microsoft 365 Services, to unpack what’s new, what’s next, and how to get the most from modern SharePoint. You can also hit play on the recording here.  

Recent Directions  

SharePoint’s recent advancements are foundational for how organizations manage content, reduce administrative overhead, and prepare for an AI-driven future.  

The latest possibilities we focused on include: 

• Reducing administrative burden through automation and smarter governance 

• Making your SharePoint Online (SPO) system AI-ready for Copilot and other intelligent services 

• Saving costs by tackling storage sprawl and optimizing resource usage 

• Improving compliance with advanced security and data governance controls 

• Enhancing employee experience with modern, intuitive tools 

Let’s dive into the key themes and actionable takeaways. 

Key Advancements and Upcoming Improvements 

SharePoint Advanced Management’s (SAM) and the Content Management Assessment (CMA) Dashboard 

• Automates governance tasks and prepares sites for Copilot activation 

• Provides a unified dashboard to evaluate site health, permissions, and lifecycle readiness 

• Helps identify over-permissioned sites and remediate security risks efficiently 

“If you have Copilot– even one license– you’ll have access to a subset of the SAM controls. 
They’re really the most important parts for getting more information around your SharePoint sites, your permissioning, who’s accessing what, and how things are being shared.” 

— Jesus Shelby, Director of Cloud & M365 Services

SharePoint Backup and Archive Service 

• Automates backup, integrates with Microsoft 365, and reduces manual effort 

• Quickly restores sites and files to minimize risk and impact of data loss 

• Moves inactive sites to cheaper storage, but still supports retention policies and compliance 

• Controls costs tightly with its (upcoming) file-level archive capability  

“Backup covers Exchange and content, whereas archive is really only content– your files, your SharePoint sites. Archive and backup are different; they serve different purposes.”

— Jesus Shelby, Director of Cloud & M365 Services

Intelligent Versioning 

• Automatically tracks document changes and flags significant updates 

• Minimizes storage needs by preventing redundant file copies 

• Enables easy retrieval and comparison of older versions, supporting better teamwork and rapid decisions 

• Can save up to 70% of storage consumption on sites 

“Most people aren’t even aware of how much storage these things are actually taking up. To clean them up manually is pretty onerous. Having this built into the platform is extremely helpful.”

— Jesus Shelby, Director of Cloud & M365 Services

AI File Actions and Knowledge Agents 

• Users can summarize, compare, generate FAQs, and create audio summaries from documents using AI 

• With knowledge agents, Metadata tagging is automated, improving search accuracy and enabling advanced workflows 

• AI features are enabled via the ‘AI Actions’ button (for Copilot-licensed users) 

Copilot-Connected Enterprise Image Libraries 

• PowerPoint users can pull branded images from SharePoint Organizational Asset Library or Templafy, maintaining brand consistency 

• Libraries are registered using PowerShell with CopilotSearchable flag 

Copilot-Powered Page Sections 

• AI-generated sections help authors create content faster with relevant contextual formatting 

• Improves productivity and consistency in SharePoint page development

SharePoint Agents 

• Smart assistants answer natural language questions using SharePoint site content 

• Deployed via Teams integration (or accessible via the SPO page itself) and configured with domain-specific content scopes 

Free for Microsoft 365 Copilot users or pay as you go for unlicensed users  

Hero Links for Secure Sharing (Future) 

• Generates a unique secure link per file with automatic permission settings 

• Simplifies sharing and reduces errors related to file permissions 

• Feature is enabled by default for convenience 

“Microsoft’s going to start releasing this early next year. It should simplify how people are sharing, remove confusion, and make it easier when links are going around.”

— Jesus Shelby, Director of Cloud & M365 Services

What Technologies You Need to Know
 

• Purview – Data governance and compliance management, including sensitivity labels 

• Advanced Management (SAM/CMA) – Unified dashboards and controls for site health, permissions, and lifecycle 

• Knowledge Agents – Automate metadata tagging, FAQ generation, and document summarization 

• Hero Links – Simplified, secure sharing links for files and sites 

• Intelligent Versioning – Automated version control and storage optimization 

Best Practices, Lessons Learned, and Recommendations 

• For SAM/CMA, start with a full export of your sites and configurations to assess exposure and permissions. Then, use group-based access controls to rein in unfettered access and simplify management. Leverage CMA and SAM dashboards for visibility and targeted remediation on an ongoing basis. 

• Educate users on sharing behaviors and monitor activity to maintain security 

• Enable knowledge agents to automate metadata and improve search accuracy 

• Plan for storage optimization with intelligent versioning and upcoming file-level archiving 

• Apply sensitivity labels and configure Purview for file-level protection  

• Test new features in preview and stay abreast of roadmap updates via the Message Center 

Conclusion 

SharePoint is accelerating behind the scenes, with AI, automation, resiliency, and cost controls at the forefront. Staying abreast of these new capabilities can reduce administrative burden, save costs, and empower employees with more secure collaboration tools.

Turn SharePoint Insights Into Action

Take the next step in your Microsoft 365 journey. Our experts help you map out a strategic roadmap that modernizes collaboration, governance, and AI readiness.

Giving access to third-party vendors is both a necessity and a risk. Common scenarios of developers needing access and specialized tooling, third-party service providers/consultants, or external users often need access to sensitive systems and data, and traditional VPN is cumbersome to both use and manage. Providing that access comes the potential for misconfiguration, over-permissioning, and increased exposure to threats.

Here is the challenge:

How do you enable secure, scalable, and auditable access for vendors without compromising your organization’s security posture or operational efficiency?

Microsoft’s cloud ecosystem offers a suite of solutions purpose-built for this challenge. In this post, we’ll explore three key options: Azure Bastion, Azure Virtual Desktop, and Microsoft Entra Private Access. Will discuss how each can be used to build a modern, secure, vendor access strategy that is tailored to the users’ needs and is efficient to manage for your technology team.

Azure Bastion: Secure Remote — Managed Access Without Public Exposure

Traditional remote access often relies on exposing resources (virtual machines, networks & data) to the internet via public IPs and RDP/SSH ports. This approach is inherently risky, opening the door to a variety of threats and potential lateral movement once inside the environment. Azure Bastion offers a different approach by providing secure, seamless RDP and SSH connectivity to Virtual Machines directly through the Azure portal. Doing so without exposing those VMs to the public internet.

How this helps support secure vendor access:

• Agentless Access: Vendors don’t need to install clients or manage VPNs. They simply log into the Azure portal and connect securely.
• No Public IPs Required: Bastion eliminates the need for public IPs on VMs, reducing attack surface.
• Secure access with Microsoft Entra ID: Access can be tightly scoped to specific VMs and time windows using Entra ID.
• Segmentation: Leveraging just-in-time (JIT), we can dynamically allow/disallow network access to resources internally to just the times it is needed.  Reducing the risk of lateral movement in the environment.
• Auditability: Bastion integrates with Entra ID, Defender, & Sentinel, enabling visibility into who accessed what, when, and how.

Primary Remote Use Case: A vendor needs occasional access to a production VM for troubleshooting. With Bastion, you can grant time-bound access to just that VM, without opening firewall ports or provisioning VPN credentials.

Azure Virtual Desktop: Flexible and Efficient Workspaces for External Users

Secure vendor access isn’t always as simple as providing access to a specific resource.  Sometimes, a full desktop experience or access to multiple internal resources across development, production, secure networks, etc. are required. Azure Virtual Desktop (AVD) offers a secure, scalable solution. AVD provides a virtualized Windows experience that is hosted in Azure but allows vendors to work within a controlled environment that is suited to their needs– scoped only to access the resources they require, and can be fully managed by your IT team.

Why It Works for Vendor Access

• Granular Access Control: Assign access based on roles, groups, or specific tasks.
• Customization: Deliver desktops or applications that are tailored to meet the task at hand.
• Entra ID Conditional Access Secured: Enforce multi-factor authentication, device compliance, and location-based access.
• Data Protection: Enable data loss prevention with policies like clipboard restrictions, watermarking, and session recording.
• Scalability: Spin up environments for short-term projects or long-term engagements without provisioning physical hardware.  Then pay only for what you use.
• Compliance: Meet strict compliance requirements from regulatory frameworks.

Primary Use Case: A partner needs access to work inside your environment to support building or modifying a variety of resources in the cloud or on-prem. AVD allows them to work in a secure space without exposing your environment to theirs or the outside world.

Microsoft Entra Private Access: Zero Trust for Internal Apps

VPNs have been a necessary evil for a long time in the secure remote access space, but they’re increasingly being seen as over-permissive against today’s threats. They tend to grant broad network access with limited visibility or control. Some of that is due to improper configuration (I’ll get to locking that down tomorrow), and some is a limitation of the technology. Microsoft Entra Private Access offers a modern alternative as part of the overall Secure Access Service Edge (SASE) strategy. It enables secure, identity-centric access to internal apps without requiring full network connectivity.

How does this help?

• Enables Zero Trust: Access is granted based on identity, device, and real-time risk signals.
• No VPN Required: Vendors access apps through a secure reverse proxy, reducing complexity and overhead. No more VPN clients and version mismatches to maintain.
• Integrated Security: Works with the broader landscape of security solutions like Microsoft Defender, Entra ID Conditional Access, and Identity Protection.
• Improved User Experience: Seamless access via browser or Microsoft 365 productivity apps, with no need for VPN clients and multi-step processes.

Use Case: A third-party service provider (or remote employee) needs access to an internal web app. Entra Private Access allows secure, browser-based access with full audit trails.  Doing this without opening the network up for additional risks.

Final Thoughts

Each of these technologies presents a different value proposition depending on the use case. The right mix depends on your specific needs across the users themselves, alongside security, compliance, and management efficiency.

Looking for a place to start?

• Short-term access to VMs in the cloud and data center? Use Azure Bastion.
• More persistent, long-term, or specialized software required? Deploy Azure Virtual Desktops or Applications.
• Access to internal apps, but you don’t need a desktop. Leverage Entra Private Access.

The key is to move beyond one-size-fits-all solutions, put the users’ needs at the forefront, while ensuring the access itself is secured with Microsoft Entra ID Conditional Access, Privileged Identity Management, etc.

Next Steps:  Let’s Build Your Plan

I’d love to hear more about your secure remote access use cases.  From there, we can develop a plan with the right mix of technology and security to deliver modern, secure, and efficient access to your critical business partners.

Ready to Secure Your Vendor Access?

Implementing a modern, Zero Trust strategy for external partners requires careful planning and the right mix of Azure tools. Stop relying on outdated VPNs and start controlling access with identity-driven security.

The Evolution of Microsoft Sentinel

Microsoft Sentinel has been a foundational tool for building cloud-native security operations.  It started with leading the cloud-native SIEM charge, but the September 2025 announcements lay out how Sentinel will function and where it fits within Microsoft’s broader security strategy going forward.

This isn’t just a product update, this evolution matters because it redefines how security teams will detect, respond, and adapt to threats today and in the future. 

Understanding the Agentic Era

The concept of the “agentic era” refers to a transition from traditional automation to intelligent agents that can reason, act, and adapt. In short, we have and want agents that can not only alert but take actions.  In Sentinel, this means the introduction of AI copilots, natural language interaction, and context-aware recommendations. These features are designed to reduce the burden on analysts, improve detection accuracy, and accelerate response times.  Think of it this way, instead of complex queries to correlate events and data we can simply say, “what was the issue and what areas were impacted”.  Now, that doesn’t mean we don’t need security teams, but it does allow those security teams (or agents they create) to identify, react, and respond faster. 

This shift also introduces new architectural considerations. Organizations will need to rethink how they structure their data, workflows, and integrations to support these capabilities. Sentinel is no longer just a log collector. It is becoming a decision-making partner.  Sentinel Graph maps all entities and uses orchestration capabilities to help AI agents understand the relationships between assets, identities, and activities.  The Model Context Protocol (MCP) provides a structured way for AI and human analysts to query security data contextually.  Following a similar foundation to Microsoft Copilot.  

A simple example of this would be the creation of an agent that is solely focused on phishing attempts.  Taking actions to notify the user that phishing attempts have been detected against their mailbox and warning for extra caution.  However, these agents go beyond alerting. They can perform a wide range of actions to separate false positives to focus in on the real threats. 

As Chris Stegh, CTO of eGroup Enabling Technologies, explains:

“The most relevant AI Agents in SecOps are the Security Copilots. Clients with large enough SOC teams can optimize the time of those valuable professionals by providing natural-language interfaces to information that can simply reduce risk faster. Due to the cost and people involved, smaller SecOps teams might still benefit from having a managed security partner.” 

Sentinel’s Migration to the Microsoft Defender Portal

One of the most visible changes that have been announced is the migration of Sentinel into the Microsoft Defender portal. This move consolidates Microsoft’s security tools into a single interface, making it easier to correlate signals across endpoints, identities, cloud workloads, and more.  This simplifies visibility for security teams by pulling together disparate tools into one central location. 

For organizations already using Defender for Endpoint, Identity, or Cloud, this integration simplifies operations. The migration to the Defender portal is not automatic.  Organizations will need to create a plan for the migration as well as replace any legacy capabilities that will not be making the move to the new, consolidated, platform.  Businesses should plan on completing the migration by March 31^st, 2026. 

Sentinel Data Lake: Preparing for AI Workloads

Microsoft also introduced the Sentinel Data Lake, a new storage layer that separates compute from storage. The primary benefit organizations will see is reduced costs for storage, something that is a BIG benefit. 

In addition to cost savings, it will allow organizations to retain data for longer periods at that lower cost, while also enabling advanced analytics and machine learning. The result?  Significant cost reduction as well as less administrative time fine tuning storage retention. 

It’s not just about cost savings. The Data Lake is important for making those agentic AI scenarios a reality. Agents require historical context to make informed decisions. By storing years of data efficiently, organizations can support forensic investigations, compliance audits, and proactive threat hunting without overwhelming their budgets. 

Cost Optimization: New Pricing Models

Microsoft introduced new Sentinel pricing tiers designed for flThe cost savings don’t stop with optimizing storage with Sentinel Data Lake, Microsoft rolled out new pricing options for Sentinel. These include a new 50GB daily ingestion commitment tier and pre-purchase plans that offer predictable billing and volume discounts.

For organizations scaling up their Sentinel usage, these models provide more flexibility and better cost control.  For most organizations, this presents a clear opportunity to reduce costs.  Allowing for savings of 5-45% based on the tier. 

For our ThreatDefender clients, these changes allow us to offer more competitive packages by reducing your Sentinel costs in storing data.  After all, our platform is built on you owning your data without vendor lock-in.  Optimizing that cost makes managed and co-managed security even more affordable.  Whether clients are building their own SOC or partnering with a provider, understanding these pricing options is key to maximizing value. 

ThreatDefender: Accelerate Your Sentinel Journey

As a Microsoft Verified MSSP, we’ve built our ThreatDefender solution to help clients operationalize Sentinel quickly and effectively. For some, the best approach is to build their own environment with our guidance. For others, a co-managed or fully managed model delivers faster results and lower overhead. 

We offer Sentinel Optimization Workshops to assess readiness, design future-state architectures, and support migration efforts. Our managed detection and response services are built around Microsoft security with Microsoft best practices in mind.  Enabling you to own your data and access security experts to extend your team or act as your team. e extending your security team with Microsoft-certified experts.

Final Thoughts

Agentic AI is a powerful tool in the evolution of threat detection and response. It doesn’t replace your security team; it makes them better (and faster) at securing your business.  The evolution of Sentinel from a technical standpoint as well as timely cost optimizations is making this capability an affordable reality. 

Whether you are building your own Sentinel environment or evaluating a managed solution, we can help. ThreatDefender is designed to deliver 24×7 security with Microsoft Sentinel at its core. Let’s talk about how we can support your security journey and stay out in front of the evolution of these platforms. 

Secure Your Organization in the Agentic Era

Modernize your Microsoft Sentinel environment with AI-driven visibility, automation, and cost control.

Whether you’re building your own SOC or exploring managed options, our experts can help you stay ahead of evolving threats.

In my previous post on Recovery Plans, I explored how Nutanix orchestrates the failover process with automated boot sequencing and network mapping. But not all failovers are created equal. The approach you take and the automation Nutanix provides will differ depending on whether you’re executing a planned migration or responding to an actual disaster.

Understanding the distinction between planned and unplanned failovers is critical for setting the right expectations around data loss, recovery time, and operational procedures. Let’s dive into how Nutanix DR handles each scenario.

The Fundamental Difference

The core distinction between planned and unplanned failovers comes down to one simple question: Is the primary site still accessible?

Planned Failover assumes your primary site is operational and you have time to orchestrate a clean migration. This might be for datacenter maintenance, infrastructure upgrades, or disaster avoidance (like an approaching hurricane).

Unplanned Failover assumes your primary site is down or unreachable due to an actual disaster, power failure, natural disaster, cyberattack, or other catastrophic event. You’re working from the last replicated snapshot, and time is critical.

This fundamental difference drives everything else about how these operations execute.

Planned Failover: Zero Data Loss Migration

When you initiate a planned failover with Nutanix DR, you’re telling the system, “I have time to do this right.” Nutanix automates the entire orchestration through Prism Central.

The Nutanix Planned Failover Process

Let’s take a quick look at the sequence of activities that are executed during a Planned Failover with Nutanix DR:

Source VMs Gracefully Powered Down

The first step in the planned failover process is to gracefully shut down the guest VMs running at the primary site. Nutanix leverages standard operating system shutdown procedures to ensure a clean and orderly closure of all applications and services.

• Operating System Integration: Nutanix communicates with the guest operating systems using tools like Nutanix Guest Tools (NGT) or standard OS commands to initiate the shutdown process.
• Application Consistency: This graceful shutdown allows applications to properly close files, commit transactions, and finalize any pending operations. This is crucial for maintaining data consistency and preventing data corruption.
• Minimized Data Loss: By allowing applications to shut down cleanly, the risk of data loss or inconsistencies is significantly reduced. This ensures that the migrated workloads start up in a stable and reliable state at the recovery site.

Final Snapshot Created

After the successful shutdown of the guest VMs, Nutanix creates a final recovery point, also known as a snapshot. This snapshot captures the absolute latest state of the workloads, ensuring that no data is lost during the failover process.

• Point-in-Time Recovery: The final snapshot provides a precise point-in-time image of the VMs’ disks and memory (if configured for memory snapshots).
• Zero Data Loss: This snapshot guarantees that every bit of data up to the moment of shutdown is preserved. This is a critical aspect of planned failover, as it ensures that the recovery site has an exact replica of the primary site’s data.
• Data Integrity: The snapshot is created in a consistent state, reflecting the clean shutdown of the applications and operating systems. This ensures that the recovered VMs are in a usable and reliable state.

Final Replication

Once the final snapshot is created, it is replicated to the recovery site. Nutanix uses the Protection Policy settings configured for the VMs to determine how the replication is performed.

• Protection Policy Settings: The Protection Policy defines parameters such as compression, deduplication, and encryption for the replication process. These settings optimize the transfer of data while ensuring security and efficiency.
• Compression and Deduplication: Compression reduces the amount of data that needs to be transferred, while deduplication eliminates redundant data blocks. These techniques minimize bandwidth usage and accelerate the replication process.

Source VMs Deleted

After the successful replication of the final snapshot to the recovery site, the original VMs are removed from the primary cluster. This step is crucial to prevent split-brain scenarios, where the same VM could accidentally run in both locations simultaneously.

• Split-Brain Prevention: Deleting the source VMs ensures that there is only one active instance of each VM at any given time. This eliminates the risk of data inconsistencies and conflicts that can arise from running the same VM in multiple locations.
• Automatic Cleanup: The deletion process is automated as part of the planned failover workflow, reducing the risk of human error and ensuring that the primary site is properly cleaned up.
• Resource Optimization: Removing the VMs from the primary site frees up resources that can be used for other purposes, such as running test workloads or performing maintenance tasks.

Recovery Site Activation

The final step in the planned failover process is to activate the VMs at the recovery site. This involves creating the VMs from the final snapshot and powering them on according to the Recovery Plan’s boot sequencing.

• VM Creation: Nutanix creates new VMs at the recovery site using the data from the final snapshot. These VMs are configured with the same settings as the original VMs, including CPU, memory, and disk configurations.
• Boot Sequencing: The Recovery Plan defines the order in which the VMs are powered on. This is important for ensuring that applications and services start up in the correct sequence, with dependencies properly resolved. The boot sequence is typically organized into stages (Stage 0, Stage 1, etc.), with each stage containing a group of VMs that need to be started in a specific order.
• Network Mapping: Network mappings are automatically applied to the VMs, ensuring that they are connected to the correct networks at the recovery site. This allows the VMs to communicate with each other and with external resources.
• In-Guest Script Execution: Any configured in-guest scripts are executed after the VMs are powered on. These scripts can be used to perform tasks such as updating DNS records, configuring application settings, or running custom initialization routines.
• Verification: After the VMs are activated, it is important to verify that they are functioning correctly and that all applications and services are running as expected. This may involve performing functional testing, checking logs, and monitoring performance metrics.

Executing Planned Failover in Prism Central

The actual execution workflow is straightforward:

1. Connect to Prism Central at the recovery site
2. Navigate to Data Protection > Recovery Plans
3. Select your Recovery Plan and click Actions > Failover
4. Choose Planned Failover as the failover type
5. Type “Failover” in the confirmation field and click Failover

Nutanix displays real-time progress through each stage. VM shutdown status, snapshot creation, replication progress, and recovery site activation. The Last Failover Status column shows “Succeeded” when complete.

Key Characteristics of Planned Failover

• Zero Data Loss Guaranteed – RPO is effectively zero because the final snapshot includes all data up to shutdown. This isn’t estimated—it’s guaranteed.
• Clean Application State – Applications shut down properly using guest OS procedures, reducing corruption risk and ensuring consistency.
• Time Investment Required – The graceful shutdown, final snapshot, and replication adds time. Duration depends on the final change size and available bandwidth.
• Requires Primary Site Access – The primary cluster must be online and accessible. If the site is down, you must use unplanned failover instead.
• Automatic Source Cleanup – Original VMs are automatically removed, preventing accidental dual operation.

When to Use Planned Failover

Planned failover is ideal for:

• Scheduled datacenter maintenance windows
• Infrastructure migrations between sites
• Evacuating ahead of predicted disasters (hurricanes, planned power outages)
• Compliance scenarios requiring documented zero-data-loss migration
• DR testing with complete data validation

Unplanned Failover: Speed Over Perfection

Unplanned failover operates under very different assumptions. Your primary site is down. You need applications running now. There’s no time for graceful shutdowns or final snapshots. Nutanix prioritizes speed and availability.

The Nutanix Unplanned Failover Process

Let’s take a quick look at the sequence of activities that are executed during a Unplanned Failover with Nutanix DR:

Latest Available Snapshot Identified

The first step in the Nutanix DR process is to identify the most recent replicated recovery point at the DR site. This recovery point represents a snapshot of the VMs and their data at a specific point in time. The age of this snapshot, and therefore the potential data loss window, is determined by your Protection Policy Recovery Point Objective (RPO).

• Near-Sync Replication: For applications requiring the lowest possible RPO, Nutanix offers Near-Sync replication, which can achieve RPOs as low as 1 minute. This means that in the event of a disaster, the maximum data loss would be limited to one minute’s worth of changes.
• Asynchronous Replication: For less critical applications, asynchronous replication is a common choice. This typically involves replicating data on an hourly or daily basis, resulting in RPOs of 1 hour or more.

The system automatically identifies the most recent consistent snapshot that has been successfully replicated to the DR site. This ensures that the recovered VMs are based on the most up-to-date data available.

Recovery Point Cloned

Once the latest available snapshot is identified, Nutanix clones it using its efficient redirect-on-write technology. This cloning process is crucial for minimizing recovery time.

• Redirect-on-Write: Instead of creating a full copy of the snapshot data, redirect-on-write creates a lightweight clone that initially shares the same data blocks as the original snapshot. Any subsequent writes to the cloned VMs are redirected to new blocks, leaving the original snapshot intact.
• Instant VM Creation: This approach allows VMs to be created almost instantly, without the need to wait for a full data copy. The VMs use metadata to reference the data stored in the snapshot. This significantly reduces the time required to bring the VMs back online.

VMs Created and Powered On

With the snapshot cloned, the next step is to create and power on the guest VMs at the recovery site. This process is guided by a Recovery Plan, which defines the order in which VMs should be started and any necessary network configurations.

• Boot Sequencing: The Recovery Plan defines the order in which the VMs are powered on. This is important for ensuring that applications and services start up in the correct sequence, with dependencies properly resolved. The boot sequence is typically organized into stages (Stage 0, Stage 1, etc.), with each stage containing a group of VMs that need to be started in a specific order.
• Network Mapping: Network mappings are automatically applied to the VMs, ensuring that they are connected to the correct networks at the recovery site. This allows the VMs to communicate with each other and with external resources.
• In-Guest Script Execution: Any configured in-guest scripts are executed after the VMs are powered on. These scripts can be used to perform tasks such as updating DNS records, configuring application settings, or running custom initialization routines.
• Verification: After the VMs are activated, it is important to verify that they are functioning correctly and that all applications and services are running as expected. This may involve performing functional testing, checking logs, and monitoring performance metrics.
• Independent Operation: Importantly, this entire process occurs independently of the primary site. No communication with the primary site is required or attempted. This is critical in a disaster scenario where the primary site is inaccessible.

Accept Data Loss Window

A critical aspect of any disaster recovery strategy is understanding the potential for data loss. In the event of a disaster, any changes made to the VMs after the last successful replication to the DR site will be permanently lost.

• RPO as the Limiting Factor: The amount of data loss is directly determined by your RPO. If your RPO is 1 minute, the maximum data loss will be 1 minute’s worth of changes. If your RPO is 1 hour, the maximum data loss will be 1 hour’s worth of changes.
• Unavoidable Loss: This data loss is unavoidable when the primary site is completely inaccessible. However, by carefully selecting an appropriate RPO for each application, you can minimize the potential impact of data loss.

Executing Unplanned Failover in Prism Central

The execution is similar to planned failover, but faster:

1. Connect to Prism Central at the recovery site
2. Navigate to Data Protection > Recovery Plans
3. Select your Recovery Plan and click Actions > Failover
4. Choose Unplanned Failover as the failover type
5. Type “Failover” in the confirmation field and click Failover

Nutanix immediately begins activating VMs at the recovery site without attempting to contact the primary cluster. Progress is tracked in real-time through the Recovery Plan dashboard.

Key Characteristics of Unplanned Failover

• Bounded Data Loss – Maximum data loss equals your Protection Policy RPO. If you replicate every 5 minutes (Near-Sync), you lose at most 5 minutes. If you replicate hourly (Async), you lose at most 1 hour.
• Fast Execution – No waiting for shutdowns or final replication. Recovery starts immediately from the last snapshot.
• No Primary Site Dependency – Works even when the primary site is completely unreachable, offline, or destroyed.
• Crash-Consistent Recovery – VMs restore from snapshots that captured a point-in-time state. Application-aware VSS snapshots (Windows) or pre/post-scripts help ensure application consistency.
• Post-Recovery Protection – After unplanned failover, create a new Protection Policy to take local snapshots of the now-production VMs at the recovery site.

When to Use Unplanned Failover

Unplanned failover is designed for:

• Actual disaster scenarios (site failure, power loss, natural disaster)
• Network connectivity loss to the primary site
• Primary cluster failures that prevent graceful shutdown
• Time-critical situations where speed matters more than the last few minutes of data
• Testing realistic disaster response and measuring actual RTO

Recovery Point Selection Limitations

An important distinction between planned and unplanned failover is recovery point selection:

Planned Failover

• You cannot select a past recovery point
• The failover always uses the final snapshot created during the planned failover process
• This ensures zero data loss and the most current state
• There’s no option to “go back in time” to an earlier snapshot

Unplanned Failover

• You can select from available recovery points
• Nutanix presents a list of replicated snapshots at the recovery site
• You can choose a specific point-in-time if needed (for example, before a ransomware attack)
• This flexibility is critical for disaster scenarios where the most recent data may be corrupted

This difference reflects the use cases: planned failover assumes you want the latest, cleanest state. Unplanned failover acknowledges that sometimes the most recent snapshot isn’t the one you want to recover—especially in cyberattack or corruption scenarios.

The RPO Reality Check

Unplanned failover forces you to live with your Protection Policy RPO. If you configured hourly replication to save on bandwidth and storage, you accept up to 1 hour of data loss during a real disaster. If that’s unacceptable, you need Near-Sync (1-15 minute RPO) or Synchronous replication (zero RPO).

This is why testing unplanned failover is critical—it validates whether your RPO settings actually align with business requirements when you lose data for real.

Cross-Cluster Live Migration: An Alternative to Planned Failover

For environments where even planned downtime is unacceptable, Nutanix offers cross-cluster live migration as an alternative to traditional planned failover. While technically a planned failover activity, it operates differently enough to warrant its own discussion.

How It Works

• VMs migrate while remaining powered on and accessible
• Storage replication happens in real-time during migration
• Network connectivity transitions seamlessly to the destination cluster
• Users experience minimal to no service interruption

The Trade-Off: Time

Cross-cluster live migration is significantly more time-consuming than planned failover:

• Large VMs with active workloads can take hours to migrate
• Network bandwidth becomes a critical constraint
• Migration duration is proportional to VM size and change rate
• Multiple VMs migrating simultaneously compound the time requirement

When to Consider Live Migration

• Zero-downtime requirements for mission-critical applications
• Datacenter evacuations where services must remain online
• Infrastructure migrations during business hours
• Applications that cannot tolerate even brief outages

For most DR scenarios, the planned failover approach (with graceful shutdown) is faster and more efficient. Live migration is a premium option reserved for workloads where availability truly cannot be interrupted.

Nutanix-Specific Considerations

Beyond the basic planned vs unplanned distinction, Nutanix DR includes several technical considerations that affect failover behavior.

Replication Type Impact

Your Protection Policy replication type influences failover characteristics:

Asynchronous Replication (1-24 hour RPO)

• Planned failover waits for final snapshot replication (could add significant time)
• Unplanned failover uses the last scheduled recovery point (data loss up to RPO)
• Best for workloads tolerant of hours of data loss

Near-Synchronous Replication (1-15 minute RPO)

• Planned failover final snapshot typically replicates quickly
• Unplanned failover loses at most 15 minutes of data
• Balances data protection with bandwidth efficiency

Synchronous Replication (Zero RPO)

• Planned failover still follows graceful shutdown process
• Unplanned failover with witness enables automatic failover (Metro Availability)
• Both modes achieve zero data loss, but unplanned is faster

Witness and Automatic Failover

For Synchronous replication with Metro Availability, Nutanix supports automatic unplanned failover:

• External witness cluster monitors site availability
• When primary site fails, witness triggers automatic unplanned failover
• Recovery Plans execute automatically without human intervention
• Minimizes RTO by eliminating human detection and response time

This is the only scenario where failover can execute automatically. All other configurations require manual initiation through Prism Central.

Post-Failover State Management

After any failover (planned or unplanned), important state changes occur:

Recovery Plan Status

• The Recovery Plan enters “Failover” state at the recovery site
• VMs are now “active” at the recovery location
• The primary site (if accessible) shows entities as “inactive”

Protection Policy Behavior

• Existing Protection Policy from primary to recovery site becomes inactive
• You should create a new Protection Policy at the recovery site for local snapshots
• If the primary site comes back online, configure reverse replication for eventual failback

Network Configuration

• Production network mappings apply automatically
• VMs connect to recovery site networks as defined in the Recovery Plan
• In-guest IP addresses remain unchanged (unless modified by guest scripts)
• DNS and routing may require manual updates depending on your architecture

Test Failover: The Third Option

While not a “real” failover, Nutanix also supports Test Failover:

• Uses metadata to clone the latest snapshot
• Creates VMs on isolated test networks
• Allows validation without affecting production or DR readiness
• Cleanup is simple—just delete test VMs when done

Test failover uses the same snapshot cloning technology as unplanned failover, but operates in complete isolation. This lets you validate both planned and unplanned scenarios without risk.

Choosing the Right Approach

The decision between planned and unplanned failover isn’t always obvious. Here’s guidance:

Use Planned Failover When:

• Performing scheduled datacenter maintenance
• Migrating infrastructure between sites
• Evacuating ahead of predicted disasters (severe weather forecasts)
• Testing full DR capabilities with zero data loss
• Compliance requires zero-data-loss migration validation

Use Unplanned Failover When:

• Primary site is completely down or unreachable
• Network connectivity to primary site is lost
• Time is critical, and you can’t wait for graceful shutdown
• Testing realistic disaster response and measuring actual RTO
• Validating whether your RPO settings are actually acceptable

Impact on Recovery Objectives

These two approaches directly impact your DR metrics:

Recovery Point Objective (RPO)

• Planned Failover: Zero data loss (RPO = 0)
• Unplanned Failover: Data loss up to Protection Policy RPO

Recovery Time Objective (RTO)

• Planned Failover: Longer due to shutdown and final replication
• Unplanned Failover: Faster, immediate activation from the last snapshot

Understanding this trade-off helps set realistic expectations. Planned failover optimizes for data integrity. Unplanned failover optimizes for speed.

What About Failback?

Both planned and unplanned failovers can be reversed through failback operations, returning workloads to the original primary site once it’s restored. The failback process mirrors the failover approach:

• Planned Failback follows the same graceful process as planned failover
• Unplanned Failback uses the last available snapshot if the current recovery site fails

We’ll explore failback procedures, considerations, and best practices in detail in Part 8 of this series.

The Power of Choice

What makes Nutanix DR powerful is that you have both options available through the same Recovery Plan. You don’t need separate runbooks or procedures. The Recovery Plan orchestration remains the same, only the execution mode changes based on your circumstances.

This flexibility means you can:

• Test with planned failover to validate zero data loss migration
• Practice unplanned failover to measure realistic disaster response
• Choose the appropriate mode when the actual need arises

Your Protection Policies define the data availability foundation. Your Recovery Plans define the orchestration. And the failover mode you select determines the balance between speed and data integrity.

What’s Next in the DR Series

In this post, we’ve explored the critical differences between planned and unplanned failover operations. In the next installment, we’ll dive into failback operations and DR testing strategies, how to return to normal operations, and how to validate your DR capabilities without impacting production.

Understanding when and how to use each failover type is essential for effective disaster recovery. The right choice depends on your circumstances, but having both options automated and ready to execute gives you the flexibility to respond appropriately, whether you’re dealing with planned maintenance or an actual catastrophe.

Strengthen Your Disaster Recovery Strategy

Ensure your business stays resilient with the right mix of planned and unplanned failover strategies. Our experts can help you validate RPO/RTO goals and optimize Nutanix DR performance for real-world recovery scenarios.

On October 16, 2025, we hosted Day 3 of the Fall Microsoft Virtual Roadshow, focused on Microsoft 365 productivity and security.

If you missed it, the recording is available in our Events OnDemand Library– feel free to share with your teams and watch segments on demand.

This recap summarizes hours of content into compact sections, clear recommendations, and actionable takeaways. We emphasized several cross-cutting themes: reducing administrative burden, preparing employees and technology to be AI-ready, strengthening security and compliance, and elevating the employee experience.

1. Make Every Employee & System AI-Ready

We explored how Copilot is evolving from a single assistant to an ecosystem of agents– retrieval, task, and autonomous—plus practical paths to build them with Copilot Studio and Azure AI.
Topics included Copilot Memory & Custom Instructions, license/consumption options, and the Copilot Control Center for governing lifecycle, metering, and permissions.

We also reviewed how to enable enterprise brand images for PowerPoint Copilot to keep presentations on brand.

Key Takeaways

• Prioritize an AI operating model with business sponsorship, change enablement, and technical readiness so agents deliver real value, not just demos.
• Choose the right build path per use case: Copilot prompts for quick wins, Copilot Studio for departmental agents, Azure AI Foundry for advanced patterns.
• Establish governance early with license/metering visibility, connector permissions, and agent lifecycle management.

2. Secure Data for AI with Purview, DSPM, & Adaptive Controls

We covered Microsoft’s integrated approach to Data Security, including Information Protection, DLP, Insider Risk Management, Data Security Investigations, and Data Security Posture Management (DSPM) to continually harden protections as AI usage expands.

For rollouts to stick, start from Microsoft’s deployment patterns and blueprints, and use eGroup’s eQIP model. Two resources to explore:

• Purview Deployment Blueprint
• Securing Your Data with Microsoft Purview: A Practical Handbook

Key Takeaways

• Treat labels as signals—they drive DLP, Insider Risk, DSPM, and AI grounding.
• Use DSPM + Investigations to find exposure hotspots and speed up AI-assisted triage.
• Implement secure-by-default labeling and iterate—don’t wait for a perfect taxonomy.
• Review the Secure by Default with Microsoft Purview model to modernize labeling at scale.

3. SharePoint Governance, AI-Assisted Content, & Resilient Backup

We demonstrated practical ways to prepare your tenant for Copilot and content growth using Content Management Assessment (CMA) dashboards to surface site health and over-permissioned areas; AI Actions in document libraries; Copilot-powered page sections; and enterprise image libraries for compliant AI-generated content.

We also compared Microsoft 365 Backup (first-party backup for SharePoint, OneDrive, Exchange) with third-party options.
Microsoft 365 Backup is consumption-based ($0.15/GB/month), supports rapid restore, and offers point-in-time rollback.
See: Microsoft 365 Backup Overview and Microsoft 365 Backup Pricing.

Key Takeaways

• Use CMA dashboards to remediate oversharing and prepare for Copilot.
• Turn on AI Actions to refine or generate content—always review before publishing.
• Adopt Microsoft 365 Backup for speed, coverage, and granular restore.

4. Employee Experience at Scale — Teams Phone and Teams Rooms

We examined how consolidating calling and meetings in Microsoft Teams reduces complexity and costs while improving user satisfaction.

Key updates included the Teams Phone Queues app and why Teams Rooms (MTR) remain a force multiplier for hybrid collaboration.

For planning, we recommended these resources:

• Teams Rooms & Devices Feature Comparison
• Teams Rooms Licenses (Basic vs Pro)
• Third-Party Meetings on Teams Rooms

Key Takeaways

• Standardize on Teams Phone + Teams Rooms to simplify your tech stack.
• Use the comparison and licensing guides to right-size each room.
• Enable third-party join but verify invites for executive meetings.

5. Operational Excellence: Identity Lifecycle Automation and Unified SecOps

We highlighted how Microsoft Entra ID Governance automates joiner/mover/leaver processes with Lifecycle Workflows, access reviews, and just-in-time controls—reducing tickets and access risk while giving employees day-one productivity.
See: Create Lifecycle Workflows and Understand Lifecycle Workflows.

We also discussed the Sentinel → Microsoft Defender portal transition, which unifies SIEM and XDR operations.
New workspaces are onboarding directly to Defender, and the Azure portal view will retire on July 1, 2026.

Key Takeaways

• Implement Entra ID Governance Lifecycle Workflows to automate JML and close access gaps.
• Pair identity governance with data-centric controls (labels, DLP, Insider Risk).
• Align SOC processes to the Defender portal ahead of the 2026 deadline—see Transition Your Microsoft Sentinel Environment to Defender.

What’s Next?

Day 3 underscored a simple pattern: prepare people and platforms for AI, secure the data that powers it, simplify the estate, and automate what used to be manual.
If you’d like a deeper dive or help with sequencing these steps, evaluating Copilot use cases, deploying Purview controls, modernizing Teams Phone and Rooms, or automating JML with Entra– eGroup is here to help you stay ahead and get the most from Microsoft’s latest innovation.

Build Your Microsoft 365 Roadmap for AI, Security, & Productivity

Ready to turn these insights into action? Our Microsoft 365 Roadmap engagement helps you assess your current environment, define priorities across collaboration, security, and AI, and chart a clear path forward. Transform what you learned from the Roadshow into a modernized, AI-ready strategy tailored to your organization.

Welcome to a deep dive into one of the most pressing topics in IT infrastructure today: migrating from VMware to Nutanix AHV.

If you’re reading this, you’re probably wrestling with the same questions our panel tackled recently. What’s next for VMware under Broadcom, how do you manage rising costs, and is Nutanix AHV really a viable alternative?

This post is a direct reflection of our August 2025 virtual panel discussion, where I had the privilege of moderating a candid conversation with three IT leaders who’ve lived through the migration journey. We skipped the slides and got straight to the real talk of what worked, what didn’t, and what you need to know if you’re considering a similar move.

Setting the Stage: Why This Discussion Matters

Let’s be honest – uncertainty around VMware’s future has been a cloud over the industry for two years. Licensing changes, price hikes, and shifting product features have forced organizations to rethink their virtualization strategies.

As mentioned at the start of the panel, “What is Broadcom doing with VMware? Prices are going up, licensing is changing, and product features and functionality are shifting.” The result? IT leaders are searching for alternatives that offer cost savings, simplicity, and agility.

Our goal for this session was simple: share practical advice and real-world insights from organizations that have already made the move to Nutanix AHV, or are actively evaluating it. No bashing, just realism about the state of the industry and what’s possible.

Meet the Panelists

I was joined by three customers from diverse industries, each with a unique perspective:

• Cody Reimers, Albany County Sheriff’s Department (Public Safety)
• Scott Ziegler, RPWB, Rogers, Patrick, Westbrook and Britton (Legal)
• Devin Costa, Jones Onslow Electric Membership Corporation (Utilities)

Each panelist brought hands-on experience with Nutanix AHV and different stages of adoption; some fully migrated, some running mixed environments, all with valuable lessons to share.

Decision-Making:
Why Move to Nutanix AHV?

Cost Savings and Simplicity

Cody kicked things off with the core reason for their migration:

“The biggest point was the renewal costs. We were seeing where Broadcom was going, and what the renewal costs were coming in as. What we really liked was the demo of Nutanix AHV, not only the cost savings, but also the overall management and simplicity. It still provided the same functional services we were doing.”

Devin echoed this, highlighting the licensing model:

“With Nutanix, you get AHV basically for free. We were already running Nutanix hardware, so it wasn’t an issue. Why not take advantage of that and save a little bit of money?”

Overcoming Hesitancy

Migrating critical services, especially in public safety, comes with risks. Cody admitted, “We were concerned about the sustainability and how well it would continue to operate in the event of a disaster or outage. But it was very simple to deploy. We had it up in a matter of hours and were building out the new environment. It was far easier than operating with VMware.”

Devin added, “There was really nothing that we can’t do in AHV that we weren’t already doing in VMware. So why not move forward?”

Risk Management and Planning

Scott’s firm faced not only VMware costs but also hardware renewal. “Our PowerEdge servers were long in the tooth, about six years old, and starting to show their age. We needed to expand, and were running out of memory. Migrating to AHV meant we could consolidate and simplify,” Scott shared.

The migration was carefully planned to minimize downtime. “From the user’s perspective, there was never any downtime. We migrated 120 VMs, and the staged rollout was pretty painless. I expected it to be a lot worse,” Scott said. He credited the Nutanix Move tool and expert support for the smooth transition.

Devin and Cody both emphasized the importance of disaster recovery (DR) and business continuity. Nutanix’s native DR functionality allowed for live disaster testing and seamless failover, critical for organizations that operate 24/7.

Day Two: Life After Migration

Performance and Stability

One of the most immediate benefits was improved performance. Scott reported, “Citrix logins went from 30 seconds to under 20 seconds internally, which is crazy. We’ve never had that fast before. External users saw similar improvements, and nothing changed on the network side.”

Devin agreed, “End users expressed how much faster it was and how much quicker it responded. It was a game-changer. When end users say, ‘Hey, this is working fast,’ you know you’re doing something right.”

Operational Efficiency

Patch and firmware lifecycle management became dramatically simpler. Cody described, “It has saved hours upon hours of my life. Now I just go into Prism Element or Prism Central, run my updates, and it does everything autonomously. I don’t have to do each individual host one at a time. It handles it all. It has saved hundreds of hours.”

Devin added, “We do a lot of it during the day. We don’t have to schedule time after hours. We get so many man hours back in our day.”

Disaster Recovery and Data Protection

Cody shared his experience moving from Zerto to Nutanix DR services. “I had a lot of challenges with Zerto. When I built DR into Nutanix, it was very straightforward. It gives you the ability to test a failover without actually performing a failover and tells you why it’s failing without causing any impact. Everything remained operational throughout that time period.”

Network mapping and IP changes were handled smoothly, with Nutanix offering both manual and automatic options. “You tell it what VLAN or subnet you want, and it will move it there and automatically assign as long as you have those features in place,” Cody explained.

Regarding Recovery Point Objective (RPO) and Recovery Time Objective (RTO), Cody found Nutanix competitive. “We didn’t notice any significant changes. Nutanix DR can go down to one-minute RPOs, and there are three different types of DR strategies—async, near sync, and metro sync—so you can craft it to what you need.”

Unified Storage and Infrastructure

Scott’s firm moved away from NetApp to Nutanix Unified Storage. “Sometimes it felt like you needed a PhD to operate NetApp. We didn’t need high IO for files, so why spend tons of money on NetApp when we can get what we need and still get good performance out of Nutanix?”

The migration resulted in significant savings in rack space and power. “We saved about 14U in rack space. It’s crazy how much space is in our rack now. We were looking at having to upgrade our PDU because we had too much stuff, and now we can stick with what we’ve got,” Scott said.

Cloud Integration and Future Plans

Devin’s organization is leveraging Azure VMware Solution (AVS) as a DR target, with plans to expand cloud integration. “We’re on the East Coast of North Carolina, affected by hurricanes. AVS seemed like a good fit. We can have our secondary systems up and running in the cloud environment, alleviating downtime. We have outage management systems that have to be up 24/7, 365,” Devin explained.

Scott mentioned their use of Nutanix Files today and is interested in extending those capabilities into Azure. With Nutanix Files now running natively in Azure, he can seamlessly replicate file data from his on-premises Nutanix Files deployment to Nutanix Files in Azure. This provides a consistent management experience across environments and supports scenarios such as cloud-based disaster recovery, data mobility, and long-term workload modernization.

Key Takeaways and Advice

As we wrapped up, I summarized the common themes:

• Flexible IT infrastructure that grows as needed
• Seamless adoption and simplified management
• Cost savings and predictable licensing
• Deeper automation and operational efficiency
• Integrated disaster recovery and business continuity

Each panelist shared their next steps:

• Cody: “A little bit of it all – adding security and additional workloads.”
• Scott: “We’re kind of done. Nothing left to do other than maintenance, so now I can sleep well at night.”
• Devin: “We recently purchased Data Lens for visibility into our file system. Excited about Nutanix Files in Azure and new DR strategies.”

Conclusion

Migrating from VMware to Nutanix AHV is not just a technical shift, it’s a strategic move that can deliver cost savings, operational simplicity, and future-proof flexibility. The experiences shared by Cody, Scott, and Devin demonstrate that with careful planning, expert support, and the right tools, organizations can navigate the migration with minimal disruption and maximum benefit.

Whether you’re facing rising VMware costs, seeking to simplify your environment, or planning for cloud integration and disaster recovery, Nutanix AHV offers a compelling alternative. As I concluded, “Not every workload is made for Nutanix, just like not every workload is made for the cloud. The key is understanding your environment, evaluating your options, and crafting a migration strategy that fits your needs.”

If you’re considering a migration, hands-on workshops and modernization assessments can help you understand what makes sense for your organization. The journey may be complex, but with the right partners and insights, it can be transformative.

Ready to Explore Your VMware to Nutanix AHV Migration?

Discover how eGroup can help you simplify infrastructure, reduce costs, and modernize your virtualization strategy with confidence.

During our Fall Microsoft Virtual Roadshow, we spent several hours diving into the realities of Data & AI transformation. Our six-part discussion focused on practical strategies, real-world challenges, and most importantly, the people side of transformation.

If you missed the live sessions, the recordings are available– and if you want a summary of what we discussed, then read on and learn how you can take the next step in your AI journey.

Part 1: AI Today– Moving From Learning to Action 

We kicked off the afternoon by acknowledging a simple truth: AI is no longer just hype, it’s here to stay, but the “magic” is evolving. Organizations are moving from curiosity to experimentation, and the real value comes when technology is grounded in business process improvement, not just deployed for its own sake. 

What We Discussed: 

• The evolving landscape of AI– moving past the initial hype. 

• Why process-driven use cases matter more than technology alone. 

• Data modernization as a critical companion to AI adoption. 

• The importance of managing expectations and embracing continuous improvement. 

Key Takeaways: 

• AI is a journey, not a destination. Progress happens in stages. 

• Success depends on aligning technology with real business needs. 

• Use cases drive value; don’t deploy AI just for the sake of it. 

• Mix and match tools. Sometimes automation is the answer. 

How eGroup Can Help: 
We offer AI education, strategy workshops, and hands-on training to help you move from learning to action. Let’s map your AI journey together and align technology to your business goals. 

Part 2: AI Strategy & Enablement 

With the landscape set, we shifted to what it takes to make AI work for your organization. Leadership sponsorship, pragmatic governance, and a clear strategy are critical. 

What We Discussed: 

• The essentials for AI success: responsible principles, leadership, and technical readiness. 

• Our five-step blueprint for launching AI: charter, Copilot Chat, Center of Excellence, use case inventory, and ROI measurement. 

• The role of executive sponsorship and cross-functional councils. 

• Building a culture of innovation and continuous improvement. 

Key Takeaways: 

• Leadership and governance are critical for sustained AI success. 

• Responsible AI is built with Microsoft tools– privacy, fairness, inclusiveness, transparency, and accountability. 

• Quick wins and honest communication build trust and momentum. 

• Start small, celebrate success, and reinvest in longer-term projects. 

How eGroup Can Help: 
We’ll help you establish your AI charter, build a Center of Excellence, and deploy Copilot Chat to drive safe, effective adoption. Our team supports strategy, governance, and user enablement for long-term results. 

Part 3: AI Readiness & Organizational Change 

No technology succeeds without people. This session, led by our OCM practice leader, Hayley Meese-Cherry, focused on the human journey, addressing excitement, skepticism, and the need for ongoing enablement. Change management isn’t just training; it’s about nurturing employees through the transition and reinforcing new behaviors. 

What We Discussed: 

• Assessing readiness across technology, proficiency, funding, and human capital. 

• The emotional journey of AI adoption– addressing excitement, fear, and skepticism. 

• Role-based learning, champion networks, and ongoing reinforcement. 

• The difference between change management and training. 

Key Takeaways: 

• Change management is about nurturing employees, not just training. 

• Involve employees early; champions drive grassroots adoption. 

• Tailor learning to roles and pain points for maximum relevance. 

• Continuous improvement and feedback loops sustain momentum. 

How eGroup Can Help: 
Our Organizational Change Management team helps you assess readiness, build champion networks, and design reinforcement programs for lasting AI adoption. We guide your people through every step of change. 

Part 4: Security, Compliance & Trust in the AI Era 

Security remains top of mind as organizations embrace AI. We explored practical steps to secure data, retrain users, and deploy solutions without waiting for perfection. The message was clear: bad data leads to bad AI, and security demands ongoing attention, not a one-time fix.

What We Discussed: 

• How AI honors existing security settings. Secure environments result in secure AI. 

• The importance of retraining users to prevent security risks. 

• Deploying AI while securing content– don’t wait for perfection. 

• Data governance, Purview label policies, and SharePoint management. 

Key Takeaways: 

• Bad data leads to bad AI. Clean, govern, and protect your data sources. 

• Security is a journey; Hybrid approaches balance protection and productivity. 

• Copilot and custom agents offer different security models (exclusion vs. inclusion). 

• Multiple layers of agent security: access, content, permissions. 

How eGroup Can Help: 
We’ll help you implement Purview, secure your Microsoft 365 environment, and deploy Copilot Chat and custom agents safely. Our security assessments and user training build trust and compliance. 

Part 5: Capturing Data Intelligence 

Next, we turned to Microsoft Fabric, a unified platform for data modernization, analytics, and AI. The focus was on iterative, process-centric approaches that deliver business value quickly and avoid the pitfalls of massive, stalled projects. 

What We Discussed: 

• Microsoft Fabric, a unified platform for data modernization, analytics, and AI. 

• Iterative, process-centric approaches for real business value. 

• Pragmatic governance: lean teams, business ownership, and quick decision-making. 

• Tips for right-sizing Fabric capacity and optimizing costs. 

Key Takeaways: 

• Centralize and streamline data for efficiency and trust. 

• Iterative development delivers value quickly and avoids project fatigue. 

• Governance should be pragmatic, engaged sponsors, and right-sized councils. 

• Data projects must show business value to justify investment. 

How eGroup Can Help: 
Let us guide your data modernization journey: design, implement, and govern your Fabric environment for rapid, measurable business impact. 

Part 6: Modern AI Solution Architectures 

We wrapped up the day by looking at the evolving world of AI solution architectures. The takeaway? There’s no one-size-fits-all. Organizations need to mix and match technologies (Copilot, custom agents, automation, and Azure AI services) based on their unique business needs.

What We Discussed: 

• The evolving landscape of AI solution architectures: generative AI, custom agents, automation, and Azure AI services. 

• Evaluating use cases carefully. Technology should fit the problem. 

• Options for building and buying AI solutions: Copilot, Copilot Studio, and Azure AI Foundry. 

• Cost management strategies: consumption models, licensing, and agent deployment. 

Key Takeaways: 

• Rapid change requires ongoing evaluation and resource allocation. 

• Mix and match AI technologies to fit your unique business needs. 

• Calculate ROI based on licensing the right technology, not always AI. 

• Use cases rule: Ground every solution in real business process improvement. 

How eGroup Can Help: 
Ready to build your AI recipe? We offer consultative sessions to help you discover use cases, design solution architectures, and implement the right mix of AI and automation for your organization. 

Turning Insight into Action

The 2025 Fall Microsoft Virtual Roadshow Day 2: Data & AI brought together leaders, technologists, and change champions united by one goal: to turn innovation into impact. Across every session, one theme echoed: AI transformation succeeds when data, people, and strategy move together.

From foundational readiness to modern solution architectures, eGroup and Microsoft continue to help organizations harness the full power of AI through secure, scalable, and human-centered approaches.

Ready to move from insight to execution?

Whether you’re just starting your AI journey or looking to accelerate adoption, eGroup is here to help. From strategy and governance to technical implementation and change management, our team brings the expertise and practical experience to guide you every step of the way. 

In my previous posts, I’ve covered how Protection Policies ensure your data is continuously replicated and how Recovery Plans orchestrate the failover process to bring applications back online in the right order. You’ve built the infrastructure, configured the policies, and mapped out the recovery sequences.

However, here’s the uncomfortable truth that many organizations need to realize – a disaster recovery plan that hasn’t been tested is just expensive fiction.

I’ve seen it too many times in my career: organizations invest significant resources in DR infrastructure, dutifully replicate data to recovery sites, and confidently present their DR capabilities to leadership and auditors. Then, when disaster actually strikes (or worse, during their first real test), they discover that their carefully designed plans have critical gaps, undocumented dependencies, or configurations that don’t work as expected.

This post is about transforming your DR plan from theoretical documentation into a proven, validated capability that builds organizational confidence and actually works when you need it.

Part 1: Why DR Testing Isn’t Optional Anymore

The Testing Problem in Traditional DR

Traditional disaster recovery testing was painful. Organizations would schedule annual or semi-annual DR tests that required:

• Production Downtime – Shutting down primary systems to test failover
• Risk Acceptance – Real possibility that the test itself could cause outages
• Massive Coordination – Involving dozens of teams across multiple days
• Business Disruption – Users knew when DR tests were happening because services were impacted
• Incomplete Validation – Testing only critical systems because full testing was too disruptive

The result? Many organizations either skipped testing entirely, tested so infrequently that the environment had drastically changed since the last test, or performed such limited testing that it provided false confidence rather than real validation.

The Real Cost of Not Testing

Let me share a scenario I’ve witnessed more than once. An organization has invested millions in DR infrastructure, replicating hundreds of VMs to a secondary datacenter. Their documentation shows Recovery Time Objectives (RTOs) of 4 hours for critical applications. During an actual outage event, they discover:

• The database server had an undocumented dependency on a certificate authority that wasn’t in the recovery plan
• Network mappings worked for most systems, but caused IP conflicts for others
• Application startup sequences that worked perfectly in production failed at the recovery site due to timeout configurations
• Scripts that were supposed to automate DNS updates hadn’t been updated in two years and no longer worked
• The actual RTO turned out to be 16 hours instead of 4 hours

The financial impact? Beyond the obvious revenue loss from extended downtime, there were regulatory compliance violations, damaged customer relationships, and a complete loss of confidence in the DR program. All of these issues were completely discoverable through proper testing – but that testing never happened because it was too disruptive and complex to perform regularly.

Testing Is More Than Validation

DR testing serves multiple critical purposes beyond simply verifying that systems power on at the recovery site.

Runbook Validation and Practice

Your recovery runbooks document the procedures for failover execution, but documentation becomes outdated the moment your environment changes. Regular testing validates that runbooks accurately reflect current configurations, network mappings, dependencies, and procedures. Just as importantly, testing gives your team hands-on practice executing those runbooks before the pressure of a real disaster event.

I can’t emphasize this enough: there’s a massive difference between understanding a procedure intellectually and having successfully executed it under real conditions. Testing transforms theoretical knowledge into practical experience.

Organizational Confidence Building

When leadership asks, “Can we actually recover our critical systems if disaster strikes?”, testing provides evidence-based answers instead of hopeful assumptions. Successful test results give executives, board members, and stakeholders confidence in business continuity investments. Failed tests (and every organization should expect some test failures – that’s why we test) provide the business case for remediation and improvement.

Compliance and Audit Requirements

Regulatory frameworks increasingly mandate not just having DR capabilities, but proving those capabilities through documented testing. Industries like finance, healthcare, and critical infrastructure face specific testing frequency requirements:

• Financial Services – Many regulations require quarterly DR testing with documented results
• Healthcare – HIPAA business continuity requirements include regular testing and validation
• Critical Infrastructure – Regulations may mandate semi-annual or even quarterly testing
• SOC 2 & ISO Certifications – Auditors expect documented, successful DR tests as part of compliance programs

Testing isn’t optional in these environments – it’s a regulatory requirement with real consequences for non-compliance.

Discovering Environmental Changes

Modern infrastructure is dynamic. Applications get updated, new VMs are deployed, network configurations change, and dependencies evolve. The DR plan that worked perfectly six months ago may have critical gaps today. Regular testing is the only way to discover these changes before they impact real recovery operations.

Validating Recovery Time Objectives

Organizations define RTOs based on business requirements, but are those RTOs actually achievable with your current DR configuration? Testing is the only way to validate whether your theoretical RTO of “4 hours” is realistic or if the actual recovery time is closer to 8 or 12 hours. This information is critical for business planning, continuity strategies, and managing stakeholder expectations.

Testing Connectivity and External Dependencies

DR testing isn’t just about your internal infrastructure—it must validate connectivity to all the external systems and services your applications depend on. During an actual disaster scenario, your recovered applications need to communicate with:

• External APIs and SaaS platforms – Can your recovered ERP system still reach payment processors, shipping providers, or cloud services?
• Partner Networks and EDI Connections – Do VPN tunnels, private circuits, or partner integrations work from the recovery site?
• Remote Office Connectivity – Can branch offices and remote workers access recovered systems?
• Internet-Facing Services – Are your public DNS records, SSL certificates, and firewall rules configured for recovery site operations?
• Cloud Service Integrations – Do connections to AWS, Azure, or other cloud platforms function correctly from the DR site?

I’ve seen organizations successfully test internal application recovery only to discover during an actual event that their firewall rules didn’t allow outbound connectivity from the recovery site, or that SSL certificates were pinned to primary site IP addresses. These aren’t hypothetical problems—they’re deployment blockers that turn your 4-hour RTO into a 12-hour troubleshooting marathon.

Testing connectivity means validating that your recovered applications can actually conduct business, not just that they power on successfully.

The Human Side of DR: Testing People and Processes

Here’s the uncomfortable reality most DR plans ignore: what happens when your team can’t physically access the data center during a disaster?

Technology-focused DR testing often assumes that your infrastructure team will be calmly executing recovery procedures from the comfort of the office. Real disasters don’t work that way. Consider these scenarios:

– Geographic Disasters and Access Limitations

When hurricanes, wildfires, floods, or other regional events trigger DR failover, your operations team may be:

• Evacuated From The Area – Unable to reach the primary or recovery data center
• Without Power Or Internet – Trying to execute recovery procedures from mobile devices with spotty connectivity
• Managing Personal Emergencies – Dealing with family safety, property protection, or evacuation logistics while also responsible for business continuity
• Geographically Distributed – Some team members are accessible, others are completely unavailable

– The “Bug Out” Scenario

Organizations need to test whether their DR capabilities work when the team has to “bug out”—executing recovery operations remotely with limited resources:

• Can failover be initiated remotely? Are your DR tools accessible from outside the corporate network? Do VPNs work when primary data centers are offline?
• Is documentation accessible? Are runbooks stored in systems that depend on the infrastructure you’re trying to recover? (I’ve seen this circular dependency failure more than once.)
• Are credentials available? Can the team access password vaults, authentication systems, and privileged accounts from remote locations?
• Do backup communication channels work? When primary email and collaboration tools are down, how does the team coordinate? Are phone trees, backup Slack workspaces, or alternative communication methods established and tested?
• Is the authority chain clear? Who has decision-making authority when senior leadership is unavailable? Are these delegations documented and known to the team?

– Testing Staffing Constraints

Comprehensive DR testing should include scenarios where:

• Only a skeleton crew is available (night/weekend event)
• Key personnel are unavailable (on vacation, sick, or unreachable)
• The team must execute recovery using only documentation, without expert knowledge
• Junior staff who haven’t executed recovery before must follow the runbooks successfully

– The Reality Check

I recommend that organizations occasionally conduct “remote DR tests” where the operations team must initiate and validate failover while physically away from the office, using only remote access tools and documentation they could access during an actual disaster. This type of testing reveals gaps that technical validation alone never catches:

• Documentation that assumes you’re logged into specific systems
• Procedures that require physical access to console ports or management networks
• Dependencies on team members who might be unavailable
• Communication workflows that break when primary systems are offline

The goal isn’t just technical recovery—it’s ensuring your organization can execute that recovery under real-world disaster conditions when access, resources, and personnel may be severely limited.

The Testing Frequency Problem

Traditional DR testing happened annually if organizations were diligent, and sometimes less frequently if they weren’t. That testing cadence is no longer adequate for modern environments.

Consider the rate of change in typical infrastructure:

• Virtual machines are deployed, modified, and decommissioned continuously
• Application updates roll out monthly or even weekly
• Network configurations change to support new services and security requirements
• Dependencies between systems evolve as architectures modernize
• Personnel turnover means different staff executing recovery procedures

By the time your annual DR test rolls around, your environment may have changed so significantly that you’re essentially testing a completely different configuration than what existed during your last test. The validation you gained from that previous test is largely meaningless.

Modern DR testing should happen quarterly at a minimum, and ideally more frequently for critical systems. But traditional testing approaches made this frequency impossible due to the disruption and risk involved.

This is where non-disruptive testing changes everything.

Part 2: Nutanix DR Testing Capabilities

Nutanix addresses the traditional DR testing challenges through capabilities designed to make testing not just possible, but routine, safe, and comprehensive. Let’s explore how modern DR testing should work.

The Foundation: Non-Disruptive Test Failovers

The core innovation that makes frequent DR testing practical is non-disruptive test failover capability. Unlike traditional approaches that required shutting down production systems to test recovery, Nutanix allows you to test failover operations while production systems continue running normally.

Here’s how it works:

Isolated Network Testing

When you initiate a test failover in Nutanix, Recovery Plans use the test network mapping you configured (covered in Part 5 – Recovery Plans). Test networks are completely isolated from production networks, which means:

• VMs powered on during test failover connect to isolated test networks
• No IP address conflicts with production systems
• No accidental communication between test and production environments
• Zero risk of test operations impacting production workloads
• Full ability to validate application functionality in isolation

This isolation is critical. It means you can test your entire DR infrastructure – power-on sequencing, network mappings, application dependencies, recovery scripts – during business hours without any risk to production systems.

Point-in-Time Recovery Point Selection

Test failovers use replicated recovery points without impacting ongoing replication or production operations. You can:

• Select specific recovery points to test (most recent or historical)
• Test application recoverability from different time periods
• Validate that application-consistent snapshots actually result in clean application startup
• Verify retention policies are maintaining the recovery points you expect

Non-Impactful to Production Replication

While test VMs are running at the recovery site, production replication continues normally. Test operations don’t:

• Interrupt ongoing snapshot and replication processes
• Consume protection policy capacity or snapshots
• Impact production performance or network utilization
• Require coordination with production change windows

This means you can test as frequently as you want without impacting your actual DR protection capabilities.

Test Failover Execution and Validation

Let’s walk through a typical test failover workflow and what you’re validating at each stage.

Pre-Test Validation

Before initiating a test failover, validate prerequisites:

• Replication status – Confirm Protection Policies are current, and recent recovery points are available
• Network readiness – Verify that test networks are configured and isolated
• Credentials – Ensure guest OS credentials are available if in-guest scripts are part of the Recovery Plan
• Resource availability – Confirm recovery site has adequate compute and storage capacity for test VMs
• Documentation – Have runbooks and validation checklists ready for the test team

Test Failover Initiation

Initiating a test failover in Nutanix is straightforward:

1. Select the Recovery Plan to test
2. Choose “Test Failover” operation (distinct from actual failover)
3. Select the recovery point to use for testing
4. Confirm test network mappings
5. Execute the test

The Recovery Plan then orchestrates the test failover following the same power-on sequencing, network mapping, and script execution that would occur during a real failover event.

Validation During Test Execution

As the test failover proceeds, you’re validating multiple aspects:

– Power-On Sequencing Validation

• Do Stage 0 infrastructure services (Active Directory, DNS, DHCP) power on first?
• Are there adequate delays between stages for services to fully initialize?
• Do dependent services in later stages successfully connect to Stage 0 services?
• Are any VMs failing to power on or timing out?

– Network Connectivity Validation

• Are VMs connecting to the correct test networks?

• Can VMs within the same stage communicate with each other?

• Can later-stage VMs reach earlier-stage infrastructure services?

– Application Functionality Validation

This is where the real testing happens. Once VMs are powered on and networked correctly, you need to validate that applications actually work:

• Database validation – Can databases start cleanly? Are transactions committed? Is data consistent?
• Application server validation – Do application services start? Can they connect to databases and authentication services?
• Web tier validation – Are web servers accessible? Can they proxy to application servers?
• End-to-end functionality – Can test users authenticate and perform actual business transactions?

– Script Execution Validation

If your Recovery Plan includes in-guest scripts (which we’ll explore in detail in Part 8), test failovers validate that:

• Scripts execute successfully in the correct sequence
• Credential access works as expected
• Scripts produce the intended configuration changes (IP reconfiguration, DNS updates, etc.)
• Script failures are handled gracefully and reported correctly

– Performance and RTO Measurement

Test failovers provide critical data about actual recovery capabilities:

• Measured RTO – How long did the entire recovery process take from initiation to application availability?
• Stage timing – How long did each power-on stage require?
• Bottlenecks – Where are delays occurring? Storage performance? Network dependencies? Application startup time?
• Capacity validation – Does the recovery site have adequate resources, or are VMs resource-constrained?

This measured data is invaluable for understanding whether your theoretical RTOs are achievable and where optimization is needed.

Test Cleanup and Reporting

After validation is complete, test failover cleanup is simple and safe:

Test Environment Cleanup

Nutanix provides a straightforward cleanup process that:

• Powers off and deletes test VMs from the recovery site
• Removes test snapshots and clones
• Leaves production replication completely unaffected
• Returns the recovery environment to ready state for the next test

There’s no complex cleanup procedure, no risk of accidentally impacting production systems, and no manual VM deletion required.

Recovery Reports: Built-In Documentation and Audit Trail

One of Nutanix DR’s most valuable features for compliance and continuous improvement is the automated recovery report generated for every test and live failover operation. This isn’t a feature you need to configure or enable—it’s automatically created and preserved for every recovery operation you execute.

What the Recovery Report Contains

After completing a test failover (or live failover), Nutanix generates a comprehensive report that captures:

– Execution Timeline and RTO Validation

• Start and End Timestamps – Precise timing of when the recovery operation began and completed
• Total Recovery Duration – Your actual, measured RTO for this specific recovery event
• Per-Stage Timing – How long each power-on stage took to complete, helping identify bottlenecks
• VM-Level Timing – Individual power-on duration for each VM in the recovery plan

This timing data is invaluable for validating whether your theoretical RTOs are achievable and for identifying optimization opportunities. If your RTO target is 4 hours but the report shows consistent 6-hour recovery times, you have concrete data to justify infrastructure improvements or RTO revisions.

– Step-by-Step Operation Log

The recovery report documents every action taken during the recovery process:

• Recovery Plan execution initiation
• Network mapping application (test networks vs production networks)
• VM power-on sequence by stage
• In-guest script execution (if configured) with success/failure status
• Any warnings or errors encountered during recovery
• Cleanup operations (for test failovers)

This detailed audit trail shows exactly what happened during recovery, which is critical for troubleshooting failed tests or demonstrating to auditors that recovery procedures executed as designed.

– Success/Failure Status and Validation

The report clearly indicates:

• Overall recovery status – Did the recovery operation complete successfully?
• Per-VM status – Which VMs powered on successfully, which failed, and why
• Script execution results – If in-guest scripts are part of your recovery plan, the report shows which scripts executed successfully and which encountered errors
• Validation checkpoints – Documentation of which stages completed and any dependencies that were satisfied

– Recovery Point Information

The report documents which recovery point was used for the test:

• Snapshot timestamp – The exact recovery point used for failover
• RPO validation – How recent was the recovery point relative to the current time
• Data consistency – Whether application-consistent or crash-consistent snapshots were used

Using Recovery Reports for Compliance and Auditing

Recovery reports provide audit-ready documentation that satisfies regulatory requirements for DR testing validation:

– For Auditors

When auditors ask “prove that your DR plan works,” you can provide recovery reports that show:

• Regular testing cadence (quarterly, monthly tests documented with timestamps)
• Successful recovery operations with measured RTOs
• Issues discovered during testing and subsequent remediation
• Continuous improvement through repeated testing cycles

– For Compliance Frameworks

Different compliance requirements mandate DR testing documentation:

• SOC 2 Type II – Recovery reports demonstrate regular testing and monitoring of business continuity controls
• ISO 27001 – Documentation proves that information security controls remain effective during recovery operations
• Financial services regulations – Reports provide evidence of disaster recovery capability validation required by regulatory frameworks
• HIPAA – For healthcare, recovery reports document business continuity testing required for covered entities

– For Internal Stakeholders

Recovery reports aren’t just for external compliance—they build internal confidence and justify investments:

• Executive reporting – Share recovery reports with leadership to demonstrate DR program effectiveness
• Trend analysis – Compare recovery reports over time to show RTO improvements or identify degradation
• Budget justification – Use reports showing RTO misses to justify infrastructure investments
• Risk management – Document known issues and remediation plans based on test results

Accessing and Sharing Recovery Reports

Recovery reports are accessible through Prism Central’s DR dashboard:

• Reports are retained for historical analysis and compliance documentation
• You can export reports in formats suitable for auditor review
• Reports can be reviewed immediately after test completion to validate success
• Historical reports allow trend analysis of recovery performance over time

Building Organizational Confidence Through Documented Success

Here’s the psychological impact of recovery reports that organizations often overlook: seeing documented, successful test failover after successful test failover builds genuine confidence in DR capabilities.

When you can show leadership a series of recovery reports demonstrating:

• Quarterly test failovers completed successfully
• RTOs consistently meeting targets
• Issues discovered and subsequently fixed in later tests
• Measured improvements in recovery times through optimization

…you’re not asking them to trust that DR will work. You’re showing them proof that it does work, repeatedly and predictably.

This documented evidence transforms DR from a theoretical capability into a proven, validated business continuity asset. And when the real disaster strikes, your team isn’t wondering if recovery will work—they know it will because they’ve tested it, measured it, and documented it successfully dozens of times.

Building a Regular Testing Cadence

With non-disruptive testing capabilities, organizations can establish realistic testing schedules that actually validate DR readiness:

Quarterly Full DR Tests

Perform comprehensive test failovers of all critical Recovery Plans every quarter. This frequency:

• Catches environmental changes before they accumulate excessively
• Provides regular team practice on failover procedures
• Satisfies most regulatory testing requirements
• Delivers meaningful validation without being operationally burdensome

Monthly Partial Tests

Test individual Recovery Plans or specific application stacks monthly to:

• Validate high-change applications more frequently
• Focus on systems that failed or had issues in previous tests
• Provide more frequent training opportunities for operations teams
• Build organizational confidence through regular successful tests

Ad-Hoc Testing

Perform test failovers whenever significant changes occur:

• After major application updates or infrastructure changes
• Following Recovery Plan modifications
• When new VMs are added to protection policies
• After network configuration changes at recovery sites

Non-disruptive testing makes ad-hoc testing practical, allowing validation exactly when it’s needed rather than waiting for scheduled testing windows.

Live Failover Capabilities

While test failovers validate your DR plan in isolation, live failovers represent the real event – bringing production workloads online at the recovery site. Nutanix provides the same orchestrated, automated execution for live failovers as for test failovers, but with critical differences:

Live Failover Execution

When executing a live failover (whether in response to an actual disaster or for planned migration), Nutanix:

• Uses production network mappings instead of test networks
• Brings VMs online with full production connectivity
• Executes the same power-on sequencing and scripts validated during testing
• Provides the same orchestration and automation you’ve already practiced and validated

Confidence Through Testing

This is where the value of regular testing becomes crystal clear. When you execute a live failover during an actual disaster event:

• You’re following runbooks that have been practiced repeatedly
• You’re using Recovery Plans that have been validated through successful tests
• You know the expected RTO because you’ve measured it during tests
• Your team has hands-on experience executing the process under pressure
• You’ve already discovered and fixed configuration issues that would have caused failures

The live failover is still stressful, but it’s not filled with the unknown variables and uncertainty that plague organizations who haven’t tested their DR capabilities properly.

Validation Beyond Technology

Effective DR testing validates more than just technical capabilities. It also tests:

Organizational Readiness

• Do team members know their roles during recovery operations?
• Is the communication plan effective?
• Are escalation procedures clear?
• Does documentation match current reality?

Business Process Continuity

• Can business operations actually function at the recovery site?
• Are there non-technical dependencies (phones, physical security, user access) that impact recovery?
• Do users know how to access recovered systems?

Third-Party Dependencies

• Are external service providers aware of recovery site configurations?
• Do network connections to external systems work from the recovery site?
• Are SaaS integrations functional when applications run from recovery locations?

Common Testing Pitfalls and How to Avoid Them

Pitfall 1: Testing Only Power-On

Many organizations validate that VMs power on successfully and declare the test complete. This validates only the most basic aspect of DR capability. Comprehensive testing must validate application functionality, not just VM boot processes.

Solution: Develop application-specific validation checklists that verify actual business functionality, not just infrastructure availability.

Pitfall 2: Testing Without Measuring

If you don’t measure RTO during tests, you’re missing critical data about whether your recovery capabilities actually meet business requirements.

Solution: Instrument test failovers with timing measurements at each stage. Compare measured RTOs to target RTOs and investigate gaps.

Pitfall 3: Ignoring Test Failures

Sometimes test failovers reveal issues that get documented but not remediated before the next test (or worse, before a real disaster). Test failures are opportunities to improve DR capabilities – but only if they’re actually fixed.

Solution: Establish clear ownership for test failure remediation with timelines and accountability. Retest after fixes to validate improvements.

Pitfall 4: Testing in a Vacuum

DR testing conducted solely by infrastructure teams without business involvement misses critical validation opportunities and fails to build organizational confidence.

Solution: Include application owners, business stakeholders, and user representatives in test planning and validation activities.

Pitfall 5: Set-and-Forget Testing Schedules

Testing quarterly is excellent – unless your last test was six months ago because schedule slippage accumulated. Regular testing requires discipline and prioritization.

Solution: Treat DR testing with the same importance as production maintenance windows. Put testing schedules on organizational calendars and hold teams accountable.

Building Confidence Through Proven Capability

The ultimate goal of DR testing isn’t compliance checkbox satisfaction or technical validation – it’s building genuine organizational confidence that your business can continue operating when primary systems fail.

That confidence comes from:

• Repeated successful tests that prove recovery capabilities work
• Measured performance that shows RTOs are achievable
• Practical experience that gives teams confidence in execution
• Discovered and fixed issues that strengthen the overall DR program
• Documented proof that satisfies auditors and regulators

Modern DR testing capabilities from platforms like Nutanix make this level of testing achievable without the risk and disruption that made traditional DR testing so challenging. Non-disruptive test failovers transform DR testing from an annual event that everyone dreads into a routine practice that actually builds confidence and validates capability.

What’s Next: Executing Failovers When It Matters

We’ve covered how to test your DR capabilities safely and frequently. In Part 7, we’ll explore how to execute actual failover operations – understanding the differences between planned migrations and unplanned disaster responses, and how Nutanix automates failover execution while maintaining control and visibility throughout the process.

Testing proves your DR plan works. Execution makes it a reality when your business depends on it.

Build Confidence with Nutanix DR Testing

Transform your disaster recovery plan from documentation to proven capability. Validate runbooks, measure real RTOs, and ensure your failovers work flawlessly—without disrupting production.

We recently hosted a four-part virtual roadshow focused on helping IT leaders build, secure, and modernize their Microsoft Azure environments. The goal wasn’t to just showcase every new feature, it was to have meaningful conversations about what works, what’s changing, and what’s next. 

Each session tackled a different challenge, but they all shared a common theme: strategies that work. Whether you’re just getting started with Azure or refining a mature deployment, these are the conversations that matter. 

If you missed the live sessions, the recordings are available. Below is a recap of each part, along with key takeaways and an opportunity for continuing the conversation. 

Part 1: Azure Cost Management: Beyond the Billing Dashboard 

We opened the roadshow with a foundational session on how to architect Azure environments for long-term success. This wasn’t about lift-and-shift, it was about aligning platform choices with business outcomes. 

We walked through: 

• The decision tree for Infrastructure (IaaS), Platform (PaaS), and bare metal (BMaaS) workloads. 

• How to navigate turbulence in the market with changes in VMware. 

• How to use the established frameworks combined with a methodology for planning to ensure business outcomes stay at the forefront of decision-making. 

• Why the small things like governance, tagging, and FinOps discipline should start on day one, not year two. 

Key Takeaways: 

• Azure success is less about what you move, more about how you operate. 

• Platform choice isn’t static, reassess as your business evolves. 

• Visibility and a foundation for automation build predictable clouds. 

Part 2: Azure Innovation: Building What’s Next 

In part two, Kai Andrews led a deep dive into Microsoft Fabric:  a single platform for data ingestion, transformation, storage, analytics, and AI. For organizations drowning in spreadsheets and disconnected reporting tools, Fabric offers a way out. 

We covered: 

• How Fabric consolidates tools like Data Factory, Power BI, Synapse, and OneLake. 

• The cost model: one capacity, one price, scalable up or down. 

• Why iterative development and pragmatic governance are key to successful data modernization. 

Key Takeaways: 

• Fabric simplifies architecture and accelerates time-to-value. 

• Copilot is now available across all capacity tiers, making AI more accessible. 

• Governance doesn’t have to be bureaucratic; it just needs to be intentional. 

Part 3: Azure Security: What CISOs Actually Care About 

Security was the third topic and is arguably the most urgent. We focused on how to move beyond disparate, somewhat connected, solutions and how we can adopt a platform to build a proactive, integrated-by-default, security solution by leveraging the expertise of a Microsoft Validated Security Solution Partner (ThreatDefender). 

Highlights included: 

• Entra, Defender, and Sentinel as the backbone of cloud security operations. 

• Zero Trust architecture in practice: identity, conditional access, and data protection. 

• Going beyond networks and MFA with how Purview supports compliance through automated classification and policy enforcement. 

Key Takeaways: 

• Security tools are only as good as the visibility they have. 

• Integration matters: visibility without correlation leads to missed threats. 

• Integration in disparate tools is costly: From personnel costs to critical gaps in coverage. 

Compliance isn’t just about checkboxes; it’s about confidence. 

Part 4: Azure Governance: From Chaos to Clarity 

We wrapped Day 1 of the Roadshow with a session on modern desktops; specifically, an ongoing trend towards changing strategies between managed endpoints and virtual desktop infrastructure (VDI). Azure Virtual Desktop (AVD), Windows 365, and Intune all provide viable options. However, the conversation centers around successful flexibility, cost, and user experience. 

We explored: 

• Why some organizations are moving away from legacy VDI toward cloud-managed endpoints with Microsoft Intune. 

• Practical considerations and pros/cons in the Endpoint, Windows365, and Azure Virtual Desktop solutions. 

• The role of Intune in managing both corporate and BYOD devices across distributed teams. 

• How Nerdio provides an opportunity to simplify desktop management and scale. 

Key Takeaways: 

• Desktop strategy is now a cloud conversation. 

• Windows 365 offers predictable cost and simplicity for dedicated users. 

• Nerdio can reduce AVD compute costs by 60%+ in the right scenarios. 

Final Thoughts 

The Azure platform is broad, but full of opportunity. These four conversations (building for success, data, security, and endpoints) are where most organizations find challenges with evaluating their posture, upskilling their teams, and making meaningful progress. If any of these topics struck a chord, let’s have a conversation that centers around your goals. 

Whether you’re planning a migration, launching a new initiative, or just trying to clean up what’s already there, we’re here to help.