CIOs experiencing sticker shock from recent software bills should be questioning how they got there.

That’s because IT leaders at large enterprises are paying a huge so-called software tax for vendor-driven upgrades, migrations, and licensing changes they would not have chosen for their organizations.

About 28% of software budgets at large organizations — an average of nearly $12.9 million per year — are being eaten up by vendor-pushed initiatives, according to a survey commissioned by independent software maintenance partner Origina.

Ninety-five percent of IT leaders surveyed said their organizations have paid for a vendor-driven upgrade in the past three years that they believed would actually reduce performance, according to the survey, which covered US and UK organizations with annual revenues higher than $1 billion or with more than 10,000 employees.

The sheer size of this “software tax” surprised Tomás O’Leary, Origina’s CEO, even though the company expected to see substantial costs for vendor-driven upgrades.

“Software was supposed to make businesses better, and it does,” he says. “But it’s also imposing a hidden cost on companies, quite a significant one. I’m quite taken aback because we know this exists, but we never quantified it before.”

When vendors control your IT spend

Big vendors have several major advantages over software customers, with the cost of switching or refusing to upgrade topping the list, O’Leary notes. In many cases, CIOs are faced with a loss of support if they turn down vendor-driven upgrades, leaving them with little room to refuse, he says. CIOs dependent on VMware are familiar with this squeeze play, as are those facing SAP deadlines.

“CIOs are left in a situation where the alternative may be worse, so upgrading is the lesser of two evils,” O’Leary adds. “When people buy technology, they don’t realize how long this stuff is going to hang around. Nobody realized this thing was going to be embedded, and the dependency was going to be greater and greater with time.”

In addition, software vendors have an experience advantage when negotiating contracts, O’Leary says. CIOs and procurement officers may try to negotiate favorable terms for upgrades, but big software vendors are expert at writing contracts that give them an edge, he notes, adding that the survey results suggest IT leaders’ current approach to negotiating better contracts is a failed tactic.

“If you keep trying the same thing over and over again, and it doesn’t work, you’ve got to try something different,” O’Leary says. “There’s a relief on the buyer side when the negotiations are over, and on the seller side for sure. But the seller side has to get back up again and do it again the next morning with somebody else, and the buyers don’t.”

Omar Amassine, founder and technical director at TripleW Digital, says between 20% and 30% of the IT services firm’s software and maintenance budget goes to vendor-driven migrations he didn’t request.

The biggest culprits? CRM, marketing automation suites, and cloud infrastructure, he says.

“Vendors frequently bundle mandatory AI features or restructure seat-based pricing into usage tiers, driving effective 20% to 35% price jumps with zero incremental utility for the core workflow,” he says.

IT leaders can fight back, however, by using modular, open standards and headless architecture, he adds. “The less proprietary logic locked inside a vendor’s walled garden, the higher your leverage when they mandate expensive upgrades,” Amassine says.

TripleW Digital also runs migration feasibility studies six months before software contract renewals. Having a migration roadmap can bring the vendor back to the negotiating table offering multi-year price freezes, he notes.

Emphasize partnership — and a credible threat of defection

Zachary Lewis, CIO of University of Health Sciences and Pharmacy in St. Louis, hasn’t seen the same software spending mandates as the organizations reflected in the survey.

The university has negotiated many of its software contracts to ensure upgrades and security patches are handled by the vendor, either with Lewis’ approval or during an agreed-on maintenance window, he says.

Even without costly upgrades, there’s still a time tax, he adds.

“With the sheer volume of new vulnerabilities being discovered, we’re spending more time following up with vendors to make sure they’re applying patches in a timely manner,” Lewis says. “My team simply isn’t large enough to manually manage patching across every application and software component we use.”

Here, establishing a vendor management strategy that emphasizes partnership over provisioning can help. And if vendors still drive costly upgrades, IT leaders can always switch providers.

But Lewis cautions that, as tempting as that is, it’s often a complicated process.

“Switching vendors is always an option, but it’s rarely simple,” he says. “Depending on the application, you may have years of integrations, processes, and institutional knowledge built around it. Sometimes the cost of moving away from a vendor is significantly higher than the cost you’re trying to avoid.”

Customers of large ERP solutions in particular are facing a significant reckoning on decades of customizations.

Collective bargaining power comes with communication

To regain their purchasing power, Origina’s O’Leary advises CIOs and procurement officers to negotiate shorter contracts, which would enable them to renegotiate terms more often and exit more quickly if their vendor jacks up prices.

“You have to get to a point where you can have a more frequent engagement with the vendor,” he says. “Negotiate your exit, and negotiate more frequently.”

While short-term contracts may impose more up-front costs on customers, they can pay off with the additional flexibility they provide, he says.

CIOs can also turn to third-party software management firms or consider internal support of their software packages if they have the resources, O’Leary advises.

CIOs should also share their software purchasing success stories and nightmares with each other more than they do now, he says.

“We all benefit from having a little bit more collective bargaining power,” he adds. “CIOs just need to take that leap of faith that others have the same problems, and maybe we can have some sort of collective pushback on this.”

Microsoft expanded its sovereign cloud offerings on Tuesday, adding new security, governance and AI capabilities as customers, particularly in Europe, demand greater assurance over where data is stored, who can access it and how critical services operate during disruptions.

The announcement builds on Microsoft’s ongoing digital sovereignty efforts, assisting organizations in applying appropriate levels of control to each workload rather than forcing a rigid, one-size-fits-all approach.

“Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change,” Douglas Phillips, president and CTO at Microsoft Specialized Clouds, said in a blog post.

The developments come amid growing international scrutiny of how global tech providers handle sensitive data and the extent of control customers retain over their digital infrastructure.

“Three factors are driving this, including stricter data regulations, rising geopolitical tensions, and growing AI adoption,” said Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting. “Governments and enterprises want greater control over where their data is stored, who can access it, and whether critical systems can operate during disruptions. For instance, governments and big enterprises in Europe are worried about keeping their important data on an American company’s computers. Europe has proposed a new law that would limit the use of US cloud companies for sensitive government data in many areas. Microsoft is responding to these concerns while competing with local sovereign cloud providers.”

New controls across cloud and AI workloads

Microsoft is introducing the Sovereign Control Panel, a unified Azure portal experience that will allow organizations to assess their sovereignty posture, identify risks and gaps, apply controls, and evaluate workload portability. The panel is scheduled to enter public preview at Microsoft Ignite.

Expanding on Azure Key Vault Managed Hardware Security Module (HSM), which gives customers dedicated protection over encryption keys, Microsoft is now extending control beyond its own infrastructure. External key management with Azure Managed HSM is now generally available, enabling organizations to keep root encryption keys in hardware they own and operate on-premises or through a trusted third party.

In limited preview, Azure Confidential Clean Rooms will use confidential computing to support collaboration involving sensitive data, where participants will be able to analyse shared information while limiting broader exposure of the underlying data.

Microsoft is also expanding Azure Local to bring more cloud capabilities into customer-operated environments. The ability to transition workloads between connected and disconnected states is entering public preview. Additionally, DocumentDB and Blob Storage are entering public preview on Azure Local, while SQL Server on Azure Local is already generally available for connected and disconnected deployments.

On the AI front, Foundry Local is scheduled to become generally available at Microsoft Ignite for connected and disconnected operations on Azure Local. It will support local inference and agentic retrieval in natural language, backed by an expanded model catalog from Microsoft, partner networks, and the open-source community.

To further protect data during processing, Confidential Virtual Machines on Azure Local is now generally available, leveraging hardware-encrypted memory and isolation alongside workload attestation before sensitive keys or data are released.

While these additions give enterprises greater flexibility, industry analysts emphasize that localized deployments do not automatically erase vendor dependency.

“Depending upon the deployment model, in the public cloud, enterprises get better visibility, stronger access controls, and more control over encryption keys,” said Ashish Banerjee, senior principal analyst at Gartner. “In the Sovereign Private Cloud, they can operate infrastructure locally and even disconnect selected workloads from Azure. But I would not call this complete control. Enterprises still need to check whether Microsoft remains involved in identity, software updates, management, or technical support for the services they use.”

European oversight and partner options

For customers in the EU and the European Free Trade Association (EFTA), Microsoft is rolling out Data Guardian. Under this model, a trusted regional partner will provide independent oversight of remote access requests by Microsoft engineers. Simultaneously, a Production Touch Ledger will create tamper-evident logs of all technical actions performed.

Microsoft is also broadening its Sovereign Partner Ecosystem, highlighting regional operators like Bleu Cloud in France and Delos Cloud in Germany, alongside independent software vendors specializing in security, identity, observability, and backup.

Geopolitical realities and market limits

Despite these additions, analysts note that technical controls cannot eliminate geopolitical dependence entirely. US hyperscalers (Amazon, Google, and Microsoft) continue to account for roughly 70% of the European cloud market, whereas European providers’ market share has contracted over the last decade.

The new measures introduced under Microsoft Sovereign Cloud do reduce risks but cannot eliminate them. “Local infrastructure, independent encryption keys, and disconnected operations make it harder for external parties to access data or disrupt services. However, Microsoft remains subject to applicable US laws, sanctions, and export restrictions. Enterprises gain greater operational independence but not complete legal or technological independence,” added Jain.

Furthermore, while sovereign cloud capabilities can offer greater control over data, infrastructure, and operations, this often comes with trade-offs in cost, performance, scalability, and access to services.

Banerjee noted that sovereignty should be assessed workload by workload, rather than applied as a label to the entire cloud environment. Greater sovereignty generally comes with greater cost and responsibility. Local or disconnected environments may not receive every Azure service at the same time. Enterprises may also need dedicated infrastructure, specialist skills and separate continuity arrangements. On top of that, they may lose some elasticity and economies of scale.

“So, I would not recommend maximum sovereignty for every workload. Reserve it for workloads where the legal, operational or geopolitical risk genuinely justifies the additional complexity,” added Banerjee.

I have audited enough celebrated technology rollouts to notice a quiet omission across the industry: nobody talks much about what happens to the unit economics once the pilot ends and the software enters daily production.

I have anonymized the company and changed identifying details for confidentiality, but the operating economics and workflow behaviors below are taken directly from the post-implementation audit.

About six months ago, I was brought into a mid-sized enterprise to review a document workflow that had recently received an industry innovation award. The platform vendor published a case study highlighting the deployment. The trade press ran a short feature on it. Internally, the business unit sponsor pointed to a ninety percent reduction in turnaround time for vendor onboarding agreements, using that headline metric to secure a larger operational mandate for the coming fiscal cycle.

A couple quarters later, the finance team reached out with an uncomfortable question. Document volume had stayed flat, yet the monthly operating expenses attached to processing those agreements were climbing steadily every single billing cycle.

They asked me to trace the spending back through their systems and reconcile the operational data with the general ledger.

