Google Cloud AI Survey Finds Modernization Stalled by Existing Software

Google Cloud published findings on November 9 showing that 49% of surveyed decision-makers linked on-premises software to delayed or curtailed technology initiatives. Those initiatives included AI, although the finding does not isolate AI projects. The Google Cloud AI survey puts a concrete number behind a familiar enterprise conflict: maintaining existing operations competes with building new capabilities.

The research, conducted with Hypothesis Group, surveyed 1,250 enterprise IT and business decision-makers in the United States. Google uses the findings to argue for greater architectural choice and less dependence on established providers. Its central concern is understandable: AI agents, software that can pursue tasks through successive actions, inherit the limitations of systems they access.

Microsoft offers a useful comparison. Its research emphasizes organizational readiness alongside employee adoption, rather than treating infrastructure replacement as the central answer. The tension running through both accounts is between expanding AI access and making business processes ready for it. For technology leaders, that shifts the discussion toward integration, operating responsibility, and whether new spending actually releases scarce engineering capacity.

What the Google Cloud AI survey actually measured

The survey measures decision-makers’ reported constraints, rather than demonstrating that a particular modernization strategy removes them.

Google Cloud’s risk and compliance chief, Jeanette Manfra, introduced the findings in a legacy software survey announcement. The accompanying report is dated October 2026, while its methodology places fieldwork in August. Publication therefore provides a recent account of experiences collected earlier, rather than a live measurement of November deployments.

An important definition shapes the interpretation. The study classifies locally hosted or on-premises enterprise software as legacy, contrasting it with software hosted and managed in the cloud. That definition concerns deployment and management arrangements. Readers should avoid assuming that every system covered is obsolete, unsupported, or technically unsuitable for AI.

The distinction matters because location and condition answer different questions. A locally operated application can have clear interfaces and disciplined maintenance. A cloud application can still contain confusing records, inconsistent permissions, or tightly coupled business rules. Neither observation contradicts respondents’ experiences, but both limit the conclusions buyers should draw.

The reported 49% also groups several outcomes: delays, reduced scope, pauses, and cancellations. These represent different degrees of disruption. A temporary scheduling adjustment does not carry the same business consequences as abandoning a project. Similarly, the inclusion of other technology initiatives means the result cannot become an AI cancellation rate.

That qualification leaves a meaningful finding intact. Respondents associate their existing software arrangements with barriers to planned change. For enterprise buyers, this is evidence that the surrounding environment deserves attention alongside the AI product being evaluated.

However, a survey response cannot establish the complete chain of responsibility. A stalled initiative might involve application limitations, procurement restrictions, missing expertise, competing priorities, or an unclear business case. Several causes can coexist within the same project.

The Google Cloud AI survey is consequently most useful as a diagnosis of perceived organizational friction. It gives leaders a reason to investigate their own dependencies. It does not tell them which application to replace, which provider to choose, or whether migration should precede a specific deployment.

That difference separates a useful research signal from an overly broad purchasing conclusion. The next question is who must resolve the friction, and what work they would otherwise be doing.

Maintenance pressure lands on the teams expected to deliver AI

The immediate pressure falls on teams accountable for both operational continuity and new AI delivery.

An engineering organization cannot treat its existing workload as optional simply because executives introduce an AI deadline. Security fixes, access changes, incident response, and application support remain necessary. Assigning an additional objective does not automatically create the capacity required to meet it.

This produces a budgeting problem that headcount figures alone can hide. A team may appear adequately staffed while specialists remain occupied with systems that require their specific knowledge. The relevant constraint is often available expertise during the delivery window, rather than total employees.

Consider an illustrative internal service agent that helps employees resolve account problems. Producing a plausible answer is only part of the assignment. The surrounding process must identify the employee, establish permitted access, retrieve current information, and route exceptions to someone responsible.

If the agent can change an account, the organization also needs approval rules and a record of the action. An effective demonstration can avoid much of this operational work. A production service cannot depend on someone manually fixing every unusual case afterward.

These demands explain why developers and security teams face pressure from different directions. Business leaders want visible progress. Operations teams must preserve availability. Security reviewers need sufficient evidence to approve access. Without explicit priorities, integration work can become an unowned dependency between those groups.

Maintenance also affects sequencing. Replacing an application might eventually reduce support effort, yet require substantial work before that benefit appears. During the transition, teams may need to support existing processes while learning the replacement. A modernization proposal therefore needs an account of temporary workload.

This is where broad promises about freeing engineers deserve examination. The relevant question is which recurring tasks disappear, who currently performs them, and when those people become available. Moving responsibility to a provider can help, but retained integration and oversight work still needs an owner.

Procurement teams face a related challenge. They must distinguish the convenience of acquiring a product from the effort of operating it. A familiar contract can simplify purchasing without resolving data access. An unfamiliar provider can offer attractive capabilities while adding another set of operational responsibilities.

