IBM Says AI Spending Delayed Mainframe Deals, but the Damage Is Temporary

IBM suffered a historic stock selloff after admitting that AI infrastructure spending helped derail its second quarter. Yet the techcrunch after-earnings story carries a sharp reversal: IBM insists customers are delaying mainframe purchases, not abandoning them.

CEO Arvind Krishna says large enterprises redirected capital toward servers, storage, and memory during the final weeks of June. Buyers wanted to secure supply before anticipated price increases. Mainframe and related software deals then missed IBM’s expected closing dates.

That explanation puts two interpretations in direct conflict. Investors saw evidence that AI budgets were cannibalizing IBM’s established businesses. IBM saw a temporary purchasing sequence inside fixed corporate budgets, followed by delayed deals that could still close.

The difference matters far beyond one quarter. Mainframes remain central to transaction processing at banks, airlines, payment networks, and government agencies. If AI spending merely postpones upgrades, IBM can recover. If AI permanently changes which infrastructure wins budget priority, the company faces a deeper problem.

IBM’s Warning Turned a Weak Quarter Into a Credibility Test

IBM did not simply miss expectations. It warned investors early, blamed a late change in customer spending, and acknowledged that its teams failed to respond.

On July 14, Krishna released preliminary second-quarter results more than a week before IBM’s scheduled earnings announcement. Revenue reached $17.2 billion, up 1 percent from the prior year. Infrastructure revenue fell 7 percent, while software grew 5 percent and consulting remained roughly flat.

Those results fell below Wall Street’s expectations. Analysts surveyed by FactSet had anticipated revenue of $17.86 billion and adjusted earnings of $3.01 per share. IBM reported adjusted earnings of $2.93 per share.

The market’s response was severe. IBM shares fell about 25 percent on July 14, marking the company’s steepest one-day decline in more than a century. The selloff also spread anxiety across software companies exposed to enterprise technology budgets.

Krishna’s unusually direct investor letter explained the immediate cause. IBM had expected infrastructure revenue to decline as the z17 mainframe entered a tougher year-over-year comparison. The actual decline was worse because large Z system and transaction-processing software deals did not close.

The timing made the warning more damaging. IBM had described the z17 launch as the strongest start to a mainframe program in its history. Investors therefore had reason to expect the product cycle to support revenue, even as early launch comparisons became harder.

Instead, IBM conceded that customer behavior changed quickly near the quarter’s end. Enterprises redirected capital expenditure, meaning money used for long-lived assets, toward servers, storage, and memory. Supply constraints and expected price increases made those purchases more urgent.

Cybersecurity concerns also distracted customers, according to IBM. However, Krishna did not present external conditions as a complete defense. He wrote that IBM “faltered,” failed to adapt quickly enough, and allowed numerous large deals to slip beyond expected timelines.

That admission changed the issue from a routine product-cycle decline into an execution question. Supply pressure might explain why customers reordered purchases. It does not fully explain why IBM failed to anticipate the magnitude or protect enough deals to meet expectations.

The final quarterly results confirmed revenue of $17.162 billion. Infrastructure generated $3.835 billion, down 7.4 percent year over year. Its segment profit margin also fell from 23.3 percent to 21.8 percent.

Software remained the largest segment, producing $7.761 billion in revenue and 5.1 percent growth. Consulting contributed $5.327 billion, up only 0.2 percent. Those figures show why the mainframe shortfall mattered despite IBM’s broader portfolio.

Mainframe hardware supports a larger economic stack. Customers also buy operating software, transaction-processing tools, support, and consulting around those systems. A delayed machine can therefore hold back several connected revenue streams.

The techcrunch after-shock was not a claim that mainframes suddenly stopped working. It was a warning that IBM’s most dependable product cycle had collided with a more urgent category of infrastructure spending.

Why AI Infrastructure Jumped Ahead of IBM Mainframes

AI did not replace the mainframe during the quarter. It changed which hardware purchases customers considered impossible to postpone.

Enterprise technology budgets are not infinitely flexible. Large organizations plan annual capital spending, but they can reorder purchases when availability and prices shift. That is what IBM says happened late in June.

Customers prioritized general-purpose servers, storage systems, and memory needed for AI projects. Memory was especially important because modern AI systems consume large quantities of high-bandwidth and conventional memory across training, inference, and data-processing workloads.

Inference is the process of running a trained AI model to produce an answer or prediction. As companies move AI applications from experiments into production, inference creates sustained demand for servers, accelerators, networking, storage, and memory.