Under the previous manual workflow, an operations clerk opened an incoming contract, checked five or six key clauses against internal guidelines, verified the vendor details and filed the document away. The entire review took about four to five minutes. Using the department’s fully loaded labor rate, including benefits and allocated overhead, that came out to roughly eighty cents per document.

The automated pipeline was running between $12 and $14 for the exact same file.

The system was technically stable. It processed thousands of files a month without dropping connections or crashing servers, and the operations dashboard stayed green. But the business was spending $12–$14 to complete work that had previously cost about 80 cents.

Every enterprise award celebrates speed and throughput. Few of them audit the cost to finish a single unit of work.

Nobody caught the discrepancy during the original three-month pilot because the computing bills, data lookups and third-party model access fees had been charged to a central innovation fund. The departmental budget never saw an invoice. As far as operations was concerned, the tool was essentially free software that dramatically reduced turnaround times on incoming requests.

The moment the pilot concluded and the system moved into full daily production, the accounting changed. Corporate finance closed the innovation project code and began allocating the actual infrastructure invoices directly back to the business line. That was when the operational reality surfaced. Within sixty days of running full transaction volume on the department’s budget, the economics of the unit turned negative.

Traditional enterprise software often has a predictable cost curve. Once the baseline platform is running, processing another five hundred records usually does not require the same kind of fresh computation and external model consumption as an automated pipeline.

In this kind of workflow, each customer interaction, incoming contract or automated data extraction can trigger additional computational steps. The system had to interpret the document, check it against internal rules, compare the result with reference data and validate the answer before completing the transaction.

If an automated pipeline requires multiple model queries and several background checks to finish a task that an experienced employee used to resolve in five minutes, you have not eliminated an operational cost. You have swapped a predictable human payroll line item for a consumption-based cost that scales directly with the work.

Falling model prices don’t mean falling workflow costs

The standard counterargument is that computing power is getting cheaper. That part is true. Research published in the Stanford HAI AI Index Report documented that the cost of querying benchmark foundation models dropped by more than 280-fold between late 2022 and late 2024.

It is tempting to assume that automated business processes will experience the same cost reductions.

In practice, a dramatic drop in per-token rates does not guarantee a lower operating bill if the production workflow performs significantly more retrieval steps, document parsing passes and validation checks to complete a single business task.

Gartner’s latest forecast points to the same tension, predicting that inference costs per agentic workflow will increase more than fivefold through 2028 as increasingly complex workflows offset falling model prices.

Both things can be true at the same time: base model prices can fall while the total cost of completing a business transaction rises.

Cheap models do not guarantee cheap business processes.

The economics of an automated system depend on the cost of the entire workflow, not just the base model.

Production complexity is where the bill gets bigger

During our audit, the operational problem showed up the moment real-world documents stopped looking like the clean samples used during vendor sales demonstrations.

The demonstration files were digitally generated PDFs with uniform fonts, consistent layouts and standard contractual language. The live production queue was full of low-resolution scans, photocopied forms rotated sideways, documents with handwritten marginal notes, and agreements containing conflicting payment terms.

A human operations specialist can often resolve that kind of ambiguity with a quick judgment call based on institutional context. The automated workflow struggled when the document fell outside the assumptions built into the process.

When the system encountered messy formatting or contradictory clauses, it triggered extra processing routines. It ran multiple extraction passes, queried internal reference databases and executed secondary verification checks to resolve the ambiguity. Each extra step added to the cloud invoice, yet the system still struggled to reach an acceptable confidence score.

When confidence fell below the required threshold (which occurred in roughly forty percent of daily transactions), the pipeline halted and routed the file into an exception queue.

That created a secondary labor expense the original business case never budgeted for.

When an agreement landed in the exception queue, an operations specialist had to log in, read the system’s partial extraction notes, diagnose why the software stalled and manually enter the correct data into the core database. Because the specialist had to review both the original document and the system’s confused output, resolving an exception took ten minutes (twice as long as the original manual baseline).

The company found itself paying twice. It was paying the full monthly cloud invoice for the automated software, while simultaneously retaining the payroll cost of the operations staff required to supervise the exceptions.

Goldman Sachs has raised the broader macroeconomic question of whether the massive corporate spending on AI infrastructure will produce productivity returns sufficient to justify the investment. Our audit showed what that question looks like inside a single department: replacing an eighty-cent clerical task with a fourteen-dollar automated pipeline that still requires human labor for four out of every ten transactions.

The problem rarely comes from the user-seat price on the purchase order. It comes from what the system consumes to complete the work.

The vendor can price the platform around usage, but the customer owns the business case. If an automated pipeline requires multiple processing passes to interpret a crooked document scan, the customer still has to absorb that consumption whether the final output is usable or not.

When you scale a human operations team, the additional cost is relatively predictable. You know what another specialist costs in wages, benefits, equipment and management time. For this kind of workflow, automated costs can rise with the ambiguity of the inputs.

When the fiscal quarter wraps up, this creates an organizational disconnect where every department claims victory while the business loses margin:

• The engineering team reports ninety-nine percent system uptime and clean infrastructure performance.
• Operations leadership reports that turnaround times on clean files dropped from forty-eight hours to under a minute.
• The software vendor references the client in marketing collateral as evidence of enterprise transformation.
• Finance is left trying to figure out why the cost of goods sold increased while revenue stayed flat.

When leadership asks why an automation milestone fails to improve operating income, engineering points to platform uptime, product leads point to system adoption and software vendors point to successful transaction counts. Every department hit its individual performance goals. Yet the business process itself became strictly more expensive to run than it was before the project started.

In this deployment, the team tried to fix the issue by adding secondary filtering scripts and tuning prompt instructions. Those additions increased system complexity and cloud consumption without solving the core unit cost problem.

An automated workflow can execute with zero technical errors while still undermining departmental margins.

Three questions before you call an AI project a success

Before approving a production, rollout or expanding an automation pilot, finance and technology leaders should put three direct questions to their teams:

• What does one completed transaction actually cost compared with the manual baseline, accounting for all infrastructure compute, database lookups and third-party model charges?
• How often does a human still have to intervene, and what is the loaded payroll cost of that review time?
• Do the economics still work at production volume, or is the organization simply moving an operational expense from payroll into an unpredictable consumption meter?

If the economics only work during the pilot, the system is not creating operational leverage. It is creating an operating expense the pilot never measured.

Google is overhauling its cloud modernization portfolio by bringing its existing migration and modernization tools along with new agentic migration tools and a new Modernization Hub under a new Google Cloud Modernize umbrella to accelerate infrastructure and application transformation at enterprises.

The new agentic tools include an EKS-to-GKE Migration Agent, designed to help enterprises move Kubernetes workloads from Amazon EKS to Google Kubernetes Engine (GKE).

The agent can analyze existing EKS environments, translate Kubernetes manifests, map storage and networking requirements, and help prepare workloads for deployment on GKE, with human approval points built into the process, the company wrote in a blog post.

Alongside that agent, Google is also adding new capabilities to its Migration Center’s Quick Estimator Agent. These new capabilities will allow enterprise users to generate total cost of ownership estimates from infrastructure data, including VMware inventory exports, and test different migration scenarios and cost assumptions in natural language.

The Migration Center itself is being rolled into Cloud Modernize and will continue to offer tools around migration planning and assessment.

Beyond the agentic capabilities and the Migration Center, the hyperscaler is consolidating its application modernization tools, such as the App Modernization CLI, Java and .NET modernization capabilities, and mainframe tools including the Mainframe Assessment Tool, Dual Run and Mainframe Connector, under a new Modernization Hub.

The new Hub, which will be accessible via the Google Cloud Console, will also be a part of the umbrella offering, the company wrote.

Unification of tools could simplify operations

For CIOs, the consolidation of existing modernization and migration tools under a broader umbrella offering could simplify operations and decision-making as it turns what was previously a collection of separate tools into “one end-to-end process”, said Pareekh Jain, principal analyst at Pareekh Consulting.

“An enterprise might have VMware workloads, Java applications, mainframes, Oracle databases and Kubernetes applications running across different clouds. Previously, these could require separate tools, assessments and migration teams. With the broader offering, CIOs require fewer handoffs, faster decisions and better visibility across a large modernization program,” Jain said.

The consolidation of the Modernization Hub also provides similar benefits.

“Instead of fragmented tools, the new Hub provides a consolidated assessment workflow. It gives CIOs one place to assess, plan and manage application modernization,” said Viet-Anh Nguyen, machine learning lead at Scopic Software.

“Earlier, capabilities were spread across different Google tools. Teams can now understand applications and dependencies, get modernization recommendations and decide what to migrate, rehost or refactor from a more unified interface,” echoed Jain.

Similarly, the EKS-to-GKE Migration Agent could reduce the manual work for developers and platform teams.

“Since the Agent can automatically discover and translate AWS-specific infrastructure and Kubernetes configurations, validate the outputs, and create pull requests for human review, it reduces repetitive engineering,” Nguyen said.

That, in turn, could make switching clouds faster, cheaper, and less risky, Jain pointed out.

However, the Agent doesn’t eliminate testing, architectural decisions, data migration, or production cutover, which means teams still have to own these steps, Jain said.

The article originally appeared on NetworkWorld.

AWS is applying AI to the challenge of evaluating and improving cloud environments with a public preview of a new agentic service aimed at automating the discovery and optimization of architectural issues.

Despite its name, AWS makes no claims for the architectural qualities of its Well-Architected Agent, the name of which refers to a long line of frameworks and tools for cloud architecture management dating back over a decade. AWS launched the first, the Well-Architected Framework, in 2015, later introducing the Well-Architected Tool in 2018 to help customers review their own workloads against the framework’s best practices.

In contrast to the Tool’s reliance on enterprise teams to provide information about their workloads through a structured set of questions, the Agent analyzes the AWS environment itself and uses that information to generate recommendations, the company wrote in a blog post.

Enterprises can also give the agent business objectives and application context to enable it to rank its findings against those goals, AWS said.

The Agent surfaces recommendations at three levels: individual resources, applications, and overall architecture, suggesting remediation steps and identifying their potential cost impact.

Those remediation steps can include environment-specific implementation guidance such as console walkthroughs, AWS CLI commands, and updated infrastructure-as-code changes, AWS said, while the existing Tool merely proposes an improvement plan.

Optimizing cloud optimization

For enterprise users, particularly cloud architects, DevOps teams, and platform engineers, the new agent can speed up optimization and change the way they manage cloud environments, moving from periodic architecture reviews and reactive remediation toward more continuous, AI-assisted optimization, said Siddharth Mehta, research leader at consulting and services company Avasant.

That shift in how cloud environments are managed will become increasingly relevant as enterprises scale agentic applications, according to Nhat Bui, deputy director of engineering at Scopic Software. 

“First, AI applications change faster and have less predictable cost profiles than traditional workloads, so a review done last quarter goes stale quickly. Second, more infrastructure is now being written by AI coding tools, and human reviewers can’t keep pace with that volume,” Bui said.

