Partner Blog | FY27 is the year to execute on AI: A starting point for Azure partners
FY27 is the year to execute on AI. For Azure partners, that means moving more customer AI initiatives into production, modernizing the cloud, data, application, security, and governance foundations they depend on, and connecting those investments to outcomes customers can measure. Across the partner ecosystem, you are starting from different places. Some partners are already scaling AI solutions in production. Others are modernizing legacy environments, unifying data, or strengthening security and governance so customers are ready for what comes next. The opportunity is to understand where each customer is today and create a practical path forward. Microsoft has aligned FY27 customer conversations, go-to-market guidance, incentives, skilling, and partner resources around that goal. The focus is less on starting with a product and more on starting with what the customer is trying to achieve. In July, MCAPS Start for Partners and the Microsoft Partner FY27 GTM Kickoff laid out that direction. If you missed the events or want to revisit a specific topic, the content is available on demand: Watch MCAPS Start for Partners on demand Explore the Microsoft Partner FY27 GTM Kickoff The more important question now is what you do with that guidance. Turn customer priorities into Core and Frontier conversations Customers rarely begin by asking for a portfolio of technologies. They begin with a challenge, an ambition, or an outcome: modernize an aging application, make fragmented data useful, strengthen security, improve employee productivity, automate a process, or create a new customer experience. That is the starting point for FY27. Core conversations establish the foundation customers need to become AI-ready. Depending on the customer, that can mean modernizing infrastructure and applications, bringing data together on a governed platform, improving security, or establishing the controls required to operate AI with confidence. Continue reading hereBeyond Tokens: Rethinking AI Economics with Microsoft Foundry
Beyond Tokens: Rethinking AI Economics with Microsoft Foundry From the cost of intelligence to the value of outcomes Enterprise AI has an accounting problem. Executives expect agentic AI to return roughly 171% on investment, according to one widely cited survey. Yet McKinsey finds only about 39% of organizations can attribute any earnings impact to AI at all. Both numbers can be true at once — because the gap between them is not a technology gap. It is a measurement gap. For the first few years of generative AI, one number dominated the economics conversation: tokens. How many tokens did a model consume? What was the cost per million tokens? Could a smaller model perform the same task? Those questions mattered when enterprises were experimenting with AI. They are no longer enough as AI moves into production. An enterprise agent doesn't simply consume tokens. It reasons, retrieves context, invokes tools, calls APIs, verifies its work, retries unsuccessful actions and sometimes escalates exceptions to humans. The model call might cost pennies. The business outcome could cost considerably more. Which leads to an increasingly important question: What is the right economic unit for intelligence? From AI experimentation to economic accountability The first wave of enterprise AI was about possibility: Can AI do this? The next wave is about production, as AI becomes embedded in software engineering, customer service, finance, healthcare and supply chains. And production changes the question: Should AI do this and at what cost? Microsoft has moved decisively onto this ground. In August 2026, the Microsoft Foundry team launched its Economics of Agent Optimization series, arguing that "tokens have become the new unit of technology spend" and that AI should be run as a managed investment system. On the latest earnings call, Satya Nadella described Microsoft's objective as "advancing the frontier on the cost-to-outcome curve, ensuring every customer can turn tokens into business results." The discipline is going mainstream too: 98% of FinOps teams now manage AI spend, up from 31% two years ago. Microsoft's series is largely about the numerator of that curve - making every request, agent and dollar more efficient. This article is about the denominator: what an outcome is, what it truly costs, and what it is worth. The evolution of Microsoft Foundry reflects the same shift. At Build 2026, Microsoft expanded the conversation beyond building agents toward tracing behavior, evaluating quality, monitoring production performance, optimizing agents and connecting their operation to ROI. Think of the progression as: Trace → Evaluate → Monitor → Optimize → ROI This is more than a technology roadmap. It represents a shift from observing AI as technology to managing AI as an economic asset. Tokens became the unit of spend. They were never the unit of value. Consider two AI agents handling the same customer-service workflow. Agent A costs $0.08 per interaction. Agent B costs $0.20. Agent A appears cheaper. But suppose Agent A successfully resolves only 55% of cases, while Agent B resolves 90%. The remainder require retries, additional reasoning or human intervention. Which agent is actually cheaper? The inexpensive interaction may produce the expensive resolution. This illustrates a fundamental problem: We often measure AI where it is consumed rather than where value is created. Tokens are a unit of consumption. Businesses operate in outcomes. A customer-service leader cares about issues resolved. An engineering leader cares about high-quality software reaching production. A finance leader cares about reconciliations completed accurately. The economic denominator needs to move closer to the business. The AI Economic Ladder I think of this evolution as an AI Economic Ladder: Tokens → Interactions → Tasks → Outcomes → Value Each step moves measurement closer to what the enterprise actually cares about. At the token level: What intelligence did we consume? At the interaction level: What did each AI run cost? At the task level: What did it cost to complete the work? At the outcome level: What did a successful result cost? At the value level: Was the outcome worth creating? An AI system can become more efficient at every technical metric while creating little economic value. Conversely, an expensive AI workflow could be extraordinarily valuable if it prevents revenue leakage, reduces operational risk or accelerates a critical business process. The objective isn't cheaper AI. It is better economics. Not every completed task is a successful outcome There is another complication. If an agent completes a workflow, should we count it as a successful outcome? Not necessarily. A meaningful outcome needs three characteristics: Completed. Quality-gated. Attributable. It must reach its intended end state, meet an explicit standard for quality, accuracy, safety or business acceptability, and be attributable to the agent or workflow that produced it. That gives us a more meaningful measure: Cost per Successful Outcome = Fully Loaded AI Workflow Cost / Completed, Quality-Gated, Attributable Outcomes The denominator becomes real only when named in business language: cost per prior authorization resolved in healthcare, per pull request triaged and tested in engineering, per disputed invoice reconciled in finance operations. If you cannot name the outcome in a sentence the process owner recognizes, you are not ready to measure it. The quality gate matters. With AI, "the system ran successfully" and "the system produced a good outcome" are not the same thing. Microsoft Foundry's tracing and evaluation capabilities become economically important for precisely this reason. Evaluation isn't merely quality control. It helps determine what gets counted as value. What does an AI outcome really cost? The true economic footprint goes far beyond inference: Model + Reasoning + Grounding + Tools + Orchestration + Infrastructure + Retries + Evaluation + Governance + Human Intervention Human intervention is particularly easy to overlook. Every time someone must review, correct, approve or recover an AI-generated outcome, the economics change. The same applies to verification. An agent reaching an acceptable result in three steps has different economics from one requiring fifteen steps and multiple retries. And verification is not a rounding error — it is the bulk of the bill. McKinsey's 2026 analysis of production agentic workflows found roughly 60% of an agentic task's cost is tied to refining answers — checking, repairing, re-verifying — not generating the initial response. Most of what you pay for is not intelligence. It is assurance. This means quality and economics are connected. The quality bar you set influences the cost you pay. The challenge isn't simply minimizing consumption. It is finding the right balance between quality, cost, speed and risk. Cost per outcome is only half the equation Now imagine two agents. Both cost $5 per successful outcome. One saves an employee ten minutes of administrative work. The other prevents $500 in revenue leakage. Their cost efficiency is identical. Their economics clearly aren't. So we need to move another step up the ladder: from Cost per Outcome to Value per Outcome. The question isn't only how cheaply AI can complete the work. It is: How much economic value does this outcome create relative to the intelligence required to produce it? Now the CIO, CFO, CAIO and business leader have a common conversation. Give every outcome an Intelligence Budget Not every problem deserves the smartest model available. Classifying an email may require relatively little intelligence. Resolving a complicated customer complaint may justify more context and reasoning. Assessing the risks in a multimillion-dollar contract may justify sophisticated reasoning, multiple validations and human review. Every business outcome therefore has an economically rational amount of intelligence worth spending on it. Call it an Intelligence Budget. This changes the architecture question from which model should we standardize on, to: What combination of model, reasoning, context, tools and human judgment does this outcome deserve? This is where Microsoft Foundry's model router becomes interesting. Individual requests can be dynamically routed so simpler work doesn't consume the same model resources as complex reasoning. If the Intelligence Budget is the economic principle, intelligent routing is one way of operationalizing it. The future enterprise AI architecture won't be about one model doing everything. It will route intelligence according to the economics, quality and risk of the outcome. Making AI economics observable None of this works without visibility. An AI system can be technically healthy and economically unhealthy — responsive and error-free while repeatedly choosing inefficient reasoning paths, invoking unnecessary tools or producing outputs requiring expensive human correction. AI economics and AI observability are becoming inseparable. Microsoft Foundry increasingly connects these disciplines. Tracing shows what an agent did. Evaluation determines whether it met required criteria. Observability helps monitor production behavior. Agent optimizer can test improvements across prompts, skills and models. Microsoft's emerging ROI capabilities take the next step by connecting operating costs with measures such as task completion, time saved and cost efficiency. Attribution is the bridge to the finance conversation. Teams place Azure API Management in front of Foundry endpoints as an AI Gateway, stream token telemetry into Application Insights, and use Entra Agent ID to give every agent run a discrete identity that maps cost to its cost center. Microsoft Agent 365 extends the discipline tenant-wide — spending policies, budget caps and departmental chargeback across Microsoft and third-party agents. Together, they create something enterprises have historically lacked: A feedback loop between how intelligence is consumed and what that intelligence accomplishes. The paradox of cheaper intelligence There is another reason AI economics will become more important as models get cheaper. The Jevons paradox suggests that when technology makes a resource cheaper and more efficient, total consumption can actually increase. AI may experience the same effect. Cheaper intelligence enables more agents, more reasoning and more workflows that were previously uneconomic. So we could see cost per unit of intelligence fall while total intelligence consumed rises. Cheaper AI may therefore produce larger AI bills. That isn't necessarily bad — provided value grows faster than consumption. The objective isn't minimum AI consumption. It is maximum economic value from AI consumption. From workload economics to portfolio economics As AI scales, economics becomes a capital-allocation question. I see three levels. Workload Economics: Is this AI system running efficiently? Outcome Economics: Is it producing quality outcomes economically? Portfolio Economics: Where should we put our next AI dollar? That final question will become increasingly important. An enterprise with hundreds of AI initiatives shouldn't assume every one deserves continued investment. Some should scale. Some need optimization. Some should be redesigned or consolidated. And some should be stopped. The ability to experiment cheaply created the first explosion of enterprise AI. The discipline to allocate capital intelligently will determine what scales. Who owns AI economics? Once an agent becomes part of how work gets done, its economics cannot remain purely an IT metric. The business understands the value of the outcome. Technology understands the architecture and optimization levers. Finance brings economic discipline and comparability. That suggests a shared model: Business owns the outcome. Technology owns the optimization levers. Finance owns the economic discipline. AI economics ultimately isn't just a technology-cost conversation. It is a business-performance and capital-allocation conversation. From abundant intelligence to intelligent economics We are entering an era where intelligence is becoming an increasingly abundant, programmable and variable-cost resource. Microsoft Foundry and the broader Microsoft AI stack are making it easier to build, evaluate, observe, optimize and govern that intelligence. But abundant intelligence does not guarantee abundant value. Enterprises still need to decide where AI belongs, how much intelligence each problem deserves, what defines a successful outcome, when humans should remain involved and which AI investments deserve more capital. The winners won't necessarily use the cheapest models. They won't consume the fewest tokens. And they won't be the organizations that build the most agents. They will become exceptionally good at moving up the AI Economic Ladder: from consumption, to outcomes, to value. Because the next era of AI won't be won by organizations that buy intelligence most cheaply. It will be won by those that convert intelligence into value most efficiently. Where to start: the first 90 days Define the denominator for your top three agents — what counts as done, what quality gate applies, who signs off. Instrument attribution — Azure API Management as an AI Gateway, token telemetry to Application Insights, Entra Agent ID on every run. Wire evaluations into the cost pipeline so only quality-gated outcomes count. Set Intelligence Budgets — model router per request, agent optimizer against your evaluators, Agent 365 policies as circuit breakers. Stand up a joint monthly review — business, technology and finance on one dashboard: outcomes delivered, cost per outcome, value per outcome. Frequently asked questions What is Cost per Successful Outcome in enterprise AI? The fully loaded cost of an AI workload divided by outputs that were completed, quality-gated and attributable - for example, cost per prior authorization resolved or per pull request triaged. It turns token metrics into the unit economics of AI-performed work. What is an Intelligence Budget? The economically rational amount of intelligence - model capability, reasoning, context, tools and human review — worth spending on a given outcome, based on its value and risk. Model router in Microsoft Foundry is one way to operationalize it. Why do AI agents cost more than single model calls? One agent task can involve planning, tool calls, retries and verification - many model calls with compounding context. Research on production agentic workflows attributes roughly 60% of task cost to refining and verifying answers, not generating the first response. Will falling model prices make AI cost management unnecessary? No. By the Jevons paradox, cheaper intelligence expands consumption, so total AI spend typically rises as unit prices fall. The discipline that matters is maximizing value per unit of intelligence. Who should own AI economics? A shared model: the business owns the outcome and its value, technology owns the optimization levers, and finance owns the economic discipline and review cadence. #MicrosoftFoundry #Agent365 #AzureAI #FinOps #AgenticAI #AIAgents #Azure #MicrosoftCostManagement #AIEconomics #Tokens References Microsoft Azure Blog: "The Economics of Agent Optimization: From pilots to measurable returns" (August 12, 2026) Microsoft FY26 Q4 earnings call (Satya Nadella, July 2026) McKinsey — "Cost versus value: managing agentic AI system performance" (July 2026) FinOps Foundation — State of FinOps 2026; Microsoft Learn — Model router for Microsoft Foundry; Agent optimizer; Foundry Control Plane cost optimizationSimplify AKS observability with Azure Native New Relic Service
An Azure Native path to New Relic Intelligent Observability for AKS AKS environments are dynamic by design. Applications can span clusters, namespaces, nodes, pods, and containers, while workloads scale and change continuously. Obtaining consistent visibility often requires platform teams to deploy and maintain monitoring components separately on every cluster. Azure Native New Relic Service simplifies this process by integrating New Relic onboarding and management into Azure. Customers can already use the service to: Create a new New Relic account or link an existing account from Azure. Configure the forwarding of Azure platform metrics and logs to New Relic. View the monitoring status of Azure resources. Consolidate procurement and eligible New Relic charges through Azure Marketplace. Monitor multiple Azure subscriptions through a single New Relic resource. With AKS extension support, customers can now extend this native management experience to their Kubernetes clusters. Install the New Relic integration from the Azure portal The new experience follows the same simple model used by Azure Native integrations for other compute resources. From an Azure Native New Relic Service resource, customers can navigate to New Relic account config > Azure Kubernetes Services, select an eligible AKS cluster, and choose Install Extension. Azure then deploys the New Relic Kubernetes integration by using the AKS cluster extensions framework. After deployment completes, the portal displays the installation status for the cluster. Customers can return to the same experience to review the status or select Uninstall Extension when monitoring is no longer required. AKS cluster extensions provide an Azure Resource Manager-based approach for installing and managing services on AKS. This gives customers a consistent Azure control plane experience for deployment and lifecycle operations instead of requiring a separate, manual Helm installation for each cluster. Gain deeper visibility into Kubernetes workloads The extension deploys the New Relic Kubernetes integration to the selected AKS cluster. The integration provides visibility across Kubernetes infrastructure and workloads, including cluster, node, namespace, deployment, pod, and container health and performance. Depending on the enabled New Relic configuration, customers can also bring together Kubernetes events, logs, and Prometheus-formatted metrics with application and Azure platform telemetry in New Relic. This helps application, platform, and site reliability engineering teams investigate issues across the stack without stitching together disconnected views. Teams can use New Relic to: Understand resource consumption and health across clusters, nodes, pods, and containers. Identify unhealthy workloads, container restarts, and capacity constraints. Correlate Kubernetes infrastructure signals with application performance data. Explore Kubernetes entities and relationships through New Relic's cluster experience. Create dashboards, alerts, and operational workflows using telemetry from Azure and AKS. The result is a more direct path from detecting an issue to understanding its impact on applications and users. Reduce operational toil with unified telemetry For organizations operating multiple AKS clusters, consistency is as important as visibility. Manual installation can lead to configuration drift, missed clusters, and additional work whenever monitoring components need to be changed. The Azure Native New Relic Service experience helps address these challenges by providing: Simplified onboarding: Install the integration from the Azure portal without building a separate deployment workflow. Centralized visibility: Review AKS extension status alongside other Azure resources connected to New Relic. Azure governance alignment: Use Azure Resource Manager and Azure role-based access control as part of the management experience. Lifecycle management: Install or remove the extension through a consistent Azure workflow. Unified, full-stack observability: Connect AKS telemetry with application, infrastructure, log, and Azure platform data in New Relic. This experience is particularly useful for platform teams that want to make observability available as a standardized service while allowing development teams to use New Relic for troubleshooting and performance optimization. Get started To begin monitoring AKS with Azure Native New Relic Service: Either browse to the Marketplace offer listing or in the Azure portal, create an Azure Native New Relic Service resource. Go to New Relic account config > Azure Kubernetes Services. Select the AKS cluster that you want to monitor. Select Install Extension and then confirm the installation. After the status changes to Installed, open New Relic to explore your Kubernetes data and configure the dashboards and alerts appropriate for your environment. If you face any technical challenges do raise a support ticket and share your feedback.Partner Case Study | Siemens
The longstanding partnership between Microsoft and Siemens—a German tech conglomerate that focuses on industrial automation—helps solve a crucial challenge facing consumer packaged goods (CPG) and retail companies: fragmented processes across production. The CPG and retail industries—both essential to everyday life and major players on the global stage—experience multiple unique pain points. Consumers have rapidly shifting preferences; labeling and packaging regulations are more stringent than in past decades; and both product ingredients and waste reduction efforts must reflect sustainability goals—not to mention the complexity of global supply chains. In addition to all this, siloed teams and disconnected operations can take a serious toll, slowing down product launches, driving up compliance costs, and making it harder to keep up with market trends. Siemens' Integrated Lifecycle Management (ILM) is specifically tailored to address the complex needs of the CPG and retail industries. A single, reliable source of truth helps organizations manage industry complexity, minimize errors, and accelerate decision-making. By seamlessly connecting product development, program management, and brand management using AI and cloud innovation, Siemens' ILM helps these sectors remain agile and competitive in a fast-paced market. Cloud-powered lifecycle management tailored for CPG and retail At the core of Siemens' ILM is Siemens' Teamcenter X on Azure, a cloud-based product lifecycle management (PLM) platform. Teamcenter X securely integrates teams, processes, business systems, and critical product data. For CPG manufacturers, this accelerates innovation, shortens product development cycles, and provides the agility needed to quickly respond to changes in consumer demand and regulatory requirements. Additionally, Teamcenter X on Azure delivers powerful generative AI capabilities, including seamless integration with Microsoft Teams and its intuitive chat functionality. This significantly improves cross-team communication and collaboration, a critical advantage for any organization. Teamcenter X on Azure harnesses advanced AI to enhance productivity and innovation specifically within the demanding environment of CPG manufacturing. Powered by Microsoft Azure OpenAI Service, the application helps augment the creation, optimization, and debugging of code for factory automation software, while industrial AI makes visual quality inspection on the shop floor possible. Continue reading here Explore all case studies or submit your own Subscribe to case studies tag to follow all new case study posts. Don't forget to follow this blog to receive email notifications of new stories!
Introducing Everpure Cloud Azure Native for Azure VMs
Overview We're excited to announce Everpure Cloud Azure Native for Azure Virtual Machines (VMs). With this release, Azure customers can provision enterprise-grade block storage volumes and attach it directly to their Azure VMs, all managed natively within the Azure portal. No appliances to manage, no complex storage stack to stitch together — just elastic, high-performance block storage that behaves like any other Azure disk. This release solves three persistent challenges Azure VM customers face with traditional Managed Disks: Pay for capacity what you actually use, not what you provision — Billing follows effective capacity after deduplication and compression, helping customers avoid overprovisioning and reduce storage costs (by up to 40%) Scale storage independently from compute — Grow capacity and tune performance without resizing your VM or touching the VM SKU, giving you finer control over both cost and performance. Enterprise data services built in — Thin provisioning, deduplication, and compression — all native to Everpure. What you can expect Familiar building blocks — storage pools, volume groups, and volumes that map cleanly to your applications and VMs. Independent scaling of capacity and IOPS — dial storage performance up or down without disturbing compute. Seamless guest-OS integration — mounted volumes appear as standard Windows disks; no special drivers or custom tooling required. Step-by-step: Setting up Everpure Cloud Azure Native storage for your Azure VM Step 1 — Deploy Everpure Cloud service Find Azure Native Everpure Cloud in the Azure Marketplace and deploy it into your subscription. The service is provisioned natively as an Azure resource and enables the service in selected region. Step 2 — Create a Storage Pool Create a storage pool — Choose an availability zone for resiliency and use the performance slider to set your desired IOPS independently of capacity Step 3 — Create a volume group Create a volume group — a logical container that groups related volumes together, for example all the disks belonging to a single application, database, or VM. Operating at the group level makes access control and day-2 management simpler at scale. Step 4 — Create volumes Within the volume group, create the volumes your VM will consume. Specify a name and size — this size is a logical limit, not pre-allocated capacity. Volumes can be resized live and shared across multiple VMs when needed. Step 5 — Mount to your Azure VM From the volume group, select Mount on VM. The Azure VM connection experience opens, letting you attach the volume to your chosen Azure Virtual Machine. Step 6 — Bring the disk online inside the guest OS Once mounted, the final step happens inside the VM. The Everpure volumes appear as standard, uninitialized Windows disks. Open Disk Management, initialize the disks with GPT, run the New Simple Volume Wizard, and format them as NTFS. Within seconds, the Everpure-backed volume becomes a regular drive letter (for example, F:) ready for any workload. Get Started Today Everpure Cloud Azure Native for Azure VMs is available now in the Azure Marketplace. Deploy it into your subscription to start bringing enterprise-grade Everpure to your Azure VMs Start Your Free Trial of Everpure Cloud Azure Native Check out the Everpure Cloud release notes for detailed guidance on supported configurations, capacity points, and operational considerations. Read the Everpure GA announcement blog to learn how Everpure Cloud Azure Native for Azure VMs helps reduce costs and simplify storage operations. Have feedback or questions? Drop a comment below — we'd love to hear how you plan to use Everpure Cloud for your Azure workloads.Partner Case Study | Ingram Micro
As organizations move toward AI-powered operations, many are discovering they are not starting with a clean slate. Legacy on-premises infrastructure, fragmented cloud environments, and security gaps often stand between customer ambition and execution. At the same time, customer expectations continue to rise, putting added pressure on managed services providers (MSPs) and consulting partners to deliver scalable, compliant solutions without adding operational burden or losing control of cost, complexity, and security. As a global Microsoft distributor, Ingram Micro empowers partners to bridge that gap by supporting customers across key stages of their modernization journey, from exiting legacy infrastructure to adopting Azure-native solutions and building toward AI innovation. Rather than treating migration, modernization, and AI as separate motions, Ingram Micro guides partners to a structured, repeatable path forward on Azure. With advanced specializations in Infrastructure and Database Migration, Azure Virtual Desktop, Azure VMware Solution, and AI Apps on Azure, Ingram Micro brings technical depth and access to Microsoft-backed funding programs to their engagements with partners. They empower partners to modernize infrastructure, optimize costs, prove value faster, and lower risk as they move customers from foundational cloud transformation to AI-powered workloads. Evolving beyond legacy infrastructure without disruption Calyx IT is an MSP that has spent more than 20 years serving customers across legal, finance, and compliant manufacturing. Over time, Calyx’s traditional private datacenter model became more difficult to sustain. Rising costs and limited scalability required more work to keep pace with customer expectations. Managing infrastructure across multiple vendors also introduced more complexity and inefficiency, while a legacy virtualization stack created added pressure through unpredictable licensing costs from third-party providers. Calyx consulted Ingram Micro, who recommended Microsoft Azure for flexible, consumption-based infrastructure. An existing partnership between Ingram Micro and Calyx provided a foundation for tackling a larger transformation. Together, the teams developed a strategy that aligned technical requirements, cost considerations, and migration planning. Continue reading here Explore all case studies or submit your own Subscribe to case studies tag to follow all new case study posts. Don't forget to follow this blog to receive email notifications of new stories!Important: FY26 PRACR close deadlines
We’re sharing the Partner Reported Azure Consumed Revenue (PRACR) deadlines for the close of fiscal year 2026 (July 2025–June 2026) to help you stay on track. These dates are sequential and critical to an accurate year-end close, ongoing submission eligibility, and a smooth transition to FY27. Category Deadline Requirement Owner Notes PRACR submissions June 10, 2026 (EOD) Final cutoff to submit PRACR reports through Partner Center Partner N/A Deal eligibility June 13, 2026 (EOD) Last day to mark deals as “Won” in MSX Microsoft Seller Required before deal registration Deal registration June 14, 2026 (EOD) Deals must be registered in Partner Center and all revalidation and disputes must be submitted by June 14. Deal registration will resume starting July 15, 2026. Partner Only registered deals can be reviewed for approval Exception handling June 19, 2026 (EOD) Final deadline to submit exception requests with full evidence through the PRACR Ops alias Partner or PDM Last exception forum of fiscal year 2026: June 24 Deal review June 26, 2026 (EOD) If deal is selected for further review, final date to submit required documentation Partner N/A No immediate action is required at this time; however, you as a partner are expected to plan and align internal activities to meet the deadlines outlined above. This communication is intended for awareness and planning purposes and partners are expected to align activities accordingly.Partner Blog | Building AI-ready applications on open, enterprise-grade Azure platforms
Microsoft Build 2026 reinforced a practical reality for organizations moving from AI experimentation to production: AI is only as strong as the foundation it runs on. Customers need modern databases, governed data, secure infrastructure, and developer experiences that can carry performing AI-enabled applications at scale into production with confidence. The public preview announcements of Azure HorizonDB and Azure Linux, along with the general availability of Azure Container Linux, show how Microsoft is investing in open platforms, developer ecosystems, and enterprise-grade cloud infrastructure for AI-ready applications. These announcements also point to a broader shift: open source has become a strategic foundation for enterprise modernization, innovation, and strategic growth. These announcements give partners a straightforward way to connect customer AI goals to the open, secure, enterprise-ready platforms needed for production. They also create timely opportunities to engage customers on data modernization, AI-ready application development, secure infrastructure, and cloud-native operations. What was announced at Build 2026 Azure HorizonDB: A new standard for AI-native, enterprise PostgreSQL Azure HorizonDB enters public preview as a new PostgreSQL cloud database service engineered for performance, scale, and modern AI-powered application needs. For business leaders thinking about data strategy, this is significant. Organizations are under pressure to modernize legacy databases and support intelligent applications without sacrificing resilience, governance, or developer productivity. Azure HorizonDB is designed to address those priorities with a platform that can scale storage automatically for large enterprise workloads, scale compute across primary and replica nodes, and bring AI-native capabilities directly into the database layer. What stands out is that Azure HorizonDB gives enterprises a way to simplify architecture while also accelerating innovation. Features such as advanced filtered vector search, in-database AI model management, Microsoft Entra ID integration, and GitHub Copilot integration through the PostgreSQL extension for Visual Studio Code position it as more than a database modernization story. Developers can use Microsoft 365 Copilot with live database context to generate schema-aware SQL, explore database structures, analyze and rewrite queries, and build against HorizonDB-specific capabilities without leaving Visual Studio Code. It is designed to bring together open-source PostgreSQL, enterprise security, AI readiness, and a more integrated developer experience in a single managed service. For business leaders, that can create a faster path from data estate modernization to measurable business outcomes. In Microsoft internal testing environments, Azure HorizonDB performed three times faster than self-managed PostgreSQL. For partners, the announcement creates an opportunity to engage customers in PostgreSQL modernization, intelligent application architecture, migration planning, performance optimization, and AI-enabled development. Azure Linux: Open-source infrastructure at enterprise scale The Azure Linux public preview announcement is meaningful for leaders focused on cloud efficiency, security, and platform consistency. Linux is already foundational to modern digital infrastructure, and two-thirds of customer cores in Azure run Linux. Now Azure Linux provides a first-party Linux distribution, purpose-built for Azure, and is available for Azure virtual machines (VMs), VM scale sets, and container images. We also announced Azure Container Linux (ACL), a secure, immutable container host designed to help platform teams run Kubernetes workloads at scale on Azure Kubernetes Service (AKS). By bringing Azure Linux forward as a more visible first-party platform choice, Microsoft is giving organizations a cloud-native operating system designed for modern workloads, including virtual machines (VMs), containers, and AI infrastructure. This matters because infrastructure choices increasingly shape agility, security posture, and operating cost. Azure Linux reflects the Microsoft focus on secure-by-default design, consistent servicing, and tighter alignment between the operating system and the Azure platform. For enterprises, that can translate into simpler operations and a more predictable foundation for cloud-native applications. These announcements reinforce what the Microsoft partner ecosystem and customer usage have shown for years: open-source infrastructure is foundational to Microsoft cloud strategy, as more than 65% of customer cores in Azure run Linux. Continue reading blog here