For knowledge workers, the consequences appear as uneven availability. An assistant might summarize documents successfully while remaining unable to use the records needed for a consequential decision. The visible AI interface then advances faster than the workflow behind it.

The pressure is therefore organizational as much as technical. Leadership must decide which dependencies deserve investment and which proposed projects should wait. Otherwise, each new pilot competes for the same people without changing the conditions that slowed its predecessors.

Adding an agent does not remove the work beneath it

Automation expands the importance of dependable business interfaces because actions require clearer boundaries than suggestions.

Google’s argument becomes more persuasive when applied to a specific workflow than when applied to software location alone. A system that produces advice can leave execution to a person. A system authorized to act must encounter rules that the organization has made explicit.

Take an illustrative purchasing request. An employee might ask an agent to prepare an order using an approved supplier. The language task is straightforward to describe. The business task includes checking authorization, selecting the correct account, applying purchasing policy, and handling unavailable items.

Each stage introduces a question that fluent text cannot settle independently. Which record is authoritative? Does the requester have permission? Is the proposed purchase within policy? What happens if the order succeeds but the confirmation fails?

These questions expose a distinction between generating an answer and completing a transaction. The organization needs to know what happened in its systems, including partial completion. A confident conversational response cannot substitute for that evidence.

Existing applications sometimes encode rules that employees understand through experience rather than documentation. An agent deployment can expose that hidden knowledge. What appears to be an integration problem may actually involve unresolved decisions about policy, exceptions, or responsibility.

Replacing the application will not necessarily resolve those decisions. It can create a better place to express them, but someone still must determine the intended behavior. This is why modernization proposals should identify the business boundary they improve, rather than relying on the age of the underlying software.

Google’s own customer service deployment account provides a concrete example. In April 2025, the company described Wendy’s FreshAI handling drive-through orders and expanding across 24 states. Those are company-reported deployment claims, rather than independent proof of general agent reliability.

The example nevertheless illustrates the value of a defined task. Ordering food has recognizable inputs, menu constraints, and a transaction that must reach restaurant operations. Its usefulness depends on connections to the actual service process, rather than conversation quality alone.

An internal enterprise workflow needs comparable clarity, even when its boundaries are less visible. A request to investigate a contract, prepare a renewal, or resolve an access issue requires an agreed destination. Otherwise, a team can declare success when the agent produces text while downstream employees still complete the substantive work.

This makes integration a question of accountability. Someone must own the transition from recommendation to approved action and from action to verified result. Without that ownership, automation can redistribute effort while leaving the business process largely unchanged.

The strongest modernization case identifies those transitions and demonstrates that they improve. Its evidence should show fewer unresolved handoffs, dependable completion, and manageable recovery when something goes wrong.

Google and Microsoft emphasize different routes to readiness

The vendors differ in emphasis, but both accounts make organizational preparation central to useful AI deployment.

Google’s position gives architectural freedom a prominent role. Microsoft’s organizational AI readiness research places more emphasis on management, work design, and evaluation. Its May 2026 report draws on a survey of 20,000 AI-using workers across 10 markets.

Microsoft says organizational conditions are strongly associated with the value respondents report receiving from AI. Its methodology explicitly distinguishes statistical association from causation. That caution matters when comparing the findings with Google’s account: neither survey establishes a universal recipe for successful deployment.

The comparison also reflects different commercial positions. Google has an incentive to encourage buyers to reconsider established enterprise relationships. Microsoft has an incentive to make existing workplace environments productive settings for AI. These incentives help explain emphasis without automatically invalidating either company’s findings.

For buyers, the choice involves practical tradeoffs. Extending an established environment can preserve familiar administration and reduce some transition work. Introducing an alternative can increase negotiating options or meet a particular workflow requirement. Either route can disappoint if the organization skips the integration assessment.

The Google Cloud AI survey should therefore prompt scrutiny of dependency rather than automatic rejection of an incumbent. Dependence becomes consequential when changing a component requires unacceptable disruption, loses essential information, or leaves the business unable to operate independently.

That concern applies to a new provider as readily as an existing one. An enterprise can replace a familiar constraint with a less familiar constraint. A different contract does not itself establish greater freedom.

Meaningful choice requires operational evidence. A buyer needs to understand whether records remain usable outside the product, whether permissions can be reconstructed, and whether completed work remains inspectable. Those questions are more revealing than the number of model names available in a menu.

There is also a difference between choosing an AI model and replacing a workflow platform. The model generates or interprets information. The platform can hold instructions, connections, records, and approval history. Changing the former may be relatively contained while changing the latter affects the whole process.

This makes the procurement discussion more demanding. Buyers should evaluate the full working arrangement, including retained obligations and exit conditions. A convenient demonstration offers limited insight into what happens when a critical connection breaks or a business unit changes its process.

Knowledge management provides a smaller parallel. A searchable knowledge base is useful when people can retrieve relevant material in context. Enterprise automation adds further requirements because retrieved information can influence actions with organizational consequences.