There are limits to the agent’s ability to offer timely recommendations, though: “The Agent refreshes resource-and application-level recommendations weekly, while architecture-level recommendations are generated through on-demand reviews,” Bui said. That distinction could be particularly important for fast-changing workloads, including agentic applications, where infrastructure and resource usage can change between recommendation refreshes, he added.

That said, the new agent could help accelerate the pace of cloud-related decision-making, said Pareekh Jain, principal analyst at Pareekh Consulting. “Instead of giving CIOs hundreds of technical recommendations, the agent can help identify which improvements matter most to the business. That means CIOs can decide where to prioritize cloud investments and engineering resources, and where to accept trade-offs,” he said.

Limitations of the new Agent

However, the Well-Architected Agent has its own set of limitations, said Mehta. “The Agent only understands the context available to it. It may not know about regulatory obligations, third-party dependencies, business-process dependencies, contractual SLAs, internal risk appetite, multi-cloud dependencies, and organizational policies not represented in AWS,” he said. “Therefore, business-goal alignment improves prioritization but does not replace enterprise architecture or risk governance.”

For Jain, however, the bigger limitation is the Agent’s requirement for a high-tier AWS Support plan, which could limit its adoption among enterprises that do not already subscribe to those plans.

The Agent is available only to customers on AWS Business+, Enterprise On-Ramp, Enterprise Support, or Unified Operations plans, unlike the Well-Architected Tool, which does not require a paid Support plan, he said.

Moreover, Mehta said, the Agent is narrower in scope, currently covering cost, security, performance, and resilience, while the Well-Architected Tool continues to support all six pillars of the Well-Architected framework, including operational excellence and sustainability.

There is no specific additional fee for the Agent or the Tool, although enterprises are charged for some of the underlying AWS resources, services, and data that they consume, including those from Trusted Advisor, Compute Optimizer, Security Hub CSPM, Resilience Hub, Cost Optimization Hub, and Cost Explorer.

Sumit Johar has been modernizing BlackLine’s IT environment since becoming CIO of the software company in early 2024.

As a longtime IT leader, Johar has plenty of experience overhauling tech stacks, but he says the work has taken on new meaning — and urgency — in the AI era.

“The definition of modernization has literally switched in the last two to three years,” he says. “Suddenly everything that you built in the last few years looks like legacy, because the SaaS model, which we have been using for the last 10 to 15 years, there is an opportunity now to totally change that and modernize with AI and for AI.”

Johar is doing just that, surveying the company’s SaaS portfolio, particularly zeroing in on point solutions, asking whether each is worth the cost, whether it delivers true business value, or whether IT can use AI to build a service better suited to his company’s needs.

At the same time, AI is changing how workers interact with technology, he says, enabling people to query applications via natural language and chat, which has his IT team considering which applications may need to be modernized or abandoned altogether as a result.

Take, for example, dashboards. “We built dashboards because there was no other or better way to report on your data,” he says. “Now I can simply ask a question and get an answer, which is what I was interested in anyways. So if I have my ERP and CRM talk to me in a human language, I’m happy with that. That’s modernization.”

As a result, he adds, “some of us might be getting rid of [our dashboards], and some might be slowly reducing the dashboarding tools we have.”

As organizations remake and automate workflows with AI, software that enables those workflows could meet a similar fate, Johar says.

Even chatbot-building products that IT implemented a few years ago are prime targets for rationalization due to AI advances, he adds. “I still need chatbots, but I don’t think I need specialized software to build a chatbot anymore. Any generic AI platform that I have will give me the ability to basically build them,” he explains.

High-priority tasks

For Johar, the longstanding CIO tasks of modernization and rationalization remain make-or-break activities for IT.

Johar and other IT leaders see modernization and rationalization as vital to controlling IT spend — as high of a priority for CIOs as it’s ever been, freeing up dollars for innovation (the No. 1 objective for nearly every IT leader and their CEO’s top priority).

IT leaders also see modernization helping them create a future-ready IT environment, one that’s not encumbered by legacy technologies and complexities that don’t play nice with emerging technologies.

“CIOs don’t have much of a choice than to continue modernization; they’re in a perpetual state of modernization,” says Amar Aswatha, senior vice president for global business engineering at CGI, a consulting and services firm. “They’re trying to simplify yesterday’s tech state while creating resilience and the right environment for AI and to be ready for whatever will emerge.”

Other factors also drive the need for ongoing modernization, Aswatha notes. The rapid pace of innovation is reducing the shelf life of many technologies more quickly, necessitating more rapid overhaul cycles than in the past. Meanwhile, the past decade’s mass migration to the cloud has meant that CIOs “traded server sprawl for subscription sprawl,” he says. The rush to adopt AI is having a similar effect, leading to AI and agent sprawl — and the need for new and more widespread rationalization and modernization strategies.

Still, CIOs must be more surgical than they’ve been in the past, using a scalpel not an ax to shed legacy technology and simplify IT environments, Aswatha advises.

That means accounting for both current and emerging business needs when determining what systems should be modernized — not simply relying on age or other such non-business-related factors. And IT leaders can’t see rationalization as an exercise in reducing application count to a set number; unnecessary complexity should instead be the target.

Such approaches require CIOs and their teams to understand current and future business needs, as well as how those needs, and the organization’s overarching strategy, shift over time, Aswatha says.

“CIOs have to watch for business signals on when and what to modernize and rationalize. It’s not about spring cleaning, it’s about what apps are slowing the business down,” he advises.

‘Best for the organization’

Rachelle Putnam, vice president and CIO of General Dynamics Land Systems, which manufactures military vehicles, is taking such an approach.

Putnam, who has led IT at the company since 2014 and managed a move off a mainframe about a decade ago, says modernization today means asking whether existing technology “allows us to have the flexibility and the functionality we need.”

Like many CIOs not on IT’s bleeding edge, for Putnam savvy modernization is about strategy, not technology. “Some might say we’re not on a modern tool set, but that doesn’t mean we don’t have the functionality we need,” she says.

For example, Putnam embraces a cloud-smart strategy, modernizing on the cloud where it makes sense and on-prem when that’s the better or required option based on government regulations.

She applies a similar lens to rationalization, asking whether any given application uniquely fulfills a business need or whether other apps in the portfolio can do the job. Such questioning helped her standardize the company on two CAD tools, down from 10, and standardize on one reporting tool instead of using three.

Putnam is also increasingly asking whether she even needs a vendor solution.

“With tools like Claude Code, when we look at [vendor-offered] apps, we ask if we even need them or whether we can create our own and not pay for maintenance,” she says. “Sometimes we want SaaS, where we want those updates, but there are others that we don’t need updates and won’t need to change the application much, so those are the ones we’re going to look at creating ourselves.”

Like other CIOs, Putnam believes modernization produces benefits for IT and the company as a whole, ensuring the organization not only has the technology necessary to perform but also a standardized data environment so that “everyone is looking at the same data, and it means the same thing,” she says.

In addition to cutting IT maintenance and management costs, modernization also reduces risks, by eliminating unsupported legacy tech and difficult-to-manage complexity.

And it makes IT talent more effective and efficient, by eliminating the need for outdated skills, which are typically hard to find and thus come at a premium. With rationalization, IT teams no longer must learn multiple vendor solutions or assign different workers to different solutions.

Modernization challenges

Of course, Putnam and other IT leaders acknowledge there are challenges to modernization and rationalization, too.

“Cost is certainly one. Sometimes it costs more to get off one than continuing to run multiples,” Putnam says.

Even in such cases, however, hard-to-quantify benefits make the move worth it, she adds. For example, rationalizing to one common system used throughout the company’s multiple geographic locations means workers anywhere can easily be assigned to help when one region faces a surge in work.

Data migration is another common challenge. But data issues can usually be overcome with “creativity, mostly, and having someone dig down to really get it done,” Putnam says. Sometimes it may mean shelving the data and only retrieving it if necessary.

Then there’s the challenge of limiting future rationalization by controlling what gets added to the IT environment today. To that end, deploying and using a common tool is the default standard now at General Dynamics Land Systems.

“That’s a rule that everyone abides by,” Putnam says, acknowledging some pushback. “Sometimes people will argue for that extra 15% that one tool might have that the existing tool doesn’t have. But we stress that standardization is best for the organization as a whole.”

A staple of CIO work

Krishna Prasad, CIO of UST, a digital transformation and IT services provider, similarly sees modernization through a business — not a technology — lens today.

Whereas modernization was once triggered by advancements that made existing tech outdated, obsolete, or no longer supported by the vendor, now modernization is triggered when business advancements render a deployed technology deficient, he says.

This new scenario has CIOs, including himself, modernizing faster than in past eras, Prasad says. And it’s why modernization remains a core component of the CIO role.

“Modernization means meeting today’s business needs, and that may mean we need to deploy a new version of [a technology] to get a better experience, speed, agility, or in a way that we can provide transparency,” he adds. “So, at UST we have always thought about modernization as a continuous process.”

For example, Prasad is currently modernizing the company’s CRM platform, even though the existing one would not be considered legacy tech using a traditional definition. Yet the deployed CRM wasn’t providing the capabilities UST needed for its sales department to deliver on the company’s vision.

“We weren’t having a good user experience, and sellers weren’t updating the information as they should, so we didn’t have real-time data and then the operations team had to do the data entry, so you had cost there, too, and we had reduced agility as a result,” Prasad explains.

Similar factors are at play when it comes to rationalization, which he believes should also be an ongoing concern for CIOs.

Despite the benefits these efforts bring, Prasad acknowledges the heavy lifts involved, ones that many organizations aren’t yet prepared to undertake. For example, UST still has a financial system running on premises, and because the complexity of “disentangling the financial systems from the guts of the business is challenging, it’s a change that the business isn’t willing to make right now,” he admits.

Such situations ensure modernization projects will remain a core IT task in the years ahead.

See also:

• 6 strategies for accelerating IT modernization
• 8 IT modernization traps CIOs must avoid
• Massive modernization: Tips for overhauling IT at scale

For most of computing history, performance was an engineering problem you could reason about at your desk. Profile the code, count the database calls, size the hardware. If a system was slow, the cause was usually something you could hold in your head: an unindexed query, a synchronous call that should have been async, a loop that ran one order of magnitude too many times. You could draw the system on a whiteboard, and the whiteboard would basically be correct.

That era is over. In cloud-native systems, performance has become an emergent property. It arises from the interaction of many moving parts, most of which you don’t directly control, and that shift changes how we have to engineer for it. The core argument is simple to state and hard to internalize: in a modern-day distributed system, you cannot optimize what you cannot observe.

Performance is no longer about your code

Consider what actually determines the speed of a cloud-native application today. It’s spread across dozens of loosely coupled microservices. Those services share network fabric and physical infrastructure with other tenants on a Kubernetes cluster. They’re scheduled into containers by an orchestrator making placement decisions you never see, filtering and scoring nodes behind the scenes before binding a workload to whichever one wins, and they scale up and down automatically in response to demand that arrives in unpredictable bursts.