Mainframe upgrades operate on a different schedule. Enterprises usually plan them carefully because they support sensitive, high-volume workloads. A bank cannot casually move payment processing from one architecture to another because a new AI server became available.

That stability also makes a mainframe deal easier to defer. A customer can continue using existing capacity for another quarter while securing scarce AI hardware today. The workload remains, but the purchase order moves.

IBM’s own results support part of this explanation. Distributed infrastructure, including Power systems and storage, grew 37 percent during the quarter. IBM said that business exited June with an order backlog of approximately $500 million.

The contrast inside IBM is revealing. Customers were still buying infrastructure, but they favored products aligned with immediate capacity constraints. Demand did not disappear from the market. It shifted among categories.

This is the mechanism behind IBM’s temporary-disruption argument. AI infrastructure receives priority because delayed access can slow a new project or expose the buyer to higher component costs. A mainframe refresh can sometimes wait without disrupting current operations.

The argument becomes less comforting when viewed over several budget cycles. If AI hardware repeatedly consumes the first share of annual capital, IBM’s supposedly temporary delays can recur. Repeated postponement eventually behaves like weaker demand, even when customers retain every existing mainframe workload.

IBM must therefore prove more than continued mainframe usage. It must show that usage converts into timely capacity growth and software revenue. Installed systems can remain essential while new-system sales still disappoint.

This distinction helps explain the intense investor reaction. Mainframes often produce cyclical revenue, with strong growth after a new generation launches and declines as that cycle matures. Investors expect those patterns. They react more strongly when a flagship launch underperforms because customers have found a more urgent destination for capital.

The z17 was introduced as a mainframe designed for the AI era. It includes capabilities for running AI models alongside transaction workloads, allowing organizations to evaluate data without moving every record into another environment.

That design should place IBM on the winning side of AI spending. Yet the second quarter showed a budgetary divide between infrastructure purchased specifically for AI expansion and infrastructure marketed as capable of adding AI to established workloads.

The two categories solve different problems. GPU-heavy systems target model training and large-scale inference. Mainframes target secure transaction processing, availability, and centralized control, with AI integrated into those existing operations.

IBM’s challenge is to make the combined use case urgent. If customers view mainframe AI as useful but nonessential, it will keep losing scheduling contests against scarce servers and memory.

TechCrunch After the Crash: IBM Says the Mainframe Is Delayed, Not Dying

IBM’s defense rests on customer capacity data and delayed deals, not on a claim that the quarter was secretly strong.

During the July 22 earnings call, Krishna rejected the idea that customers were moving away from mainframes. He said IBM saw no evidence of clients abandoning the platform. The company instead characterized the shortfall as a timing problem concentrated in large capital deals.

IBM reported that z17 performance remained near 130 percent of the comparable z16 program. “Program-to-program” compares sales or installed capacity at the same point in successive product cycles.

The company also said clients representing 85 percent of installed MIPS had maintained or expanded capacity. MIPS, or millions of instructions per second, is a traditional measurement used to describe mainframe processing capacity.

Those numbers support the argument that core workloads remain in place. They also fit the historical durability of mainframes. Organizations continue using them because replacing deeply integrated transaction systems carries operational, security, and compliance risks.

A large bank, for example, might run account updates, card authorizations, fraud checks, and settlement processes through mainframe applications. Moving those systems requires more than rewriting old COBOL code. The organization must preserve data integrity, uptime, audit controls, and links to hundreds of downstream services.

AI coding tools can reduce some modernization work. They can document old applications, explain unfamiliar code, and help translate selected components. They do not erase the institutional risk of replacing systems that handle critical transactions every second.

IBM’s position therefore has a strong technical foundation. Mainframes are difficult to displace because they sit inside operating processes, not merely inside data centers. The cost of failure can exceed any expected savings from migration.

However, technical persistence does not guarantee a smooth hardware cycle. Customers can keep workloads on IBM systems while extending equipment life, using spare capacity, negotiating harder, or moving incremental applications elsewhere.

That gap between installed usage and new spending is the central tension. IBM’s figures show that the platform remains active. They do not yet establish that every delayed purchase will return on the original scale.

Krishna offered a near-term data point during the earnings discussion. He said roughly one-third of the large deals that failed to close in the second quarter had already closed during the third quarter.

That is meaningful evidence for a timing problem. It is not a complete recovery. Two-thirds had not yet closed when he spoke, and IBM did not promise that all would arrive without changes in size, timing, or terms.