The strongest comparison between Google and Microsoft therefore concerns how each proposed environment supports actual work. Brand preference is a weak substitute for examining the same process, permissions, and acceptance criteria across competing approaches.

The survey leaves important causal and security questions open

Reported maintenance friction supports investigation, but it does not establish that cloud migration delivers better outcomes for every workload.

The accompanying enterprise readiness report describes a 20-minute online survey, supplemented by qualitative interviews. Its American decision-maker sample provides a defined perspective. Readers should retain that scope when discussing enterprises elsewhere or employees outside purchasing and technology leadership.

The report also says 78% of respondents believe technology maintenance diverts resources from AI, while 48% consider their stack ready for scaled deployment. These are assessments of capacity and readiness. They are not direct measurements of engineering hours recovered after a migration.

Respondents can accurately describe frustration without identifying the best remedy. A team struggling with support demands might benefit from replacement, better configuration, additional expertise, or a narrower AI scope. Choosing among those responses requires evidence from the affected environment.

Commercial sponsorship warrants attention for the same reason. Google sells services aligned with its proposed direction. The appropriate response is to examine definitions and compare alternatives, while preserving findings that remain useful under scrutiny.

The survey’s deployment-based definition is particularly consequential. Treating locally managed software as legacy makes the cloud comparison central from the outset. Buyers still need a separate assessment of maintainability, security, integration quality, and business suitability.

Security introduces another limit to a simple migration narrative. A managed service can change who handles infrastructure maintenance. It does not remove the need to decide which information an agent can access or which actions require review.

Gartner’s agent governance framework addresses that distinction. Analyst Shiva Varma argues that uniform controls can overrestrict simple agents while underrestricting more autonomous ones. The framework differentiates observation, advice, and action requiring approval.

That perspective complicates the assumption that increasing autonomy always represents progress. An agent restricted to preparing a recommendation can be appropriate for a consequential workflow. Requiring approval is a design decision whose value depends on the action and its potential effects.

A cautious enterprise buyer should consequently distinguish infrastructure improvement from authorization improvement. Better hosting can support availability and maintenance. Better authorization defines what the system is allowed to do. Both deserve attention, and neither should stand in for the other.

The Google Cloud AI survey does not resolve the balance between these investments. It identifies perceived constraints that leaders can investigate. The analytical mistake would be converting that signal into proof that one architecture, vendor, or autonomy level is inherently preferable.

There is a further measurement problem after deployment. Employees might spend less time initiating work but more time checking uncertain results. A productivity claim needs to account for that review effort, alongside support and recovery. Otherwise, apparent automation can conceal work transferred to another team.

Watch completed workflows, switching evidence, and recovery

The next useful evidence will connect modernization decisions to operating results that buyers can inspect.

During the coming months, the first signal to watch is customer reporting about completed workflows. Useful disclosures will distinguish a demonstration from recurring use and explain what counts as successful completion. They should also identify where human intervention remains necessary.

This evidence would strengthen Google’s argument if modernization removes identifiable constraints and produces repeatable operational improvements. It would weaken a broad migration claim if projects still require extensive manual repair despite replacing the underlying environment.

Completion alone is insufficient when the process produces unacceptable errors. Buyers need evidence about correctness and the effort required to resolve exceptions. A workflow that finishes quickly while creating downstream disputes has moved the problem rather than resolved it.

The second signal is demonstrated switching. Product announcements about connectors or model choice deserve closer examination when customers show that a working process survives a component change. Preserving permissions, evaluation criteria, and usable records would provide meaningful evidence of flexibility.

A switch that requires extensive reconstruction tells a different story. It suggests that nominal choice exists alongside substantial operational dependence. This distinction will matter as buyers compare established workplace platforms with alternative agent environments.

The third signal is recovery under controlled failure. Customer accounts and technical evaluations should explain what happens when access expires, a connected application becomes unavailable, or an action completes only partially. Recovery evidence reveals how the system behaves beyond the favorable demonstration.

Clear ownership would strengthen confidence. A team should be able to identify the last verified state, determine which actions occurred, and decide how work resumes. If those answers require informal investigation every time, the operating burden remains unresolved.

These signals also help separate infrastructure constraints from process constraints. A failed connection can indicate a technical dependency. An unresolved approval dispute points toward governance. Both can block delivery, but they call for different responses.

The Google Cloud AI survey gives enterprise leaders a reason to examine where engineering capacity goes. Its findings are most valuable when translated into questions about a specific service, its dependencies, and the people responsible for keeping it useful.

For readers planning an AI investment, follow the work beyond the assistant’s response. Ask which business outcome must occur, which records establish completion, and who handles exceptions. Compare proposals against that same outcome, including migration effort and continuing review. Keep the acceptance criteria consistent when evaluating an incumbent platform or an alternative. Insist that claims about reduced maintenance identify the tasks removed and the responsibilities retained. Then look for customer evidence that those changes persist during ordinary operations and controlled failures. Which dependency currently prevents your team from completing valuable work, and what evidence would show that the proposed investment actually removes it?