In that environment, application behavior is driven less by algorithmic efficiency than by distributed orchestration, virtualization overhead, and workload variability. A minor shift in traffic distribution or container scheduling can introduce a bottleneck that’s genuinely difficult to diagnose after the fact, because the conditions that caused it may no longer exist by the time you go looking. Inter-service calls that look trivial in isolation — a few milliseconds here, a few there — accumulate into measurable delay across a long service chain, the same way a handful of small taxes compound into a large bill.

And in a multi-tenant cloud, a competing workload can degrade your responsiveness in ways you can’t reproduce on demand. This is well known enough in cloud architecture circles to have its own name: the noisy neighbor problem, where one tenant’s activity on shared infrastructure quietly degrades another’s performance even though nothing in your own stack changed. The performance you get is the sum of all these interactions, not just a property of any single component you wrote.

Why traditional monitoring falls short

The instinct is to throw monitoring at the problem. But there’s a meaningful difference between monitoring cloud-native systems vs. actually exposing where fault could lie. And that is exactly where that difference matters. Cindy Sridharan made a case earlier, describing traditional monitoring as failure-centric, built around a list of known ways things break, whereas observability is meant to support open-ended debugging of failures nobody predicted.

That distinction matters in practice because averages are exactly the wrong lens for distributed systems. Average latency can sit directly on top of a system that is intermittently unbearable for a meaningful slice of users, and because averages smooth over the short-term, however, it is the sharp events that hurt the most. This isn’t a new observation; in the now-classic paper on large-scale systems, Google engineers Jeff Dean and Luiz André Barroso described how tail latency at scale becomes the dominant experience for users of any sufficiently large distributed system, because a request that fans out to hundreds of components only needs one slow component to become a slow request overall. As a system grows, the odds that at least one component is having a bad moment approach certainty. Averages don’t see that. Observability, done well, means being able to ask why a specific request was slow and reconstruct the answer from execution traces, logs, and fine-grained runtime telemetry across every service that request touched. The goal isn’t a prettier dashboard. It’s the ability to follow one request through the system and see exactly where the time went.

Designing for runtime, not just design-time

The deeper lesson is about when we assess performance, not just how. For years, performance testing was a design-time activity: run a load test before release, and if the numbers look good, ship. Cloud-native systems break that assumption, because so much of what affects performance — scheduling decisions, autoscaling behavior, neighbor interference, resource contention under real traffic shapes — only exists at runtime and only under real workloads. Offline benchmarks against fixed, synthetic traffic patterns simply don’t capture it, because production traffic doesn’t arrive in the tidy, evenly distributed way a load-testing script assumes.

So, performance assurance has to move closer to production: continuous telemetry from running services, compared against known-good baselines, so that degradation is caught as it emerges rather than discovered after users feel it and complain. There is a growing body of research pushing in exactly this direction, on observability-driven and adaptive autoscaling approaches that use runtime signals rather than fixed thresholds to decide when and how to scale. The results across that research vary by system and workload, and the specific percentage improvements aren’t  quoted as a single universal number. What is consistent is the underlying finding: systems that scale and adapt based on what’s actually happening at runtime tend to outperform ones that rely on static, pre-configured rules, particularly on tail latency, which is the metric static rules are worst at protecting. The specific numbers in any one study matter less than what produced the improvement: measuring the system as it actually runs, not as it was assumed it would run when someone configured the autoscaler months earlier.

The takeaway

Cloud-native architecture gave us tremendous flexibility, and it took away our ability to reason about performance. The right response isn’t to fight that trade. It’s to accept it and instrument accordingly.

Treat observability as a design requirement, not an afterthought bolted on after an incident. Measure at the percentiles, not the averages, because the averages are hiding the exact failures that matter most to real users. And assess performance where it actually happens: at runtime, under real load, continuously, rather than only in a pre-release load test that can’t anticipate what production traffic will actually look like.

In systems this complex, visibility is the prerequisite for everything else. You can’t optimize what you can’t observe, and you can’t observe it unless you designed it, from the start, to be seen.

Alternative clouds have emerged amid major cloud providers such as AWS, Google Cloud, and Microsoft Azure, and often specialize in niche areas like AI-native computing, and sovereign and edge deployments, while professing to provide cost reductions and best-of-breed performance.

“Many organizations are rebalancing away from all-in hyperscaler strategies to avoid lock-in and concentration risk,” says Kyle Campos, CTPO at CloudBolt, a cloud management platform. “At the same time, alternative clouds are often purpose-built for specific advantages.” To him, benefits include lower-cost object storage at scale, better edge performance for latency-sensitive apps, and faster access to dedicated GPUs for AI workloads. Data sovereignty is also pushing adoption of localized providers.

But as alternative clouds, also called neoclouds, make headlines and amass considerable funding rounds, their use in enterprise environments remains relatively nascent. While enterprise executives see the potential in using alternative clouds, especially for GPU workloads, many are skeptical, taking a balanced approach to assessing maturity, costs, and whether it’s worth sacrificing continuity with existing clouds.

Smartsheet CIO and CISO Ravi Soin is one of these executives taking a measured approach. “We’ll grow our use of alternative clouds, but within a clearly defined perimeter,” he says. “That discipline is what separates considered adoption from sprawl.” For Soin, many neoclouds still fail early in the evaluation process, especially for regulated workloads where a mature compliance posture is non-negotiable.

In order to fully evaluate alternative clouds, the platforms must be treated with the same vigilance as any other IT acquisition. “This remains consistent across any tech stack: fit, form, and function,” says Nigel Gibbons, director and senior advisor at the NCC Group, a cybersecurity consulting firm. “This means alignment of the cloud to workload performance, security, and sovereignty needs.”

Overall, CIOs aren’t rushing into alternative clouds. It’ll take a serious proof spanning regulatory impact, auditability, resilience, and total cost planning in order to convince large organizations to migrate away from well-established cloud infrastructure. More realistically, such clouds will be evaluated on a per-workload basis.

Compliance and transparency

When evaluating neoclouds, compliance is top of mind for enterprise executives. “Compliance posture such as SOC 2, ISO 27001, and sovereign-specific certifications like FedRAMP or IRAP is the first filter and, for most neoclouds, an early exit,” says Soin.

Smartsheet runs AI on enterprise customer data and therefore requires strict compliance and sovereignty frameworks. “That defines a hard boundary where regulated workloads stay with certified providers,” he adds. “Workload identity doesn’t federate natively across clouds, so every trust relationship must be hand-built and audited. For a platform where data sensitivity varies enormously, that governance gap isn’t theoretical.”

Gibbons adds that trust validation is becoming a pressing requirement from regulators and the overall market. “The uncomfortable truth is that most organizations have operated on deferred risk captured in registers, softened in board narratives, and tolerated due to limited visibility,” he says. The pattern of tumultuous changes in the AI market, he adds, is encouraging more of a resilience mindset among technical executives assessing new technologies.

Operational transparency is another pressing area to evaluate. For Soin, the infrastructure that supports AI workloads requires granular auditability. “Can the provider give you end-to-end observability across the inference layer: tamper-evident logs, model versioning, the ability to trace what happened to customer data from input to output?” he asks.

Smartsheet’s enterprise customers also ask how AI is applied to their data and what controls exist, and that answer has to be defensible. “A neocloud that can’t support it isn’t just an operations risk, it’s a risk to the customer trust our business is built on,” he says.

Per-workload evaluation

Although neoclouds are often framed as a replacement to hyperscalers, they’re more often complementary infrastructure, purpose-built for individual use cases. “A neocloud isn’t a type of cloud, but more a design principle,” says Gibbons. “We can think of it as infrastructure optimized for a specific workload, trust model or control requirement, rather than general-purpose scale.”

Their usage hinges on the project at hand, which typically involves AI/ML projects. “We work with a mix of alternative providers depending on workload fit,” says CloudBolt’s Campos. “We’ve used alternative cloud providers for VMware as part of a cloud migration strategy.” Their customers use alternative clouds for object storage, edge and low-latency needs, AI/ML GPU capacity, and legacy virtualization workloads that don’t map cleanly to hyperscaler-native services.

Executives must determine which environment makes sense for the workload at hand, and act accordingly. “CIOs should begin by clarifying the specific workload opportunity an alternative cloud is meant to accelerate, then evaluate providers against developer and operator experience inclusive of ability to scale with business need,” adds Campos. “From there, the priorities are whether the platform can be governed and operated alongside existing clouds, with strong visibility into usage and unit economics. Security, compliance posture, and credible SLAs for reliability and performance should be evaluated at the same bar as hyperscalers. The goal is to add flexibility without creating a new operational silo.”

Not all workloads are a fit for neoclouds or alternative providers, however. While these platforms benefit numerous workload-specific options, they’re not viewed as wholesale replacements for hyperscalers. For general-purpose enterprise functions, hyperscalers may still retain advantages around integrated services, discounts, operational maturity, and the availability of relevant job skills.

For this reason, many technology leaders are still in an exploratory phase. “Our infrastructure today runs on hyperscalers, and that’s been the right choice for where we’ve been,” says Smit Shanker, global CIO of Xebia, a global IT consulting and software engineering company. Still, he encourages CIOs to begin actively evaluating alternatives. “We’re now in that evaluation phase, looking at where specialized providers, sovereign options, or hybrid approaches make more sense for specific workloads.”

Shared responsibility model

CIOs require a high-degree of enterprise-grade trust that must be codified beyond empty promises and proven under real-world stress tests. As such, before diving headfirst into a newfangled cloud, Smartsheet’s Soin advocates verifying its shared responsibility model, which stipulates commitments the cloud provider has to uphold, and where responsibility lies with consumers.

For Soin, it’s especially critical to understand how a cloud provider acts when incidents occur. “Request post-incident reviews before signing anything, not templated RCAs but the real communication timeline,” he says. “Shared responsibility models are well-documented until they’re tested. Find out what happened the last time they were tested.”

Ultimately, alternative clouds need to meet the same enterprise maturity bar as established cloud providers. “Assurances must include auditability, compliance, resilience, transparent SLAs, interoperability, portability, and independently validated trust, not vendor assertions,” says NCC Group’s Gibbons.

Total cost analysis

Understanding the economic impact is necessary to determine whether an alternative cloud is worth it for the business. This is an area where alternative clouds shouldshine, with reports estimating savings of up to 70% compared with hyperscaler GPU instances. Traditional cloud computing pricing models are often opaque, and charges related to add-ons, upsells, and hidden fees around egress and ingress are notoriously known to surprise cloud computing consumers.

For certain workload categories, the economics can favor alternative clouds. “Traditional cloud providers often impose substantial data egress fees that inflate the total cost of ownership for data-heavy architectures,” says Dave McCarthy, VP of cloud and infrastructure services at global market intelligence and advisory firm IDC. “Alternative providers frequently minimize or eliminate these bandwidth penalties entirely, offering a more transparent cost structure,” he says.