The techcrunch after-earnings framing captures this distinction. AI has not killed demand for the work mainframes perform. It has exposed how even essential systems must compete for approval within limited enterprise budgets.

IBM also lowered its full-year constant-currency revenue growth outlook to a range of 4 percent to 5 percent. It had previously expected growth above 5 percent. A forecast reduction is difficult to reconcile with the idea that every missed deal simply moved a few weeks.

Management can believe the underlying franchise remains healthy while acknowledging that the year’s revenue opportunity has weakened. Both statements can be true. The platform may endure, but IBM still has to execute within the calendar investors use.

The Real Contest Is Budget Priority, Not Mainframes Versus AI

IBM’s opponent is not an AI model or another mainframe vendor. It is the urgency attached to every competing AI infrastructure purchase.

Framing the story as AI versus mainframes creates a false technical choice. Major enterprises need both transactional systems and AI capacity. The immediate conflict occurs when finance and technology leaders decide which purchase receives funding first.

AI projects now attract attention from boards, chief executives, security teams, and business-unit leaders. Many organizations fear falling behind competitors or losing access to constrained components. That pressure increases the perceived cost of waiting.

Mainframe upgrades carry a different justification. They often protect resilience, capacity, and efficiency for systems already generating business value. Their benefits can appear incremental beside a new AI initiative promising automation or a fresh product line.

This asymmetry affects IBM even if its technology performs as advertised. A proven platform can lose budget priority to a speculative project when leadership treats the latter as strategically urgent.

Competing infrastructure suppliers benefit from that urgency. Nvidia-centered systems capture spending for accelerated computing. Hyperscale cloud providers offer access to AI models and infrastructure without requiring every customer to own the underlying hardware.

Server, storage, networking, and memory suppliers also benefit when enterprises build private AI environments. IBM participates in parts of this market, but its mainframe economics remain exposed when buyers separate AI capacity from transaction infrastructure.

IBM has tried to connect these worlds. The z17 supports embedded AI processing, while watsonx provides tools for building, governing, and deploying AI. Red Hat’s hybrid-cloud software helps organizations run workloads across private and public environments.

The strategic idea is coherent: enterprises should manage AI alongside the systems and data they already trust. Yet buyers do not always purchase technology as an integrated architecture. Budget owners can fund an urgent AI cluster now and revisit mainframe capacity later.

Consulting should help IBM bridge that divide. Its advisers can connect AI plans with existing applications, governance requirements, and operational data. However, consulting revenue grew only 0.2 percent in the quarter, limiting evidence of a broad implementation surge.

Software showed more momentum. Red Hat revenue grew 11 percent, while recently acquired HashiCorp and Confluent assets performed strongly, according to IBM. These businesses align with hybrid infrastructure, application deployment, and real-time data movement.

That performance gives IBM several ways to benefit from enterprise AI spending. It also complicates the story. The company can gain through Red Hat or data software while suffering delayed mainframe and transaction-processing sales.

Investors must evaluate the mix, not just total AI exposure. Revenue moving from a high-margin established stack into different products can alter profitability, sales timing, and customer relationships.

The spending conflict also reaches technology leaders managing existing systems. They must decide whether to modernize near the mainframe, move selected workloads, or build AI services that access established data through controlled interfaces.

That decision requires a clear record of architecture choices, vendor claims, security constraints, and operational dependencies. A searchable technical knowledge base can help teams compare those materials without separating decisions from their source documents.

Still, documentation cannot resolve the investment tradeoff. IBM must demonstrate that upgrading its platform advances AI objectives now, rather than merely preserving infrastructure customers already consider indispensable.

What IBM’s Explanation Still Does Not Prove

The temporary-delay narrative is plausible, but one quarter of follow-through cannot establish that AI spending left IBM’s long-term economics unchanged.

The first uncertainty concerns the remaining delayed deals. Closing roughly one-third during the third quarter supports IBM’s account. It also leaves a substantial portion unresolved.

Large enterprise purchases can change after slipping. Customers may reduce capacity, split orders, demand different terms, or move related software decisions into another budget year. A delayed deal is not identical to contracted backlog.

The second uncertainty concerns recurring component pressure. IBM linked June’s disruption to supply-constrained infrastructure and anticipated price increases. If memory and server availability remain difficult, customers may keep prioritizing those purchases.

That would turn a temporary sequence into a repeated pattern. Mainframes would continue running, but each new cycle could begin behind AI infrastructure in the capital queue.

The third uncertainty involves IBM’s execution. Krishna explicitly said the company failed to adapt quickly enough. That admission prevents management from attributing the miss entirely to external conditions.