Still, a full cost audit is necessary before going all-in on an alternative cloud. “What I’d recommend to anyone is do the full-cost model before you commit,” says Shanker. He suggests conducting a comprehensive analysis of cloud compute, inference, API volumes, and maintenance costs for things like infrastructure upgrades projected against the actual demand curve. When viewed together, he says, they create compounding costs that most C-suites haven’t modeled.

“Most enterprises are still modeling cloud economics on implementation costs alone, and that’s incomplete,” he adds. “The organizations getting AI right are the ones treating infrastructure economics as a first-class design decision, not a footnote.”

As cloud infrastructure choices can produce vendor lock-in, CIOs should use all the criteria at their disposal to plan and inform a neutral decision-making process. “Whatever path you choose — hyperscaler, alternative, sovereign, or some combination — the discipline that matters is vendor-agnostic, framework-led design,” adds Shanker. “Don’t let infrastructure choices constrain what’s possible.”

Where the market is heading

Neoclouds have made a mark for themselves by offering direct access to latest-generation hardware, which is important for AI-focused workloads requiring high performance. There’s also the argument that opting for alternative clouds aids a distributed multi-cloud strategy, which can benefit resilience and meet certain regional sovereign cloud mandates.

Nearly 90% of IT leaders say an organization should never commit to one cloud provider for their entire architecture, according to a HostingAdvice survey from last year. The same study found 73% of leaders use two or more alternative cloud providers, underscoring a clear interest in alternative clouds.

Still, while some industry reports are favorable, enterprise executives express more of a cautious reality of selective evaluation, not wholesale migration. For Soin, a top concern is the compliance posture and observability capabilities for alternative clouds, especially when hosting workloads that run AI inference. “The question isn’t just where inference happens but whether we can see what happened, explain it, and stand behind it,” he says. “That obligation shapes which providers are even in the conversation.”

While state-of-the-art cheap GPU compute is alluring, CIOs should keep an eye on the full governance picture when evaluating alternative clouds. “The neoclouds that earn more of our workload won’t just be the ones with the best GPUs,” says Soin. “They’ll be the ones that have seriously invested in model governance infrastructure and can demonstrate it. That’s a higher bar than most currently clear, but it’s where the market needs to go.”

A focus on inference

IDC forecasts that by next year, the computational demands of AI will force 80% of organizations to modernize legacy cloud environments by switching to platforms designed for AI workloads, with half of this being processed locally on endpoints or edge nodes by 2030.

“Enterprises are increasingly looking beyond major hyperscalers to avoid vendor lock-in and optimize specialized workloads,” says IDC’s McCarthy. “Rather than relying on a single, centralized infrastructure, organizations are adopting these alternatives into a broader portfolio.”

Much of this new computing paradigm will center on inference, or the post-training execution of AI models in production, using live customer or enterprise data. As inference moves into more business-critical workflows, decisions about where those workloads run, and what criteria guide those decisions, will have long-term implications.

Alt and neo clouds will likely have their place in inference, as well as in future sovereign and decentralized cloud models, and it’s not a decision CIOs should take lightly or without an informed evaluation framework. “Where workloads run becomes one of the most consequential decisions a leader makes,” says Shanker.

Oracle is adding a new execution layer to its Fusion Cloud Applications Suite that it says will help enterprises lower the costs of automating complex and long-running business processes with AI agents.

The execution runtime, Fusion Claw, uses a combination of a frontier model, deterministic policies, and governed execution capabilities to plan and carry out a given task or process, instead of relying for each step on AI inference, which can result in repeated model calls as the task progresses. That can help enterprises keep inference and compute costs under control, the company said.

The deterministic policies can include approved algorithms, business rules, calculations, optimization services, reconciliation logic, and transaction-processing capabilities. Enterprises can define or configure them via Fusion’s AI Agent Studio while building the agent or modifying existing agentic applications, Oracle said.

Claw then uses two built-in features, the Enterprise Operating Envelope and the Enterprise Trust Harness, to enforce those policies as controls during task execution, ensuring that the agent operates within its delegated authority and the required governance boundaries, while also generating an auditable record of agent actions and decisions, it further said.

Fusion Claw could help improve an agent’s unit economics

For Manoj Chandra Jha, principal analyst at Nord-IQ research, Fusion Claw’s approach to agentic execution is likely to help enterprises with the unit economics of deploying AI agents to automate business processes.

“By keeping the expensive model for planning and running high-volume work on cheap deterministic computation, Fusion Claw can make agentic costs both lower and more predictable for CIOs,” Jha said.

Beyond cost, Fusion Claw’s approach to separating AI reasoning from deterministic execution can also make agentic automation more reliable and repeatable, which could be “critically important” for CIOs trying to move agentic applications from prototype to production, according to Scott Bickley, advisory fellow at Info-Tech Research Group.

The deterministic controls combined with delegated authority, approvals, escalation rules and an auditable record of decisions and transactions can give enterprises a measure of “safe autonomy,” he said.

There are advantages for developers, too, especially in terms of productivity.

As the new execution layer packages up most of the underlying plumbing stack required to operationalize an agentic application, developers can focus on process design, offloading the mundane work of integrating and orchestrating the underlying components needed to put an agentic application into production, Bickley said.

That, in turn, is likely to result in business processes being automated faster, he added.

Lower AI consumption does not necessarily mean lower costs

However, that reduction in development and orchestration work does not eliminate the work required to govern agentic applications, but rather adds to the governance work required, Jha cautioned: “Development teams must encode policies and approval rules, choose autonomy levels, and verify outcomes.”

That outcome verification will also be important for CIOs in determining whether the promised cost savings and cheaper unit economics actually translate into lower costs, rather than simply lower AI consumption, according to Bickley.

While Oracle’s architecture can reduce the amount of AI inference needed for a task, the actual cost of an agentic application can vary based on factors including the actions it performs, token consumption, model used, testing, human review, exception handling and ongoing operational support, Bickley said.

As a result, CIOs should measure the cost of successfully completing a business outcome, such as resolving an accounting exception or filling a staffing gap, rather than looking only at the cost of AI units or tokens, Bickley added.

The analyst also cautioned CIOs about Oracle’s AI unit policy, which he said could introduce additional considerations into the cost of running Fusion Claw-based applications: “Unused pooled units expire without reimbursement, while Oracle can modify its action and model tables with at least 30 days’ notice.”

CIOs should demand per-outcome pricing in writing and let a bounded pilot build the business case, said Jha.

Adoption will depend on process and governance maturity

Those considerations, combined with the added governance requirements, are also likely to shape which enterprises adopt Fusion Claw first, even among existing Oracle customers.

“Existing Oracle Fusion customers with standardized processes, reliable master data, mature controls and high-volume work with measurable outcomes are likely to be the initial adopters. Finance reconciliation, supply-chain planning, staffing and other constraint-heavy processes are logical candidates because they combine analysis with calculations and repeatable execution,” Bickley said.

On the flip side, adoption will be “slower” in enterprises with heavily customized Fusion estates, fragmented data, multiple ERP platforms, weak segregation of duties, or limited AI governance, he added.

For enterprises willing to try out Fusion Claw, the execution runtime is now available as part of the Suite, Oracle said.

The company is also making 25 pre-built Claw-powered agentic applications available, including Ledger, Workforce Staffing, Shipping Consolidation, and Sales Territory Planning, aimed at helping divisional leaders, such as CFOs, CSOs, supply chain heads, and CHROs, improve productivity and reduce costs.

The company will make the other 21 apps available in October, it said.

Enterprise software budgets haven’t shrunk this year, though we keep reading they have. Boardrooms are still approving spending on new tools at a consistent pace, and Gartner’s latest forecast puts global software spend at $1.43 trillion in 2026, up more than 15% year over year. What has changed is what buyers will tolerate to get that value, and SaaS vendors who miss this distinction will have a very bad renewal season.

Headlines call it the SaaSpocalypse. What’s really happening is a hard reset on what software charges for and how long it can lock a customer in. Three-year platform commitments made sense when the underlying technology moved slowly, but now AI models turn over every six months. Ask any CFO whether locking the business into one vendor’s roadmap still feels sensible under those conditions.

What buyers want now

Buyers want the freedom to adopt an AI capability this quarter and swap it out the next without tearing their stack apart. They want tools built to work inside an agentic environment, not bolted onto one after the fact, which in practice means proper API access, structured context handoff, and role-based permissions an agent can operate within safely. Buyers also want contract terms with genuine data portability clauses. And they want proof that a product does something genuinely beyond what an off-the-shelf agent could replicate over a weekend.

That third demand is keeping vendor product teams up at night. A thin workflow layered on top of a database used to be defensible. Today it’s a prototype an engineer could build before lunch.

At renewal time, every contract now faces the same three questions.

1. What work does this tool actually remove?
2. How well does it play with the rest of the estate?
3. How painful would it be to walk away?

Vendors with good answers are growing; the rest get folded into someone else’s platform.

Cost pressure is the excuse

It’s easy to blame this on cost pressure alone. CFOs have wanted to rationalize their software stacks for years; AI just gave them the excuse to do it finally. The last couple of years were a “try everything” era. Every business is now sitting on a waste heap of tools nobody’s had the discipline to evaluate since. Industry data on SaaS management puts the average large enterprise at around 660 SaaS applications in active use, with adoption largely flat over the past two years and per-app spend keeps climbing regardless. Nobody going back to clean houses is causing that sprawl.

Cost pressure is one driver. Tool sprawl is another, and it’s the direct hangover of that try-everything period. Software pricing has run on one assumption for two decades: value scales with the number of people using the tool, but agents break that assumption completely. Once part of a workflow runs without a human clicking through it, paying per seat starts to look like paying for headcount that no longer exists. Buyers spotted this before most vendors did, and they’re negotiating accordingly.

Vendors are responding, unevenly. Deloitte’s 2026 technology predictions point to seat-based licensing giving way to hybrid models that blend usage and outcome pricing. This is messier than the analyst reports suggest. Some vendors have moved to per-conversation or per-task credits. Others found customers wanted predictability more than they wanted to pay strictly for outcomes, and pulled back toward seat-based pricing with usage caps layered on top. Nobody has fully solved it yet, so treat any vendor who claims otherwise with some skepticism.

There’s also a lot of noise about agents replacing traditional interfaces outright. Talk to the people actually running mission-critical operations, and you get a different picture. Nobody serious is letting an autonomous agent operate freely inside a production SAP environment, and nobody serious is planning to any time soon. Instead, they’re asking two much narrower questions of every vendor: can this platform give an agent the context it needs and let it act safely within limits? Does the platform add value an agent couldn’t produce on its own? Strip away the AI framing, and this is an outcomes conversation wearing new clothes: fewer incidents, faster audits, and less unplanned weekend work.

The SAP deadline nobody can ignore

For the SAP ecosystem, there’s an added forcing function. Solution Manager exits mainstream maintenance at the end of 2027, and it isn’t going alone. SAP Process Integration and Process Orchestration, both still built on the older NetWeaver stack, are retiring on the same timeline, with Cloud ALM and the Signavio portfolio positioned as the replacement. That’s a genuine architectural change, moving from an on-premises, monolithic management layer to a modular set of cloud-native tools connected through SAP’s Business AI Platform.

Every enterprise running SAP has to rebuild part of its operations toolchain regardless of what else happens in the market. The smart ones are using that forced migration as cover to consolidate around fewer, more open platforms rather than replacing what they had piece for piece. The less smart ones are treating it as a like-for-like swap, migrating their old Solution Manager processes into Cloud ALM without questioning whether those processes should exist in their current form at all. That’s a wasted opportunity. When you’re forced to rebuild the toolchain anyway, that’s exactly the moment to ask which parts should stay proprietary to SAP and which parts should sit in an open, vendor-neutral layer instead.

Every agent needs eyes and hands

This is where the real opportunity sits, and it isn’t in defending the old per-seat model or racing to absorb everyone else into a smaller stack.

Both paths have a shelf life.

Being part of a smaller consolidated stack is fine if you’re the vendor doing the consolidating. For everyone else pulled into it, whoever now owns the relationship usually squeezes price and roadmap.

The lasting opportunity is the layer that sits across systems and gives agents the two things they never arrive with: trustworthy context about what’s happening across the estate, and a governed way to act on it. Observability and automation, in plain terms. Every agent needs eyes and hands, and almost none ship with either. That means structured telemetry an agent can actually reason over raw logs, and an action layer with approval gates, audit trails, and rollback built in rather than direct write access to production systems. Get either piece wrong, and you either have an agent that’s blind or one that’s dangerous.

That cross-system layer benefits from the very churn destabilizing everyone above it. The more customers want the freedom to swap AI tools quarter over quarter, the more they need a stable foundation underneath that doesn’t care which agent is asking.

There’s a catch, and vendors building that foundation need to hear it clearly. You cannot sell openness and quietly build your own version of lock-in. The rules buyers are now enforcing everywhere else apply here too: open integration, easy exit, price it on outcomes, not seats. Vendors who understand that distinction will define the next decade of enterprise software. The ones who don’t will become the next renewal casualty.

While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.

The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.

Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.

Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.

“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”

Rolling restarts, persistent issues throughout the day

Salesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.

Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”

However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those ‌instances.

Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.

A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.

“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”

Creating a ‘temporal’ data problem

For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.

For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.

This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”

The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.

Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?

Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.

What to look for in post-incident reports

A credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.

The company should be able to answer these questions, he said:

• What was the actual initiating failure and why did the failure propagate into the login path?
• Why could the affected dependency consume sufficient capacity to affect core services?
• Why didn’t isolation or failover prevent the impact?
• Why did initial remediation attempts fail and why did the subsequent rollout require additional intervention?
• What safeguards are being added to prevent recurrence?
• How will Salesforce demonstrate that the corrective action actually works under failure conditions?

Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”

It’s not just about ‘legacy’ pieces in the stack

One architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.

“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.

That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?

Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.

“For enterprise architects, that is the real takeaway,” he said.

Maybe driven by agentic AI, exacerbated by layoffs

At this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”

He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”

Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”

AWS is betting that AI agents need a different interface as they move beyond answering prompts and start working autonomously in the background.

The company has open-sourced Pizza Bot, a self-hosted application that gives users an inbox for managing work delegated to AI agents, with separate threads for ongoing tasks and a queue for work that is completed or needs human input, rather than keeping the management of agents restricted inside a conventional chat window.

The rationale, according to AWS, is that background agents do not always need a user’s attention while they work and an inbox model will let users hand off longer-running tasks, return to them later, and see which jobs are complete or require intervention.

Under the hood

That approach is reflected in how the inbox organizes work with the help of an “All” tab that contains the history of each task or conversation, including the agent’s messages and work performed, the “Unread” tab that flags completed work that users have yet to review, and an “Action” tab that surfaces tasks paused while waiting for user input or approval.

The inbox interface also has a panel named Activity that shows users how an agent handled a particular task along with the transcript, AWS wrote in a blog post introducing Pizza Bot.

AWS’ inbox-oriented rationale also extends to Pizza Bot’s architecture.

It uses LangChain’s Deep Agents as the harness and LangGraph as the stateful runtime, with a combination of the two allowing an agent to checkpoint its progress as it works, preserving its messages, tool activity and current state so a task can be paused and resumed rather than being tied to a live chat session, the hyperscaler wrote.

Pizza Bot’s server sits on top of that stack, connecting the agent runtime with the user interface, skills, MCP servers and the model provider, with developers able to choose from Anthropic, OpenAI, Google Gemini and Amazon Bedrock, as well as local models through Ollama, it added.

As for its out-of-the-box capabilities, the application comes with skills for working with files, browsing the web and delegating tasks to specialist agents. Developers can also add existing Agent Skills and MCP servers to give the agents access to other tools and services, the hyperscaler wrote.

Enterprise integration could remain a hurdle

However, analysts were not too convinced that Pizza Bot’s out-of-the-box skills and support for existing tools will make its implementation easier for enterprises.

While the out-of-the-box capabilities and added support for existing skills saves enterprise teams the time to build the application, it leaves out the integration work required to make it work, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

“Integration is where most of the money in an enterprise agent deployment goes. A sales or finance team gets value from an agent when it can read and update CRM, email and ERP, and each of those systems needs a connector someone has to build, secure and maintain,” Chopra pointed out.

Pizza Bot’s integration could be further complicated by the application’s lack of support or any SLA, according to Manoj Chandra Jha, principal analyst at Nord-IQ Research. That means the integration and operational burden ultimately falls on enterprises, who would be responsible for running, securing and maintaining the open source software themselves, Jha said.

Rise in enterprise productivity likely

But for enterprises willing to take on that integration work, the inbox-oriented approach could improve productivity.

“It’s a meaningful shift because it changes the economics of delegating work to agents. A chat interface requires a person’s attention throughout the task, while an inbox brings them in only when their judgment is needed, much like how executives delegate work to their teams,” Chopra said.

“Coding agents have already demonstrated this model, where an engineer assigns an issue and reviews the resulting pull request. Pizza Bot extends that approach to tasks such as meeting preparation and follow-ups,” Chopra added.

Further, the analyst pointed out that the inbox-oriented approach could give enterprise teams a clearer window into how scheduled tasks perform.

“For scheduled tasks, having the results delivered as threads gives users a way to track what happened in the background and spot failures that might otherwise go unnoticed,” Chopra said.

Out of sight, out of mind

There are risks with this approach, however: “The inbox model can make bad work less visible. When somebody is watching an agent in a chat window, they can see it going off the rails,” said Phil Fersht, CEO of HFS Research.

In contrast, when hundreds of tasks are running quietly in the background, users may not see an agent making mistakes until the task is complete or an exception requires their attention, potentially making problems harder to catch early, Fersht said.

That reduced visibility can also create approval fatigue, according to Chopra.

“An agent sending back dozens of threads with multiple approval requests can condition users to approve them without reading them closely,” Chopra said.

There is also a risk in the delay between an agent preparing an action and a user approving it: “Information that was current when the agent paused may no longer be valid hours later, potentially resulting in an outdated CRM update or a meeting invite for a slot that is no longer available,” he said. “An assumption that might be caught in a live chat can go unchallenged as the agent continues building on it and consuming model resources. Scheduled runs can also add costs without anyone watching them in real time.”

Those disadvantages can be countered by designing processes with fewer, better-timed approval points, and verifying that the underlying data is still current before allowing an action to execute, he said.

Adoption likely to start with technical teams

Such tradeoffs are likely to shape where Pizza Bot gains traction.

“Adoption will likely be bottom-up, with individual technologists and small platform teams drawn to Pizza Bot’s control and standards-based design,” Jha said. “Risk-averse industries, especially ones in the regulated sectors, and business users with limited technical expertise, however, are likely to approach the application more cautiously,” he added.

That could leave Pizza Bot occupying a more targeted role in the enterprise, as a way for technical teams to experiment with asynchronous agents and new ways of delegating work, rather than an immediate replacement for the governed interfaces and managed services enterprises typically use for business-critical processes, he said.

This article first appeared on InfoWorld.

Broadcom isn’t playing nicely in the European market, according to a new report by the independent monitoring body European Cloud Competition Observatory (ECCO), which rates Broadcom’s status as “critical” in its most recent analysis of cloud competition in Europe.

The company’s conduct has “deteriorated markedly” since October 2025 due to what ECCO calls “continued and escalating” unfair licensing practices, delay tactics and “procedural obstruction” in the European Commission’s antitrust investigation, and “wholly misleading” sovereignty claims in the European market.

“These developments represent a serious and continuing attempt by Broadcom to restructure the market in its favor,” the group claimed. “This is a threat not only to the viability of European cloud infrastructure providers, but to the integrity of EU competition enforcement.”

SAP, meanwhile, is at “amber status,” meaning there are escalating concerns in the European market due to newly-introduced API restrictions and changes to agentic AI licensing that could stifle competition.

Microsoft, for its part, remains in good standing, and has made progress relative to previously-raised concerns.

Grievances against Broadcom

ECCO is made up of members of the Cloud Infrastructure Services Providers of Europe (CISPE), as well as European customer organizations. The group rates providers in its regular reports with by color: Red means no meaningful progress has been made, amber represents stalled progress or barriers to resolution, and green signals significant and sufficient progress made regarding specific issues.

In this latest report, Broadcom sits firmly in the red category. ECCO cited several concerns.

For starters, the group is raising flags around “market-harming actions” taken by Broadcom, notably the abrupt shutdown of its partner program, and new “severe” restrictions to its Bring Your Own License (BYOL) terms.

In January, Broadcom unilaterally terminated its main reseller program for VMware cloud service provider (CSP) partners. The program had allowed European cloud companies to provide virtualization services that are critical to large cloud deployments. Now, they can no longer offer VMware services “under any terms.”

“Essentially, vast swathes of Europe’s cloud ecosystem were, at a stroke, denied access to a crucial product for which there are no immediate alternatives,” ECCO wrote. The group argued that Broadcom is “systematically exploiting” its dominant position, and taking advantage of the fact that its VMware virtualization software is complex to replace.

Switching can be time-consuming and disruptive to business operations, ECCO said: “Re-engineering, even where it is possible, is a multi-year and multimillion Euro project.”

The group also pointed to a new bring your own license (BYOL) scheme: Customers are now forced to choose from a small group of European companies to host their BYOL workloads. There are few Broadcom Certified Cloud Services remaining, essentially creating lock-in and probably price inflation due “mini-monopolies” in some regions and sectors.

Other licensing concerns center around cost: CISPE members have been reporting license price increases of 10x or more compared to VMware pricing before its 2023 acquisition by Broadcom.