Sales teams should understand customer approval cycles and competing budget demands. Forecasting systems should identify large deals exposed to quarter-end shifts. Product teams should make the z17’s AI value concrete enough to protect purchase urgency.

IBM says the z17 remains ahead of the comparable z16 cycle. That metric deserves careful interpretation because product programs can vary in launch timing, capacity mix, customer concentration, and revenue recognition.

The installed MIPS figure also measures platform activity more directly than new revenue. Customers maintaining capacity show commitment to workloads. They do not necessarily show enthusiasm for accelerating hardware purchases.

Independent reporting reinforces both sides. The preliminary-results coverage documented the gap against analyst expectations and the scale of the initial stock decline. Subsequent results showed that IBM still produced growth across software and several distributed infrastructure products.

The market arguably punished more than a single hardware miss. IBM’s warning raised questions about whether AI capital expenditure crowds out established enterprise software and infrastructure. Similar concerns can affect any vendor whose products compete with AI projects for fixed budgets.

However, IBM’s case should not become a universal rule. Its results reflect its product mix, sales execution, mainframe cycle, and customer base. Another software company might face different renewal structures or less exposure to capital purchases.

There is also a risk in treating the stock reaction as a technical verdict. Markets reprice expectations, not architectures. A steep decline indicates that earnings and guidance differed sharply from investor assumptions. It does not show that the mainframe has lost its operational role.

The more defensible conclusion is narrower. AI spending disrupted IBM’s expected deal sequence, and IBM failed to absorb that disruption. The company has presented early evidence of delayed demand returning, but the recovery remains incomplete.

That conclusion respects the difference between a credible explanation and a verified turnaround. IBM does not need to prove that AI and mainframes can coexist. They already do. It needs to prove that coexistence produces the revenue timing and growth investors expected.

Three Signals Will Decide Whether IBM’s Reversal Holds

The next quarter must convert IBM’s explanation into measurable results across delayed deals, mainframe capacity, and the wider enterprise portfolio.

The first signal is the closure rate for large deals that slipped from the second quarter. IBM said about one-third had already closed. The next update should show whether most of the remainder followed, and whether they retained their expected scope.

A high closure rate would strengthen the timing argument. Continued slippage would suggest that customers are reconsidering more than purchase order dates.

The second signal is z17 performance against the z16 cycle. IBM says z17 remains near 130 percent program-to-program. Investors should watch whether that advantage persists after the volatile quarter.

Stable or expanding installed capacity would support IBM’s claim that customers remain committed. Slower capacity additions would weaken the connection between essential workloads and new-system revenue.

The third signal is IBM’s revenue mix. Mainframe recovery would be more convincing if transaction-processing software improves alongside infrastructure. Continued strength in Red Hat, storage, and Power would show IBM capturing AI-related spending elsewhere.

That mix matters because IBM lowered its annual revenue outlook. A few recovered deals might repair quarterly timing without restoring the earlier growth expectation. Sustainable improvement requires contributions across software, infrastructure, and consulting.

The broader question is whether IBM can make the mainframe part of the urgent AI budget instead of the purchase that waits behind it. That requires specific customer outcomes, not another general claim that the z17 was built for AI.

Enterprises should watch how IBM customers deploy AI near regulated transaction data. Useful examples include real-time fraud screening, risk analysis, operational forecasting, and automated support for legacy applications.

Security will also remain central. Organizations need controlled access to sensitive records, reliable audit trails, and clear governance over model outputs. Mainframes possess advantages in those environments, but IBM must translate them into projects with approved budgets.

The techcrunch after-quarter narrative will ultimately be judged by orders, capacity, software growth, and guidance. It will not be settled by the age of COBOL or another prediction that legacy systems are about to disappear.

IBM has survived several generations of technology that were expected to replace the mainframe. Survival is no longer the demanding test. The demanding test is whether IBM can convert an enduring installed base into growth while AI infrastructure absorbs an expanding share of customer attention.

For enterprise buyers, the practical response is to track where each delayed investment creates risk. Which AI purchases are genuinely supply-sensitive? Which mainframe upgrades protect capacity or compliance? Which projects depend on shared data and therefore belong in one architecture decision?

Keep those answers tied to meeting records, vendor documents, and operating evidence. A personal knowledge system can preserve the reasoning as assumptions change.

IBM says the mainframe is delayed, not dying. The next earnings cycle must show that delayed demand returns before another wave of AI spending sends it to the back of the line.