The company has also eliminated overage-based pricing, which allowed CSPs to provision capacity and reconcile usage if in arrears. Now European cloud companies are required to pre-commit to core counts, essentially eliminating the flexibility required when delivering cloud services.

This imposes “severe commercial and operational constraints,” ECCO contended.

Dovetailing with this, CISPE said it has confirmed rumors of a potential kill switch or “degradation mechanism” in VMware’s licensing infrastructure. Broadcom requires compliance reporting every 180 days; failure to do so triggers automated degradation or blocking, thus rendering a customer’s virtualization environment non-functional.

The existence of this mechanism represents an “extraordinary and disproportionate” exercise of market power and raises significant questions about the resilience and security of European digital infrastructure, ECCO said.

Finally, the group pointed to Broadcom’s active obstruction of the European Commission’s antitrust investigation into its VMware acquisition. The company continues to issue legal challenges and requests to suspend proceedings, thus stalling the process, and has invoked its US legal privilege in what seems an attempt to protect potentially damning documents.

ECCO is urging the European Commission to resist attempts to suspend the antitrust investigation and to enforce disclosure obligations even-handedly. “These are not legitimate procedural steps, they are a calculated strategy to delay and dilute effective enforcement,” it said.

SAP is throttling, changing billing

ECCO isn’t entirely thrilled with SAP, either; it calls out “specific, substantial, and … potentially anticompetitive” practices, including traditional antitrust measures that direct customers to its own cloud offerings and impose restrictions on data access for agentic AI.

The group argued that SAP has been throttling data access as a means to control the AI layer. Customers are being offered differentiated, lower grade products unless they migrate to SAP’s own cloud infrastructure.

This follows an ongoing trend by the company: In July 2023, SAP announced that all future innovations would be delivered cloud-first. But facing backlash, the company backtracked, saying in early 2026 that its AI, Joule, and other cloud-first tools would be available to on-prem customers.

There was a caveat, though: New products and features would only be made available to customers committing to transition to RISE with SAP, the company’s subscription-based ERP migration platform.

SAP also announced software billing changes at its Sapphire 2026 conference. Historically, the company has charged consumption-based pricing (that is, the more software is used, the higher the cost), but it plans to shift to imposing capacity-based (per-server) pricing on its partners, with caps for certain scenarios.

This will immediately make it more expensive to offer SAP services on non-SAP clouds, will favor large companies that can spread costs across a wide customer base, and will potentially price out smaller players offering SAP alongside other cloud service offerings, ECCO argued.

These developments “raise serious concerns about foreclosure of third-party competition in the emerging enterprise AI market,” ECCO said.

On a positive note, ECCO credited Microsoft’s decision to “harmonize” the cost of extended security updates across customers, regardless of choice of cloud. This addressed a previous complaint by CISPE and demonstrates the company’s “continued willingness” to recognize and respond to concerns raised by relevant stakeholders. Redmond has also engaged in new collaborations under the European Cloud Accelerator, including the co-development of cloud-based onboarding for SMEs.

The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material.

Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost.

Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position.

Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it.

What prepared CIOs are doing differently

The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from.

Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot.

The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon.

The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny.

Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all.

Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it.

Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it.

Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle.

None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined.

A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.

The cloud computing conversation has changed significantly over the past few years. Earlier, enterprises selected cloud platforms mainly for scalability, global reach, agility and cost flexibility. Today, those priorities remain important, but they are no longer sufficient. Governments, regulators, boards and customers are asking a deeper question: where does critical data reside, who can access it, who operates the infrastructure and which legal jurisdiction ultimately governs it? This is the context in which sovereign cloud has moved from a specialist requirement for governments into a mainstream enterprise architecture consideration.

Sovereign cloud refers to cloud environments designed to preserve data residency, legal control, operational independence and regulatory compliance within a defined jurisdiction. In practical terms, it is not merely a cloud region located inside a country. A mature sovereign cloud model includes a combination of local data storage, strict identity and access control, encryption key ownership, local personnel controls, auditability, contractual protections, operational segregation and, in some cases, disconnected or air-gapped deployment options. Its central purpose is to allow organizations to consume cloud and AI capabilities while reducing exposure to cross-border data transfer risk, extraterritorial access concerns and regulatory uncertainty.

Recent trends in sovereign cloud

The first major trend is the shift from data residency to full digital sovereignty. Data residency answers the question of where data is stored. Digital sovereignty goes further by addressing legal jurisdiction, administrative access, operational control, encryption key management and dependency on foreign technology providers. This distinction has become increasingly important as enterprises recognize that locating data in a domestic region does not automatically remove legal or operational exposure.

The second trend is the rapid convergence of sovereign cloud and artificial intelligence. Generative AI and large-scale analytics rely on sensitive enterprise data, customer information, intellectual property, telemetry and domain-specific knowledge. As a result, enterprises are increasingly asking whether AI training, inference, prompts, embeddings, logs and model outputs should remain within national or regional boundaries. Sovereign AI infrastructure is therefore emerging as a natural extension of sovereign cloud, especially in regulated industries and public-sector environments.

Magesh Kasthuri

In the figure above, you can see each layer builds on the ones before it, moving from a storage question to a question of legal, operational and technological independence, showing sovereignty is cumulative.

The third trend is the rise of hybrid sovereign architectures. Few enterprises can move every workload into a fully isolated sovereign environment without affecting agility or cost. Instead, many organizations are adopting a layered model. Highly regulated workloads such as citizen services, payment systems, healthcare records, defense data and critical infrastructure systems are placed in sovereign or private cloud environments, while less sensitive workloads continue to use mainstream public cloud regions. This approach allows enterprises to balance sovereignty, innovation, performance and economics.

Magesh Kasthuri

In the figure above, hybrid sovereign architecture model is built as a layered approach that balances sovereignty, innovation, performance and economics.

The fourth trend is the growing importance of local partnerships. Hyperscale providers are increasingly working with regional telecom operators, system integrators, government-backed entities and local infrastructure providers to meet country-specific sovereignty requirements. These collaborations help address demands for local operations, domestic ownership, regional support and compliance with national security policies. At the same time, local cloud providers are refreshing their platforms to offer modern automation, cloud-native services, security tooling and managed operations.

The fifth trend is the growing use of policy-as-code and sovereign-by-design controls. Enterprises want sovereignty to be enforced through architecture, not only through contractual language. This is creating demand for region-locked deployment policies, controlled replication, customer-managed keys, confidential computing, localized identity administration, immutable audit trails and automated evidence collection for regulators and auditors.

Industry adoption of sovereign cloud

Government and public sector organizations remain the most visible adopters of sovereign cloud. Their workloads often include citizen identity, taxation, welfare, defense, justice, digital public infrastructure, border management and national emergency systems. These systems carry high public trust obligations and governments increasingly prefer cloud platforms that provide clear control over data location, local administration, audit rights and national continuity.

Banking, financial services and insurance are also strong candidates for sovereign cloud adoption. Banks handle personal financial data, payment transactions, fraud signals, credit records, trading information and regulatory reporting data. Sovereign cloud helps financial institutions align with central bank expectations, operational resilience mandates, cybersecurity requirements and audit obligations. It also enables safer use of AI for fraud detection, customer intelligence, risk modeling and compliance monitoring.

Healthcare and life sciences organizations are adopting sovereign cloud to protect patient records, clinical trials, diagnostics, genomics data, medical imaging and public health information. The sensitivity of healthcare data makes jurisdictional clarity extremely important. Sovereign cloud can support secure collaboration, research analytics, hospital modernization, AI-assisted diagnostics and telemedicine platforms while maintaining tighter data governance.

Telecommunications providers use sovereign cloud for network functions, 5G core workloads, subscriber data, lawful interception systems, edge platforms and national communication infrastructure. Because telecom networks are often classified as critical infrastructure, sovereignty requirements can influence decisions on hosting, operations, resiliency and supply-chain assurance. Here is a summarized view of various industrial adoption across different use cases.

Manufacturing, energy, utilities and transportation sectors are beginning to view sovereign cloud as part of industrial resilience. Operational technology data, plant telemetry, grid analytics, digital twins, predictive maintenance models and supply-chain intelligence are increasingly valuable assets. For these industries, sovereignty is closely tied to business continuity, cyber resilience, industrial secrecy and national economic security.

Cost implications of sovereign cloud adoption

Sovereign cloud adoption may increase cost when compared with standard public cloud deployment, especially in the early stages. Additional costs can arise from localized infrastructure, dedicated regions, private cloud environments, local operations teams, specialized compliance controls, sovereign connectivity, encryption key management, audit tooling and managed security services. In some cases, organizations may also need to redesign applications to prevent unapproved cross-border replication or dependency on non-sovereign platform services.

However, the cost discussion should not be limited to infrastructure premiums. Enterprises must compare the added cost of sovereign controls with the potential cost of regulatory penalties, reputational damage, business interruption, loss of public trust, failed audits, contractual exclusion from regulated markets and inability to use sensitive data for AI safely. For a regulated enterprise, sovereignty can become an enabler of revenue protection and market access rather than a pure compliance expense.

FinOps discipline becomes essential in sovereign cloud programs. Organizations should classify workloads by sovereignty need, avoid over-engineering low-risk applications, monitor data egress, negotiate transparent pricing, standardize deployment patterns and use automation to reduce operational overhead. A pragmatic cost model normally separates workloads into tiers: highly sovereign, regulated but cloud-friendly and general enterprise workloads. This allows the organization to apply the highest controls where they matter most.

Benefits of sovereign cloud for enterprises

The most direct benefit of sovereign cloud is improved regulatory alignment. Enterprises operating across multiple jurisdictions can demonstrate stronger control over data storage, processing, access and movement. This is especially valuable when serving government clients, regulated sectors or customers with strict data protection expectations.

A second benefit is enhanced trust. Customers, regulators and partners are more likely to support digital initiatives when an enterprise can explain where sensitive information resides, who operates the environment and how access is governed. In sectors such as healthcare, banking, public services and critical infrastructure, trust is not a soft value; it is a commercial and operational requirement.

A third benefit is stronger resilience. Sovereign cloud can support local continuity planning, controlled dependency management, regional disaster recovery and clearer operational accountability. When designed properly, it reduces the risk that geopolitical disruption, foreign legal orders, supply-chain fragility or cross-border service restrictions will affect mission-critical systems.

A fourth benefit is responsible AI enablement. Many organizations hesitate to use AI on sensitive data because of uncertainty about retention, training, inference and cross-border processing. Sovereign cloud provides a more controlled foundation for AI adoption by combining data isolation, model governance, auditable operations and policy-driven controls.

Analyst perspective on future trends

Analyst research indicates that sovereign cloud is becoming a fast-growing part of the cloud market rather than a narrow compliance niche. Gartner forecasts worldwide sovereign cloud infrastructure-as-a-service spending to reach US$80 billion in 2026, reflecting 35.6% growth from 2025 and also notes that sovereign cloud spending could shift a meaningful share of workloads from global to local providers. Earlier Gartner research also projected strong long-term growth for sovereign cloud IaaS, driven by regulatory demand, operational independence and technological autonomy.

Forrester’s recent work on digital sovereignty highlights that organizations are no longer treating sovereignty as a simple data residency issue. Its sovereign cloud platform research emphasizes that different deployment models are required for different risk profiles, ranging from public cloud with sovereign controls to private, partner-operated and disconnected environments. This reinforces an important market reality: sovereignty is becoming a design principle across the IT stack, not a single product category.

IDC’s digital sovereignty research points to regulatory compliance, national and regional legislation, protection against extraterritorial data requests, AI adoption and strategic partnerships as key forces shaping the market. IDC’s infrastructure predictions also caution that sovereignty programs can add cost and complexity, requiring stronger data classification, governance, security controls, partner ecosystems and skills development.

Everest Group’s research frames sovereign cloud as closely connected to sovereign AI, enterprise autonomy, data governance and operational control. Its European sovereign cloud analysis describes a market being shaped by geopolitical tension, stronger privacy mandates, concerns about foreign surveillance laws and the need for clearer sovereignty frameworks across data, operational and technical dimensions. Everest Group’s broader private cloud research also indicates that AI, automation, workload repatriation, hybrid-first strategies and sovereignty mandates are increasing demand for controlled cloud environments.

Conclusion

Sovereign cloud is best understood as a response to a broader shift in enterprise technology: the movement from borderless cloud consumption to governed digital autonomy. It does not reject public cloud innovation; rather, it asks cloud platforms to operate within clearer legal, operational and architectural boundaries. For enterprises, the strategic question is not whether every workload must become sovereign. The better question is which data, systems, AI workloads and business processes require sovereign protection and how that protection can be delivered without slowing innovation.

The future of sovereign cloud will likely be hybrid, policy-driven, AI-aware and industry-specific. Organizations that treat sovereignty as an architectural capability will be better positioned than those that approach it as a last-minute compliance checkbox. The winners will be enterprises that build a balanced operating model: global where possible, local where necessary and sovereign where trust, regulation and resilience demand it.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

When it comes to AI in the physical security industry, much of the conversation has rightfully focused on analytics. With devices now doing more than standard recording, many are configured to detect an object, recognize a particular behavior, or identify an event that requires immediate attention.

Those applications improve daily and will continue to remain important. However, the role of AI is expanding. Looking ahead, AI agents could assist with the administration and optimization of the physical security systems themselves, including identifying system issues, recommending configuration changes, supporting lifecycle management, or automating routine tasks.

Of course, it’s going to require more than increasingly capable AI models in order to unlock those possibilities. Organizations will also need trusted data, secure connectivity, strong governance, and an infrastructure that can support new applications as they emerge.

AI expands beyond analytics

AI has already changed what organizations can learn from their security data. For example, video analytics can help teams detect events and patterns that would be difficult to identify through manual monitoring and analysis.

The next phase will apply intelligence to a broader set of operational challenges. IT and security teams must support complex environments, often without changes in resources. AI can help by automating repetitive admin tasks and assisting teams with troubleshooting, system optimization, and other aspects of day-to-day management.

This represents a shift from using AI primarily to understand what is happening within a scene to exploring how AI can help organizations manage the technology itself. As these capabilities continue to develop, AI will become a tool for helping smaller teams oversee large and complex physical security environments.

Trusted data becomes the foundation

Of course, an AI system can only make useful recommendations or take appropriate actions if it can rely on the information that’s intended to support those decisions.

That makes data quality an essential part of preparing for more advanced AI. Physical security environments can include thousands of connected cameras, intercoms, access control devices, sensors, and other technologies. Each device generates data about events, configurations, performance, and system health. Accurate metadata and standardized information flows can make it easier for applications to interpret and utilize that data.

Connectivity and lifecycle awareness are equally important. Understanding whether a device is online, properly configured, and operating as expected provides context for making correct decisions.

Investing in connected, well-managed infrastructure does more than improve operations; it helps create a stronger data foundation for future AI initiatives.

“We may not know exactly how agentic AI will be applied to physical security five years from now, but we can start preparing today,” said Patrik Pettersson, Strategic Advisor, Incubation, Axis Communications. “The organizations that establish secure connectivity, trusted data, and well-managed devices will be in a much better position to take advantage of any new capabilities as they emerge.”

Why secure cloud foundations matter

As AI’s role expands from generating insights to potentially taking actions, trust and governance will become even more important.

Secure cloud platforms can provide an essential layer between devices, applications, and services. Platforms such as Axis Cloud Connect, for example, enable secure communication and connectivity across physical security environments, while also providing a foundation for services to interact with connected devices.

This foundation will become even more important as agentic AI evolves. Organizations will need visibility and control over who or what is allowed to access their systems, which services can interact with individual devices, and when those interactions can occur. An AI agent that recommends a configuration change presents one level of risk. Giving that agent permission to make the change itself introduces an entirely different risk and/or governance consideration.

Organizations will need confidence in the AI itself as well as the infrastructure controlling its access to critical systems. As intelligence becomes more capable, the mechanisms governing what it can see and do will become just as important.

Openness enables future innovation

There is another challenge: Nobody knows exactly what tomorrow’s AI ecosystem will look like.

Organizations may ultimately use different AI models, analytics providers, applications, and services for different purposes. An infrastructure built around open APIs and interoperability will provide greater flexibility to adopt those emerging capabilities.

This flexibility also reduces the risk of tying future innovation to active decisions. Rather than replacing entire systems to take advantage of a new AI capability, organizations can integrate new applications and services into an existing technology environment.

Open architectures also offer greater freedom to choose how and where organizations adopt AI while reducing the dependence on any single technology or provider.

Building for what comes next

The physical security industry’s AI conversation is moving beyond analytics and event detection. Increasingly, the opportunity will involve automation, orchestration, administration, and operational efficiency.

Exactly how those capabilities develop remains to be seen. But organizations need not know every future AI use case to begin preparation. By investing in secure connectivity, trusted data, strong governance, and open infrastructure, organizations can create an environment to support new emerging AI capabilities.

Learn more about Axis Communications.

It wasn’t too long ago that physical security devices were mostly treated like traditional appliances: Install, configure, and revisit when something broke. 

Fast forward to today, and that approach is no longer sufficient. Modern cameras, access control devices, intercoms, sensors, and other physical security technologies are connected, software-driven endpoints. Like other network infrastructure, they require extensive oversight to maintain performance, address vulnerabilities, and manage cybersecurity risks.

This evolution requires a shift in mindset and processes. Organizations must begin treating physical security as living infrastructure that requires ongoing attention throughout its lifecycle. For many, that means moving beyond the limited install-and-forget approach and bringing these devices closer to the standards applied to other critical IT infrastructure. As cameras and other physical security devices increasingly generate business intelligence, their role within the organization is expanding. This makes visibility and lifecycle management increasingly important.

The growing edge management challenge

The variety of intelligent devices deployed at the edge continues to grow. A single organization may rely on dozens of unique technologies distributed across hundreds of locations. Many of those devices will remain in service for years.

This creates an active management responsibility that extends well beyond installation. Firmware must be kept current. Cybersecurity risks must be monitored. Device performance and system health must be evaluated. Audits may even need to be conducted across an entire technological estate.

“Connecting a device to the network and properly hardening it isn’t the end of the cybersecurity responsibility,” said Wayne Dorris, Program Manager, Cybersecurity, Axis Communications. “Organizations need to understand what devices they have, keep the software current, update software for any vulnerabilities, and manage those devices throughout their lifecycle. That ongoing visibility is now an essential part of maintaining a secure physical security environment.”

For organizations with large or geographically dispersed environments, handling those responsibilities device by device or location by location quickly becomes untenable. There is a fundamental challenge in managing status and performance of a large number of devices throughout their lifecycles.

Moving beyond reactive maintenance

This growing complexity is changing expectations around maintenance. Simply waiting for a device to fail can create unnecessary disruption and consume valuable IT and security resources.

Instead, organizations need a more proactive approach to identify and address potential issues before they lead to outages. This shift also changes the relationship between organizations and their system integrators. Traditional break-fix support has evolved toward managed services that can include critical monitoring, updates, and oversight.

In this managed service model, some of the most valuable maintenance work might often go unnoticed. That’s because an issue can be identified, diagnosed, and resolved before it affects operations. The result is less disruption for the organization and a more predictable approach to maintaining physical security infrastructure.

Creating an operational layer with the cloud

Managing infrastructure proactively and at scale requires secure connectivity and centralized visibility. This is where cloud-enabled management plays an important role.

Rather than replacing the physical security system itself, the cloud provides an operational layer for efficiently managing large numbers of connected devices. Device management software can give organizations greater visibility into the device fleets while helping them remotely monitor device health, manage software, maintain cybersecurity, and address other lifecycle management needs.

For example, Axis offers device management software for on-premises, cloud-based, and hybrid environments, including AXIS Device Manager Edge and AXIS Device Manager Extend. Axis Cloud Connect can take this a step further by helping integrate device management capabilities and data into other platforms and applications. This provides greater flexibility for incorporating physical security infrastructure into existing management environments.

IT and physical device leaders should keep integration in mind when selecting a vendor. Not long ago, selecting a solution was about whether it addressed a specific security need. Now, organizations should also consider how readily a vendor’s technology can integrate with their existing IT and cybersecurity ecosystems. This allows physical security devices to become part of the broader processes and tools already used to manage critical infrastructure.

For distributed organizations in particular, this centralized approach provides a more practical way to oversee devices across multiple sites, understand their cybersecurity status, and proactively configure and update them as needed. It can also enable teams to take action remotely or automate certain actions without requiring individual endpoint management.

In a word, cloud connectivity makes ongoing management more scalable as physical security environments become larger, more connected, and more complex.

Doing more with less

This scalability is especially important as IT and security teams face pressure to support more technology with limited resources. Centralized administration allows smaller teams to oversee larger environments, while remote diagnostics and triage can help technicians investigate and potentially resolve issues without travel. These capabilities can even support mobile and distributed teams, giving authorized users greater flexibility in how and where they manage their environments.

Looking ahead, agentic AI could further change this equation. IT teams are beginning to consider how AI can help offload routine work through autonomous triage and diagnostics,  creating a force multiplier for stretched organizations. The goal is indeed greater automation, but it is also to spend less time on repetitive maintenance and give teams more capacity to focus on their higher-value, strategic initiatives.

Treating physical security as living infrastructure

As physical security technology becomes more connected and software-driven, lifecycle management, cybersecurity, and operational visibility are becoming strategic requirements rather than occasional maintenance tasks. Organizations that embrace this proactive management model can reduce operational risk while easing pressure on the IT and security teams responsible for keeping systems running. 

Managing devices can no longer be an install-and-forget exercise. Physical security must now be treated as living infrastructure, continuously monitored and managed throughout its lifecycle.

Learn more about Axis Communications.