SAP’s migration pitch has changed. The old argument was about support deadlines. The new argument is about AI. Stay on ECC and you miss the AI revolution. Migrate to clean-core S/4HANA and unlock the future.
There’s some substance to that. SAP Joule — their AI assistant and agent platform — gates its most capable features behind clean-core S/4HANA Cloud. SAP Business Data Cloud (BDC), the unified data fabric announced at Sapphire 2025, requires the full SAP cloud stack. Together they form what SAP calls the “AI flywheel”: apps generate data, data fuels AI, AI enhances apps, the cycle compounds.
But there are gaps in the argument. This article asks the question SAP’s marketing doesn’t: which AI capabilities actually require migration, and which can you get without it? It’s part of our complete guide to SAP ECC end of support and what comes next, which covers the full decision landscape from the 2027 deadline through migration paths and alternatives.
Two things are worth putting on the table here. First, composable ERP — open API architectures that let you run agentic AI workflows on top of SAP ECC without a clean-core migration (covered in depth in the SAP alternatives SAP will not tell you about). Second, AI-assisted modernisation tools like Microsoft’s COBOL Agentic Migration Factory (CAMF), which show that AI can be used to accelerate migration rather than as a reward that only arrives after it.
By the end, you’ll be able to answer: what AI do I actually need, and does that require S/4HANA?
SAP’s position at Sapphire 2025 is pretty clear. Access advanced AI — specifically Joule’s autonomous agents and Business Data Cloud — and you need a clean-core S/4HANA cloud deployment plus the SAP BDC data architecture. Everything else leaves you on the wrong side of a capability gap.
The causal chain goes like this: ABAP customisations in ECC block clean-core compliance → clean core gates Joule’s advanced features → advanced Joule plus BDC form the AI flywheel. Forrester puts it bluntly — SAP’s most advanced AI capabilities are “unequivocally gated behind a clean core and cloud-native architecture.”
The partnership announcements at Sapphire 2025 — Palantir, Perplexity AI, NVIDIA — are ecosystem signals, not capability unlocks. They don’t change the clean-core requirement for ECC customers.
The question to carry through: are these prerequisites technically necessary, or are they also commercial gatekeeping?
SAP Joule is SAP’s AI assistant and agent platform — embedded across SAP’s cloud applications as a natural-language interface and autonomous agent layer. As of Q4 2025, it has over 350 AI features and more than 2,400 Joule skills.
“Joule requires clean core” is too vague to be useful. Joule has a tiered capability architecture, and the distinction matters.
Basic Joule — conversational ERP queries, contextual help, and guided transactions — is accessible in applications connected to SAP BTP, without requiring S/4HANA Cloud.
Advanced Joule — autonomous multi-step agent workflows, predictive business process intelligence, and BDC-integrated analytics — requires S/4HANA Cloud with clean-core compliance. This includes domain-specific autonomous agents across finance, HR, and supply chain, plus Joule Studio (GA in Q4 2025) and bidirectional integration with Microsoft 365 Copilot.
So the specific gate is Joule’s autonomous agent capabilities and its BDC integration — not Joule as a conversational assistant.
There’s a cost layer that rarely shows up in migration proposals: SAP Joule’s advanced features are priced on an AI Units consumption basis, on top of RISE with SAP subscription charges. Model that before you calculate your AI ROI.
One more thing. 75% of UKISUG members call AI strategic for the next three years. The same 75% believe it is “completely overhyped in terms of delivering business value.” Forrester corroborates that SAP AI adoption remains modest relative to the installed base. So there’s a bit of collective hedging going on.
SAP Business Data Cloud (BDC), announced at Sapphire 2025, is SAP’s unified data fabric: Databricks, SAP Datasphere, SAP Business Warehouse, and SAP Analytics Cloud — harmonising data across SAP and non-SAP systems through the SAP Knowledge Graph.
SAP’s AI flywheel argument depends on BDC. Forrester calls it “the nonnegotiable data foundation” — “SAP’s entire Business AI vision and its promised value is predicated upon it.”
What BDC actually demands from you: clean-core S/4HANA as the source system. ECC data structures are incompatible with BDC’s harmonisation layer. BDC is relatively new, and Forrester notes SAP has not fully clarified its approach to AI security and data sovereignty within it. BDC and Joule together also create deep dependency on the full SAP cloud stack. SAP is shifting from “vendor with useful ERP” to “enterprise AI operating system vendor.” That’s a different kind of relationship.
Ask yourself honestly: does your AI use case require enterprise-wide data harmonisation through SAP’s native semantic layer? If the use case is narrower, the migration investment to access BDC may not be justified.
SAP presents AI as what you get after migrating. But there’s a whole category of tools that flips this: AI used to accelerate migration rather than as a post-migration reward.
The best-documented open example is Microsoft’s COBOL Agentic Migration Factory (CAMF) — an open-source multi-agent system for migrating legacy COBOL code to Java, available at aka.ms/cobol on GitHub. Built on Microsoft Semantic Kernel, it runs three cooperating agents: COBOLAnalyzerAgent (scans COBOL files), JavaConverterAgent (converts COBOL to Java Quarkus), and DependencyMapperAgent (analyses relationships and generates architectural diagrams).
The Bankdata case study gives this real-world credibility. Bankdata — a technology company established by a consortium of Danish banks — had over 70 million lines of COBOL on mainframe and provided real COBOL modules for the CAMF proof of concept. AI agents generated converted code; domain experts validated business logic throughout.
A precision point that matters: CAMF is a COBOL-to-Java tool, not an SAP ABAP migration tool. Its relevance to the SAP ECC question is analogical — it proves AI agents can automate legacy code analysis and conversion at scale. There is no equivalent tool for SAP ABAP customisations at the same maturity level.
AWS Transform for Mainframe, launched May 2025, is the hyperscaler-backed equivalent targeting mainframe COBOL — not SAP ABAP. Source coverage is thinner than for CAMF. Both tools prove the class of AI-assisted modernisation works, which is the point.
Composable ERP — a Gartner term — decouples ERP processes into modular services accessed via open APIs rather than relying on a monolithic integrated suite. Keep the stable transactional core. Layer modern best-of-breed modules and AI workflows on top.
The “AI without migration” argument is straightforward: open API architectures let agentic AI workflows connect to SAP ECC without clean-core S/4HANA. AI agents call APIs to read ERP data, trigger transactions, and chain business processes. None of this technically requires an S/4HANA core.
Kingfisher — operators of Screwfix and B&Q — is the most concrete published example. Kingfisher moved its core ECC system to Google Cloud with Rimini Street support, added AI and personalisation engines, and is already seeing benefits without migrating to S/4HANA.
The Rimini Street/Freeform Dynamics global study of 455 SAP customers found 83% see clear value in composable approaches for faster AI access. Worth noting: Rimini Street is a third-party SAP support vendor with a commercial interest in the “don’t migrate” argument, so treat those statistics as directionally valid rather than neutral.
The honest trade-off: composable ERP plus agentic AI on ECC will not give you SAP Joule’s native capabilities or SAP BDC’s harmonised data layer. It gives you a different AI capability profile — more flexible, lower cost, faster to implement — but it does not replicate SAP’s native semantic layer. That’s not a knock on composable ERP. It’s just a different path to different outcomes.
Here’s how the four AI-to-ERP approaches stack up.
SAP Joule + BDC requires full clean-core S/4HANA Cloud migration. Most capable — and deepest lock-in. Primary use case: deep SAP-native AI across finance, HR, and supply chain with enterprise data harmonisation. Advanced features are new; adoption remains modest.
Composable ERP + agentic AI layer requires no migration, works with ECC via open APIs, and is production-proven — Rimini Street Agentic AI ERP is commercially available and Kingfisher is a live case study.
AI-assisted migration tools (CAMF class) don’t replace ECC — they accelerate migration itself. CAMF is COBOL-to-Java, not ABAP; production at scale for SAP ABAP is not yet established.
AWS Transform for Mainframe targets mainframe COBOL, not SAP code. Launched May 2025, less documented than CAMF.
The composable ERP path has the most real-world evidence right now. SAP Joule plus BDC represents the deepest SAP-native AI capability — but it’s new, adoption is modest, and AI governance within BDC is still evolving.
It depends entirely on which AI capabilities your business actually needs — not which capabilities SAP is marketing.
SAP’s migration-for-AI argument is strongest when you need deep, integrated SAP-native AI across finance, supply chain, and HR simultaneously; when BDC’s enterprise-wide data harmonisation is specifically what you’re after; and when you’re already on a path to clean-core S/4HANA for other reasons, making the AI capabilities incremental value on top of an already-justified investment.
SAP’s migration-for-AI argument is weakest when your required AI use cases are narrow — one or two automated processes, or targeted analytics on ECC data; when composable ERP plus a third-party agentic layer can deliver equivalent value; and when the migration investment can’t be justified on AI benefits alone.
Three questions to work through before accepting SAP’s AI argument:
1. Which specific AI capabilities does your business actually need in the next 12–24 months? Not what looks impressive in a demo — the use cases with a quantified business outcome attached. If the use cases are narrow and process-specific, the full Joule plus BDC stack may be far more than you need.
2. Can those capabilities be delivered via composable ERP plus agentic AI on ECC? Conversational ERP queries, guided process automation, API-driven AI workflows don’t require clean-core S/4HANA. Autonomous multi-step Joule agents across finance, HR, and supply chain simultaneously — these do.
3. What is the total cost comparison? Migration plus AI Units consumption plus RISE subscription fees versus the composable alternative, measured against concrete business outcomes. If the composable path delivers 80% of the value at 20% of the cost, the migration decision is a business trade-off, not a technical inevitability.
Migration is the right path to SAP’s AI. It is not the only path to AI value in an ERP environment. For a broader view of how AI is reshaping the enterprise software landscape itself — and what the SAP crisis signals about the future of monolithic ERP — see whether monolithic ERP is architecturally obsolete.
For the broader strategic context — end-of-support implications, migration paths, and how this AI question connects to the full ECC decision — see our SAP ECC migration series.
Not for all AI use cases. SAP’s most advanced AI (Joule autonomous agents, SAP Business Data Cloud) requires clean-core S/4HANA Cloud. Agentic AI on top of SAP ECC via composable architecture is achievable without migration. The key question: does your use case specifically require SAP-native AI, or is the value available via an open API plus agentic layer?
SAP Joule is SAP’s AI assistant and agent platform. Basic capabilities — natural language queries, contextual guidance, guided transactions — are accessible in BTP-connected environments without S/4HANA. Advanced capabilities — autonomous agent workflows, BDC-integrated analytics — require S/4HANA Cloud with clean-core compliance, and are priced on an AI Units consumption model on top of RISE subscription charges.
Yes — via composable ERP architecture and third-party agentic AI layers. Kingfisher (operators of Screwfix and B&Q) moved ECC to Google Cloud with Rimini Street support and added AI engines without migrating to S/4HANA. The trade-off: composable ERP will not replicate SAP Joule’s native capabilities or BDC’s data harmonisation layer.
BDC is SAP’s unified data fabric announced at Sapphire 2025: Databricks plus SAP Datasphere plus Business Warehouse plus SAP Analytics Cloud, harmonised through the SAP Knowledge Graph. It requires clean-core S/4HANA as the source system; ECC data structures are incompatible with BDC’s harmonisation layer. If your AI use case requires enterprise-wide data harmonisation through SAP’s native stack, BDC is relevant. If your needs are narrower, it may not be necessary.
CAMF (COBOL Agentic Migration Factory) is Microsoft’s open-source AI agent framework for migrating COBOL code to Java, built on Semantic Kernel and available at aka.ms/cobol on GitHub. It is a COBOL-to-Java tool — not an SAP ABAP migration tool. There is no equivalent AI-assisted tool for SAP ABAP customisations at the same maturity level.
AWS Transform for Mainframe (launched May 2025) automates COBOL-to-Java and JCL-to-Groovy conversion — like CAMF, it targets mainframe COBOL, not SAP ABAP. Both represent AI-assisted modernisation: using AI to accelerate migration rather than as a post-migration reward. Independently verified benchmarks for AWS Transform are less available than for CAMF.
Clean core is SAP’s architectural mandate for S/4HANA: no unsupported ABAP modifications in the core; all custom extensions built via SAP BTP. Joule’s advanced autonomous agent capabilities and SAP BDC both require clean-core compliance. Brownfield migrations (approximately 34%) carry ABAP customisations forward; only greenfield reimplementations (approximately 18%) typically achieve clean core. Choosing the right migration approach is therefore a direct determinant of which AI capabilities you can access post-migration.
Composable ERP (Gartner term) decouples ERP processes into modular services accessed via open APIs. You keep the stable transactional core and layer modern best-of-breed modules and AI workflows on top via APIs. 83% of SAP customers see composable approaches as a faster path to AI value (Rimini Street/Freeform Dynamics, 455 SAP customers). The trade-off: composable ERP does not provide SAP’s native AI features (Joule, BDC).
Agentic AI refers to autonomous AI systems that execute multi-step workflows without human intervention — reading data, triggering transactions, and chaining processes across systems. AI agents can interface with SAP ECC via APIs to automate tasks like invoice matching and demand forecasting without requiring S/4HANA. Third-party agentic platforms can connect via open APIs without migration.
SAP Joule is not available as a native feature of SAP ECC. Basic Joule functionality is accessible in applications connected to SAP BTP, but advanced capabilities require S/4HANA Cloud with clean-core compliance. ECC customers who want native Joule must migrate; those who want AI without migration must pursue a composable or third-party agentic approach.
SAP Sapphire 2025 in Orlando: SAP Business Data Cloud (integrating Databricks, Datasphere, Business Warehouse, and SAP Analytics Cloud); extensions to Joule’s autonomous agent capabilities tied to clean-core S/4HANA; Joule Studio reaching General Availability. Partnerships included Palantir, Perplexity AI, and NVIDIA. Forrester’s assessment: the announcements strengthen SAP’s AI narrative but don’t resolve the adoption gap.
Brownfield Greenfield or Bluefield: Choosing the Right SAP Migration Path With the DataEvery CTO evaluating an SAP ECC migration ends up staring at the same three options: brownfield, greenfield, or bluefield. Most sources give you the definitions. A comparison table. A conclusion that basically says “it depends.”
That’s not helpful. That doesn’t help you make a decision.
Here’s the context: ISG‘s 2026 research of 200 senior SAP decision-makers found that 60% of SAP migration projects ran over budget or over time — regardless of which approach they chose. Organisations don’t fail because they picked the wrong approach. They fail because they picked without a framework.
This article gives you that framework. A clear taxonomy of all three approaches, what the ISG outcome data actually shows, the clean core and AI access link most organisations miss when they go brownfield, and an original scoring model you won’t find anywhere else. This guide is part of our complete guide to SAP ECC end of support and what comes next, where we cover the full decision landscape from deadline context through strategic alternatives. If you’re still working out whether migration is the right move at all, start there first.
The short version: Brownfield converts your existing ECC system in place, keeping all customisations and data. Greenfield rebuilds S/4HANA from scratch. Bluefield — also called Selective Data Transition or SDT — selectively migrates the parts worth keeping.
SAP’s formal name is System Conversion. You take your existing ECC system and convert it to S/4HANA, retaining configurations, historical data, custom ABAP, and existing processes. Your Z-objects come with you. Your inefficient processes come with you too.
34% of organisations chose brownfield per ISG’s 2026 research. It’s the fastest time-to-go-live and causes the least initial disruption. The cost is carried-forward technical debt and a clean core deficit that limits what you can do with AI down the track.
SAP’s formal name is New Implementation. Processes redesigned from the ground up, customisations replaced by SAP standard functionality, historical data left behind — only master data and open transactions make the move.
18% of organisations chose greenfield. That low adoption reflects the change management burden and the timeline. LeverX estimates greenfield at 12–18 months versus 6–10 months for brownfield. When the 2027 mainstream support deadline is right there in your calendar, that gap matters.
“Bluefield” is SNP Group‘s trademarked term. SAP’s official label is Selective Data Transition. Both describe selectively migrating chosen data, processes, and configurations from ECC to S/4HANA.
Two sub-variants worth understanding. Shell conversion brings over most ECC configurations selectively, with decisions made during migration — moderate transition speed, moderate clean core attainment. Mix-and-match starts with a new S/4HANA system and selectively integrates ECC elements — higher clean core attainment, suited to organisations that want a modern baseline with selective legacy retention.
48% of organisations chose bluefield/SDT — a plurality. But the aggregate outcome data for the category is murky. Shell conversion and mix-and-match are meaningfully different projects. If you’re evaluating bluefield, compare against the relevant sub-variant, not the category as a whole.
The short version: The data is sobering. 60% of projects run over budget regardless of approach. Brownfield carries the highest post-migration complexity. Greenfield has the cleanest outcomes but lowest adoption. Bluefield’s aggregate data is muddied by the variance in project types it covers.
The headline from ISG’s 2026 research is not flattering for anyone: nearly 60% of projects delayed and over budget. The causes — underestimated complexity, scope creep, failure to understand internal constraints — are governance failures, not approach failures. ISG principal analyst Michael Dornan put it plainly: “A lot of the delays are caused by people, not necessarily the technology.”
Brownfield gives you the fastest time-to-go-live, but that advantage erodes. LeverX notes the time savings often vanish once you start dealing with legacy complexity. More than half of ISG respondents agreed they had over-customised their ERP to the point where standardisation felt risky. For brownfield organisations, that risk isn’t deferred — it’s imported into the new system. For the full breakdown of why brownfield migrations limit transformation value, the outcome statistics per approach are covered in depth.
Greenfield outcomes on technical debt and AI readiness are consistently the strongest. The 18% adoption reflects the change management burden and timeline cost, not poor long-term results.
Bluefield’s aggregate statistics are genuinely muddied. Shell conversion for a mid-market company and mix-and-match for a multinational are both labelled “bluefield.” Their risk profiles are not comparable. The 60% over-budget figure applies across all three approaches. Approach selection matters — but without Phase Zero governance and an ABAP assessment, no approach prevents failure.
The short version: Clean core is SAP’s architectural principle that S/4HANA should remain close to standard, with custom functionality built via SAP BTP rather than direct ABAP modifications. AI capabilities including SAP Joule require clean core to function. Brownfield delivers the lowest clean core attainment by default; greenfield delivers the highest.
SAP’s definition: keep your ERP system as close as possible to its standard state. Handle custom modifications through cloud extensions on SAP Business Technology Platform (BTP) rather than direct ABAP modifications to the core. The core stays clean. Upgrades arrive without you re-validating custom code every time.
Clean core is not just an architectural preference. It’s the gate for AI capability access. The broader implications of how the S/4HANA migration calculus has shifted with AI are covered in our complete SAP ECC end of support guide.
Brownfield migrations carry Z-objects from ECC into S/4HANA. Even the custom code that survives the conversion creates a clean core deficit — it needs post-migration remediation, rebuilt as BTP extensions. That’s a separate project, and it’s routinely underestimated when brownfield is chosen primarily for speed.
SNP Group’s technical summary puts it simply: Brownfield = Low clean core attainment. Shell Conversion = Moderate. Mix-and-Match = High. Greenfield = Very High.
SAP Joule — SAP’s generative AI copilot — requires clean master data and a standard system architecture to function. ISG’s finding: “Fragmented processes, extensive customisations, and legacy data structures often constrain which AI use cases can be effectively deployed after go-live.” Choosing brownfield for speed today may mean paying to remediate customisations later before AI features can be activated. Frame it as optionality risk. It’s real.
The short version: Run SAP’s Readiness Check and Custom Code Migration Worklist (CCMW) to inventory your Z-objects before any approach selection discussion. Custom code volume is the first hard constraint — it must be assessed before timeline or budget conversations start.
Z-objects are the custom ABAP code built on top of standard SAP ECC — programmes, reports, function modules, interfaces, and enhancements created to support business-specific processes that SAP standard didn’t cover. Their volume and business criticality determine which migration approaches are feasible for your organisation. Brownfield preserves them. Greenfield replaces them. Bluefield selectively migrates them. If you don’t know what you have, you can’t evaluate which approach fits.
SAP provides the tooling. The SAP Readiness Check analyses your ECC system and flags compatibility issues and custom code requiring remediation. The Custom Code Migration App / CCMW automates the Z-object inventory and identifies what’s compatible, what needs re-coding, and what calls retired tables. Run both before any approach selection conversation.
For each Z-object, assess four things: business criticality (does SAP standard now cover this need?), usage frequency (is this active code or dead code?), remediation effort (how many person-days to replace with a BTP extension?), and S/4HANA compatibility (does it call retired tables?). A significant portion of custom code in mature ECC systems is dead code. Removing it before migration reduces complexity regardless of approach — and is often the first leverage point for brownfield organisations.
Classify your Z-object inventory as Low (mostly standard SAP, few custom objects with S/4HANA equivalents), Medium (moderate custom code, some business-critical Z-objects requiring remediation decisions), or High (extensive Z-object inventory, core processes depend on custom ABAP, many objects call deprecated functionality). This classification feeds directly into the scoring model below. One note: organisations in the 50–500 employee band typically have lower Z-object volumes than the large enterprise benchmarks used in most migration research — smaller organisations may find greenfield more feasible than published analysis implies.
The short version: Phase Zero is the pre-migration governance stage — data quality, scope definition, stakeholder alignment, success metrics — that must be completed before technical migration begins. ISG identifies governance failures as the primary driver of the 60% over-budget rate. Brownfield projects are the most likely to skip it.
Phase Zero covers five things: who owns data quality decisions and by what date; a data readiness audit to find and fix dirty, duplicate, and incomplete master data before it enters the migration stream (migration tools can move your data — they can’t fix it); a scope lock that freezes which processes and entities are in scope before technical teams begin; executive sponsorship and decision authority confirmation; and agreed success metrics before any vendor is engaged.
Brownfield has a psychological trap. Converting what you already have feels lower risk — less apparent unknown. That perception causes organisations to underinvest in questioning whether what they have is what they actually want to carry forward. Phase Zero is where those questions get answered. Brownfield projects that skip it find the answers during testing, when fixes are expensive and consulting fees spike. The fastest approach to go-live becomes the most delayed project in progress.
The short version: Score your organisation on three dimensions — customisation volume, timeline urgency, and transformation ambition — on a 1–3 scale. Total scores of 3–4 point to greenfield; 5–6 to bluefield; 7–9 to brownfield as the pragmatic choice.
Every source on this topic provides criteria. None of them provide a scoring model. That’s the gap this framework addresses.
Dimension 1: Customisation Volume (from your ABAP audit)
Dimension 2: Timeline Urgency (distance to deadline and internal business drivers)
Dimension 3: Transformation Ambition (how much process redesign you want from the migration)
Total 3–4 → Greenfield. Low customisation, flexible timeline, and high transformation ambition align with clean-core reimplementation.
Total 5–6 → Bluefield / SDT. Moderate customisation, moderate urgency, mixed transformation ambition. Use shell conversion if your starting point leans brownfield; mix-and-match if you want a greenfield baseline with selective legacy retention.
Total 7–9 → Brownfield. High customisation volume and/or urgent timeline constrains your options. Accept the clean core deficit as a known cost and plan explicitly for post-migration remediation before AI features can be activated.
Three caveats to keep in mind. Change management capacity is a fourth dimension that can override numerical results — a transformation ambition score of 3 with no change management budget doesn’t reflect reality. A score of 7–9 doesn’t mean greenfield is impossible — it means the implications need explicit executive acknowledgment. And Phase Zero must be completed before the score is meaningful; scoring ambition without a data readiness audit produces a number that flatters your aspirations rather than reflects your readiness.
The short version: When ECC covers a non-core function a SaaS replacement handles better, when you’re in active M&A, when customisation volume makes every approach unviable, or when your transformation ambition is zero. 39% of SAP ECC customers had not migrated as of Q4 2024 — not all of them are paralysed.
Most analysis on this topic assumes migration is the answer and just frames the decision as “which approach.” That assumption deserves scrutiny.
Gartner data shows 39% of SAP’s 35,000 ECC customers worldwide had not migrated as of Q4 2024, nearly a decade after S/4HANA launched. Not uniformly in denial — some have made deliberate choices. And the 2027 cliff isn’t as vertical as it’s often portrayed: mainstream support ends at the end of 2027, but extended support at a 2% premium is available until end of 2030.
Four scenarios where reconsidering migration makes sense. Your ECC system covers a non-core function a modern SaaS tool now handles cheaper. You’re in active M&A and migrating into a system that may be rationalised increases sunk cost risk. Your ABAP audit reveals Z-object volumes so high that every approach is unviable and composable architecture is the better near-term path. Or your transformation ambition is zero and migration is purely a compliance exercise. That last one is a legitimate reason to migrate — just be upfront about it. Organisations that migrate without a transformation thesis are most likely to appear in the next round of ISG over-budget statistics.
For a detailed analysis of when the composable approach is the right call, our companion article covers the alternatives to SAP S/4HANA migration in full. For a complete overview of all aspects of the SAP ECC decision — from deadline mechanics through financial modelling to strategic alternatives — see our complete SAP ECC end of support guide.
Brownfield (System Conversion) converts the existing ECC system in place, retaining all customisations and historical data. Greenfield (New Implementation) builds S/4HANA from scratch, redesigning processes and replacing custom code with SAP standard functionality. Brownfield is faster to go live but carries technical debt forward; greenfield takes longer but delivers a cleaner, AI-ready system. Per ISG 2026 research: brownfield 34%, greenfield 18%.
Bluefield — also called Selective Data Transition (SDT) — is a hybrid approach that selectively migrates chosen data, processes, and configurations from ECC to S/4HANA. “Bluefield” is SNP Group’s trademarked term; SAP’s official term is Selective Data Transition. Two main sub-variants: shell conversion (closer to brownfield) and mix-and-match (closer to greenfield).
Bluefield / SDT is the plurality choice at approximately 48% per ISG 2026 research. Brownfield: 34%. Greenfield: 18%. Most common does not mean best outcomes — 60% of projects run over budget regardless of approach.
Clean core is SAP’s architectural principle that S/4HANA should remain close to standard, with custom functionality built via SAP BTP rather than direct ABAP modifications. It is required to access SAP’s embedded AI features, including SAP Joule. If AI adoption is a strategic priority, clean core is a prerequisite, not an option.
Brownfield migrations can achieve clean core but don’t deliver it by default. Z-objects carried forward from ECC create a clean core deficit requiring separate remediation — rebuilding customisations as BTP extensions post-migration. SNP Group rates brownfield clean core attainment as Low. This cost is routinely underestimated when brownfield is chosen for speed.
LeverX’s estimates for single-country standard deployments: brownfield 6–10 months; bluefield/SDT 9–18 months; greenfield 12–18 months. Organisations starting now have feasible timelines for all three. Those starting after mid-2025 may find greenfield tight without phased go-live strategies.
They are synonymous in practitioner usage. SAP’s official term is Selective Data Transition; “bluefield” is SNP Group’s trademarked label. Both describe selectively migrating data, configurations, and processes from ECC to S/4HANA.
Z-objects are custom ABAP code built on top of standard SAP ECC to support business-specific processes. Their volume and criticality are the primary technical variable in migration approach selection. High Z-object volumes make brownfield the default but also the approach most at risk of clean core deficit. SAP’s Readiness Check and CCMW automate the inventory process.
Phase Zero is the pre-migration governance stage — data quality assessment, scope definition, stakeholder alignment, and success metric agreement — completed before technical work begins. ISG identifies governance failures as the primary driver of the 60% over-budget rate. Phase Zero takes six to twelve weeks and is most often skipped in brownfield projects.
Not necessarily. Bluefield offers more selective control, but heavy customisation volumes still require individual Z-object assessment decisions. If your customisation volume is high and most of it is business-critical, the operational advantage of bluefield over brownfield narrows considerably. Complete the ABAP audit first.
In a greenfield implementation, custom ABAP code is not migrated. Each Z-object requires assessment: some will be replaced by SAP standard functionality, some rebuilt as BTP extensions, and some represent processes needing redesign. This assessment is the primary upfront investment that makes greenfield achievable for organisations with moderate customisation volumes.
The Real Cost of Migrating to SAP S4HANA and How to Build a Business Case That HoldsA Rimini Street-commissioned Foundry survey of 455 SAP customers found that 95% say building a positive ROI case for S/4HANA migration is “difficult or takes significant effort.” That is not a fringe view. It is the near-universal experience of the people who have actually tried to run the numbers.
The 2027 SAP ECC end-of-mainstream-maintenance deadline is turning what should be a deliberate financial decision into a perceived forced march. That is exactly when expensive mistakes get made.
Here is what this article gives you: a TCO comparison framework across three strategic paths, a clear-eyed look at the perpetual licence surrender decision, and the inputs you need for a business case that will hold up in a board meeting. This article is part of our complete guide to SAP ECC end of support and what comes next, which covers every dimension of the 2027 decision.
There are concrete structural reasons why this is so hard. It is not because your finance team is bad at spreadsheets.
The Rimini Street/Foundry numbers tell you everything: 95% of 455 surveyed customers find positive ROI “challenging.” Ninety percent are worried about subscription cost unpredictability. And at the end of 2024, only 39% of SAP’s 35,000 ECC customers had actually migrated — and S/4HANA has been out for nearly a decade.
The structural problem is that SAP’s own ROI calculators leave out the costs that hurt the most: dual-run periods, custom code remediation, productivity loss during cutover, and mandatory Signavio add-ons. The Horváth Partners study of 200+ executives fills in the gap — 65% missed quality targets, 60% suffered planning overruns averaging 30% longer than planned, and 55% exceeded budget. Only 8% completed on schedule. For a full breakdown of why SAP projects go wrong, see why SAP migrations fail at a rate that should concern every decision maker.
The benefits of S/4HANA are real. They are also long-dated. The costs are immediate. A genuine positive ROI case requires a full TCO model across a 5–7 year horizon — one that includes the hidden costs and a realistic execution risk premium.
This is the part that most migration conversations gloss over. It should not be glossed over.
Signing RISE with SAP requires surrendering your perpetual ECC licences as a precondition. Once surrendered, those licences are permanently retired from your account. There is no mechanism for SAP to reinstate them. None.
Your SAP ECC perpetual licences are owned assets. You paid for them once and own the right to run that software indefinitely, with an annual maintenance fee of around 22% of the original licence value. RISE with SAP is a subscription — an OpEx model that eliminates licence ownership entirely.
This is a one-way door. If you later want to exit RISE, you need to purchase new licences at current market prices or leave SAP entirely. As Redress Compliance put it: “Once surrendered, you cannot go back. Ensure the RISE economics genuinely justify giving up an asset you own forever.”
SAP has also become more assertive about auditing as the 2027 deadline approaches — a mechanism to accelerate the conversation toward RISE.
For your business case, the perpetual licence value must appear as a sunk asset written off at RISE signing. A quantified cost. Not an invisible concession.
The RISE headline price is not the total commercial commitment. Not even close.
RISE bundles S/4HANA Cloud, managed infrastructure, and SAP BTP access. But several meaningful costs sit outside that number, and they add up fast.
SAP Signavio. Forrester Research (Akshara Naik Lopez, Charles Betz) confirmed SAP is “moving toward mandating that RISE-validated partners use SAP Signavio and LeanIX from day one of major cloud transformation programs.” Not optional. Its own subscription cost on top of everything else.
SAP BTP overages. BTP is bundled in RISE, but usage-based costs for integrations and extensions are metered and not capped in standard contracts. Consumption charges escalate quickly without a hard ceiling in writing.
Implementation partner cost. The actual migration is not included in RISE. You pay a GSI or SAP partner separately — typically 1.5–3x the first-year licence cost, according to ERP Logic data.
FUE licensing complexity. S/4HANA Cloud uses Full User Equivalents rather than named users. Organisations routinely underestimate FUE requirements at scoping and then discover at go-live that their actual usage patterns require more expensive licences — triggering true-up costs at renewal.
Dual-run costs. Running ECC alongside S/4HANA during migration means double-paying for 12–24 months. Almost never included in SAP’s estimates.
Renewal price escalation. RISE contracts typically allow 5–7% annual price increases. Without a cap in the initial contract, a five-year deal could cost 25–35% more on renewal.
Run the full model before you sign anything. The on-premises perpetual model often has a lower cumulative TCO over seven or more years once you do the honest maths.
BTP is not just a budget line item. It is a structural commitment that gets harder to undo the longer you are in it.
SAP Business Technology Platform (BTP) replaces on-premises ABAP customisations in an S/4HANA Cloud deployment. The clean core mandate — SAP’s architectural requirement — means all custom ABAP code must be removed from the core system. Any code that survives must be re-platformed to BTP.
Forrester Research (Akshara Naik Lopez, Charles Betz) names the consequence directly: “SAP’s shift toward bundled, subscription-based cloud models and heavy dependence on the Business Technology Platform for extensibility increases vendor lock-in.” Integrations built on BTP use SAP-proprietary APIs and cannot be lifted to another platform without a full rebuild.
Years of ABAP customisation investment must either be abandoned, rebuilt in BTP at cost and with new lock-in, or re-evaluated as over-engineered. The clean core mandate forces that reckoning whether you are ready for it or not.
The commercial context explains why this is not going to change. SAP SE reported €36.8 billion in 2025 revenue, with cloud backlog growth decelerating. SAP needs BTP adoption metrics. This is structural, not incidental.
Before finalising any migration cost estimate, audit every custom ABAP programme, integration, and user exit. Organisations that skip this audit routinely encounter 30–50% cost overruns at implementation.
Any defensible business case must evaluate all three options honestly. If your business case only models the migration path, it is not a business case — it is a justification.
Path 1 — Migrate to S/4HANA via RISE with SAP
The full cost picture: perpetual licence write-off, RISE subscription (years 1–5 with 5–7%/year renewal escalation), SAP Signavio (mandatory), BTP usage overages (metered), implementation partner fees (1.5–3x first-year licence), dual-run period (12–24 months), custom code remediation to BTP, training and change management. For organisations in the 50–500 employee range, migration costs typically run $1M–$5M over the first 24 months, excluding dual-run costs. Halliburton (NYSE: HAL) disclosed $42 million in SAP S/4 migration costs in Q4 2025 alone — and that is a single quarter.
Path 2 — Remain on SAP ECC with third-party support
Rimini Street or Spinnaker Support typically charge 50% of SAP’s maintenance fee, plus internal support team retention and a risk premium for operating post-2027. Third-party support covers security patching and regulatory updates for up to 15 years beyond SAP’s own deadlines. For many organisations, the 5-year TCO of this path is lower than Path 1. Worth modelling honestly. For a deeper look at this option and its risks, see the SAP alternatives SAP will not tell you about.
Path 3 — Composable ERP transition
ECC decommissioning, new application licensing across multiple vendors, integration platform costs, data migration, process redesign, and full retraining. Typically the highest short-term cost, but it eliminates SAP vendor dependency entirely.
The TCO comparison framework
Populate every cost category for your specific environment. Do not rely on vendor-supplied numbers for any path — including SAP’s.
The cost components to model: migration or transition cost; annual licence and support in year one and year five (accounting for escalation); BTP or integration platform costs; implementation partner fees; dual-run period; training and change management; and a risk premium calculated as base cost × 1.25 to 1.35, using the Horváth data.
SAP has three commercial leverage mechanisms working in its favour right now. The 2027 support deadline creates urgency. Extended ECC support to 2030 is gated through RISE commercial commitments. And renewal pricing is not capped in standard RISE contracts.
But the dynamic cuts both ways. SAP’s stock fell 22% on 29 January 2026 following cloud backlog deceleration guidance. Customers with credible alternatives have real leverage at initial contract negotiation — and that is the window you need to use.
Five practical negotiation levers:
No large enterprise pays SAP list price. Discounts of 30–70% are common. If you are accepting less than 40% on a significant deal, you left money on the table.
Most migration business cases fail not because the numbers are wrong, but because they use SAP’s framing. That framing starts with “you must migrate” and works backwards to justify the decision. A board-ready case starts somewhere else entirely: “Here are three legitimate paths. Here are the honest costs and risks of each. Here is our recommendation.”
Four things you need to build it properly:
If recommending RISE, the perpetual licence surrender must appear as an asset write-off. Omitting it is a material misrepresentation of the RISE path cost — and a board that finds out later will not be pleased.
For board credibility, cite the data that holds up to scrutiny: the Rimini Street/Foundry survey (95% ROI difficulty — this is industry-wide, not your internal failure); Forrester Research (Akshara Naik Lopez, Charles Betz — independently names BTP lock-in risk); Horváth Partners (execution risk data); Halliburton Q4 2025 ($42M — publicly audited, SEC-disclosed).
When you complete this process, you will have the vocabulary and evidence base to have a substantive commercial negotiation with SAP — not just accept the terms offered. For a broader view of all strategic options across the 2027 decision, see our comprehensive SAP ECC end-of-support guide.
For many organisations, yes — on a 5-year TCO basis. Rimini Street or Spinnaker Support typically reduce annual maintenance by around 50% compared to SAP’s own fee, with no implementation cost, no perpetual licence write-off, and no escalation risk. Third-party support buys you time but does not resolve what comes after 2030. It is a legitimate path and genuine negotiating leverage with SAP.
Perpetual licence surrender means handing back your SAP ECC licences as a precondition for signing RISE. Those licences are permanently retired from your account. It cannot be reversed. If you later want to leave RISE, you need to purchase new licences at current market prices or exit SAP entirely. Treat it as an asset write-off in the financial model.
RISE creates lock-in through two mechanisms: perpetual licence surrender makes returning to on-premises SAP expensive; BTP dependency increases switching costs because custom integrations built on BTP cannot be moved to another platform without a full rebuild. Forrester Research (Akshara Naik Lopez, Charles Betz) explicitly names BTP dependency as a strategic risk in their “SAP Sapphire 2025: What Tech Leaders Need To Know” analysis. Lock-in scales with BTP investment.
Renewal leverage is limited — SAP CEO Christian Klein has confirmed the company will not discount the renewal base. The leverage window is initial contract negotiation. Get formal competitive quotes, time the deal to SAP’s Q4 end, and negotiate renewal price caps and Signavio/BTP cost limits at signing. Once you are live on RISE with surrendered licences, that leverage disappears.
SAP Signavio is a process intelligence platform SAP acquired and integrated into its portfolio. It is mandated from day one of RISE-validated partner programmes — not optional — with its own subscription cost on top of everything else. If you do not plan to actively use it, negotiate its cost or a credit into the RISE contract before you sign.
Apply the Horváth Partners data as a risk multiplier: 65% of SAP migrations missed quality targets; 60% suffered planning overruns averaging 30% longer than planned; 55% exceeded budget; only 8% completed on schedule. The formula: (Base Migration Cost) × 1.25 to 1.35.
A dual-run period is when both SAP ECC and S/4HANA run simultaneously for testing and cutover validation — typically 3–12 months. The cost is doubled infrastructure plus internal resource cost. It is almost never included in SAP’s or implementation partners’ estimates. It belongs as a separate line item in your TCO model.
2027 ends SAP’s mainstream maintenance for ECC — no standard support packages or functional updates after that date. Extended support at a 2% premium is available through 2030 via SAP or RISE. The deadline is a commercial lever, not a technical cliff. Rimini Street and Spinnaker Support offer continued ECC support post-2027, covering security patching and regulatory updates.
Greenfield is a clean-slate implementation — starting fresh, higher upfront cost, clean system. Brownfield converts existing ECC configuration directly into S/4HANA — lower upfront cost but carries legacy technical debt forward. Around 49% of organisations pursue a hybrid approach, the most common real-world outcome despite being the most complex to plan.
For organisations in the 50–500 employee range with moderate ECC customisation, migration costs on the RISE path typically run $1M–$5M over the first 24 months. Gartner cites $2M to $1B depending on complexity. Key components: RISE subscription, implementation partner fees (1.5–3x first-year licence), infrastructure, training, and custom code remediation.
Clean core is SAP’s architectural mandate for S/4HANA Cloud: all custom ABAP code and direct modifications to the SAP core must be removed. Code that cannot be eliminated must be re-platformed to SAP BTP — the primary hidden cost driver in migrations with heavily customised ECC landscapes. Audit every custom integration, ABAP programme, and user exit before finalising a migration cost estimate. Organisations that skip this routinely encounter 30–50% cost overruns.
Why SAP Migrations Fail at a Rate That Should Concern Every Decision MakerThe numbers don’t make for comfortable reading. More than 60% of SAP migrations exceed budget, only 8% complete on schedule, and 65% of organisations that reach go-live report significant quality deficiencies on the other side. That’s from Horvath Partners‘ “Business Transformation Unlocked” study — a survey of 200-plus executives at SAP-using companies.
ISG’s 2026 “State of SAP Migrations” report surveyed 200 senior decision-makers at large global companies and landed in nearly the same place — close to 60% falling behind schedule and budget. Two independent research bodies. Similar conclusions. That’s not noise, it’s a pattern.
This is the typical experience across roughly 35,000 SAP ECC customers facing a 2027 end-of-mainstream-maintenance deadline. This article is part of our complete guide to SAP ECC end of support and what comes next, which covers that broader context in detail. What most migration content glosses over is the specific failure mechanisms behind these statistics — and what failure actually looks like at mid-market scale. This article names those mechanisms directly, and works through realistic project costs for organisations with 50–500 employees using the only publicly disclosed enterprise cost data available.
The Horvath study (reported by CIO.com) found that budgets were blown severely in one quarter of migrations and moderately in another 40% — the 60% figure is a composite of both. Schedules fared even worse: only 8% finished on time, and the average project ran 30% longer than planned.
ISG’s independent survey reached almost the same conclusion from a completely different sample. The convergence matters. Horvath is a German management consultancy. ISG is a technology research and advisory firm with no systems integration business — no financial incentive to overstate the problem. When two research bodies with no relationship to each other land on similar figures, the statistics are defensible.
Christian Daxböck, study director and Horvath partner, put it plainly: “This mismatch leads to the enormous discrepancies between plan and results.” The mismatch is between how organisations assess their own complexity and what they actually encounter once the project is underway. Both surveys cover large enterprises with 1,000-plus employees — which matters, because mid-market organisations face proportionally similar failure causes with fewer resources to absorb the consequences. For context on what the 2027 end-of-mainstream-maintenance deadline actually means and which ECC customers are affected, that context is covered separately.
ISG’s data shows that only 18% of organisations implement new business processes when migrating to S/4HANA. Nearly half — 49% — carry their existing processes over unchanged. That tells you a lot about why brownfield migration is popular, and why the outcome data for it is so problematic.
Brownfield migration (system conversion) takes your existing ECC configuration, customisations, and historical data and moves them directly into S/4HANA. Less immediate disruption, shorter timelines, easier stakeholder buy-in. The catch is that it also carries forward every ABAP customisation your organisation has accumulated over the past decade or two — all of the technical debt, unresolved. Those 49% who carry legacy processes unchanged aren’t streamlining their business. They’re reconstituting their customisation burden in the new system.
Greenfield migration — a clean S/4HANA implementation requiring full business process redesign — eliminates that debt, but at a cost: higher upfront investment and a longer timeline that most mid-market organisations find hard to justify. Selective data transition offers a middle path, migrating selected processes or data subsets, but it’s underrepresented in outcome data and requires careful scoping. Choosing between these approaches is one of the highest-stakes decisions in the migration process. As Stanton Jones, ISG analyst, noted: “To fully leverage the potential of automation, analytics, and AI, companies must be prepared to make fundamental changes in governance, data quality, and process standardisation.”
Phase Zero is the structured preparation stage that happens before formal project kickoff — equivalent to the Discover phase in SAP’s Activate methodology. It defines what the project covers and what “done” looks like before you sign anything with a systems integrator.
In practice, Phase Zero produces five deliverables: a detailed business case, a target operating model, a solution architecture blueprint, a change management plan, and a data and integration strategy. ISG identifies weak governance — not technical challenges — as the primary cause of migration delays. Phase Zero is where governance structures, decision-making rights, and SI accountability mechanisms get established.
When Phase Zero gets compressed — and it does get compressed, because it’s not billable SI work and nobody wants to delay the “real” project start — scope enters execution unresolved. Data quality problems that could have been mapped before kickoff become unplanned cost items in month seven. The Horvath survey makes the failure pattern concrete: top challenges cited included lack of IT integration perspective (28%), insufficiently defined processes (24%), and lack of knowledge about third-party systems (23%). Phase Zero failures, all of them, showing up as execution problems.
ABAP (Advanced Business Application Programming) is SAP’s proprietary language for customising and extending ECC functionality. Over a typical 10–20 year ECC deployment, organisations accumulate thousands of custom programmes, modifications, and enhancements — bespoke reports, workflow extensions, interface adaptors, workarounds for processes that didn’t fit standard SAP behaviour. All of it works in ECC. None of it is automatically compatible with S/4HANA.
Custom code is described as “the single biggest risk factor in any SAP transformation” by SmartShift, a firm specialising in automated ABAP remediation. Every custom programme must be inventoried, tested for compatibility, and either refactored, retired, or replaced with standard S/4HANA functionality. Many organisations don’t have an accurate inventory — documentation is outdated, usage tracking is nonexistent, and nobody is quite sure what’s actually running in production.
The failure mechanism follows a consistent sequence: undiscovered ABAP debt surfaces during execution, late-stage scope expansion is required, costs and timeline blow out. Horvath’s research names scope expansion as the main reason for overruns, ahead of suboptimal project delivery and poorly managed data transition. The scope expansion isn’t random. It’s the inventory you didn’t complete in Phase Zero, presenting its bill.
Scope creep is the mechanism that connects Phase Zero neglect and undiscovered ABAP debt to the budget and schedule overruns in the Horvath and ISG data. Four drivers compound each other during execution.
Undiscovered ABAP customisations surface once code analysis actually begins — scope additions that were never in the original plan. Data quality problems not assessed in Phase Zero require remediation work that’s now on the critical path. Business stakeholders who see the new system for the first time start adding requirements. Integration failures with third-party systems that weren’t fully mapped generate unplanned work that pushes go-live.
ISG’s Stacey Cadigan is direct about the governance dimension: “Many migration programmes involve multiple system integrators, SAP service providers, and niche specialists — there is a lack of clear decision-making rights, acceptance criteria, and responsibilities between providers.” Without those structures, every new discovery becomes a renegotiation rather than a controlled scope decision.
ISG recommends linking part of providers’ compensation to specific delivery metrics — data migration completeness, integration test stability, cutover sample success — to align incentives from the start. Building a defensible business case starts with understanding how scope expands before it starts.
Before the numbers: what follows is an analytical model, not empirical data. No publicly available peer-reviewed cost data exists for mid-market SAP migrations. The figures below are derived from enterprise-scale disclosures and published implementation benchmarks, with stated assumptions. Use them for planning and contingency modelling, not contract negotiations.
The only publicly disclosed enterprise-level migration cost comes from Halliburton (NYSE: HAL), a Fortune 50 global oilfield services company. Their Q4 2025 investor relations disclosure reported $42 million in SAP S/4 migration costs for that quarter alone. Halliburton is an extreme upper bound — decades of ECC customisation, a complex global operational environment, and a scale of integration work with no direct parallel in a 200-person technology company.
Published benchmarks suggest implementation costs of $1,000–$3,000 per named SAP user for mid-market projects, with data migration adding 15–25% of implementation cost on top. Working from those benchmarks:
50–100 employees (30–60 SAP users): total project cost in the range of $300,000–$900,000
100–250 employees (60–150 SAP users): total project cost in the range of $800,000–$2.5 million
250–500 employees (150–300 SAP users): total project cost in the range of $2 million–$6 million
These ranges assume adequate Phase Zero investment. If Phase Zero gets compressed, add 20–40% to the upper bound of each range — that’s the contingency the 60% over-budget rate from Horvath justifies.
Cost components that many initial estimates miss: implementation services (SI fees), data migration and remediation, infrastructure, internal resource time, training, and a post-go-live remediation reserve. The 65% quality deficiency rate means that reserve isn’t optional — it’s planning for the near-certain. Ninety-five percent of SAP customers say making an ROI case for S/4HANA is difficult or takes significant effort, per a Rimini Street survey of 455 organisations. The total cost of ownership question is harder to answer than most migration content lets on.
IBM completed its S/4HANA migration in July 2024 and reported a 30% reduction in infrastructure-related operational costs. Worth understanding what produced that result — because IBM’s success is not a counterargument to the failure statistics. It’s evidence of what success actually requires.
Four elements appear consistently across successful migrations.
Substantial Phase Zero investment: scope, data quality, and custom code addressed before commitment. A clean core commitment: deliberately minimise ABAP customisations in the new system and accept business process changes rather than technical workarounds. Strong governance: defined scope change processes and SI accountability mechanisms in place from day one. Phased go-live: staged deployment that limits the impact of any single quality defect.
Each element is the structural inverse of a documented failure cause. IBM’s scale is larger than a 200-person technology company, but the structural principles transfer. The preparation investment is what determines how migration approach affects outcomes.
The failure rate data is an input to decision-making, not an argument against migrating. The 2027 end-of-mainstream-maintenance deadline is fixed. With only a minority of SAP ECC customers having fully completed their S/4HANA transition, Horvath’s assessment is that executives “will start to feel the heat” — late starters face compressed Phase Zero timelines and heightened competition for specialist SAP labour.
The data suggests three specific adjustments to how you should frame the decision.
If budget is constrained: the 60% over-budget rate means initial estimates are structurally optimistic. Plan for the upper bound of the cost ranges above, not the midpoint. More than 40% of Horvath respondents said they would increase the budget from the outset given the chance to do it again.
If timeline is constrained: the 8% on-schedule rate means schedule contingency is not a risk mitigation option — it’s a planning requirement. A project starting now with an 18-month estimate has a high probability of landing post-2027 without contingency built in.
If your organisation has significant ABAP customisation debt: a thorough code audit before contract signature is the single most reliable way to improve estimate accuracy. It surfaces scope before it becomes a change order.
The alternative to migrating before the deadline isn’t indefinite ECC operation. SAP’s extended support runs to 2030; Rimini Street extends SAP support until 2040 for customers preferring to stay on ECC. Both carry their own cost and risk profiles. Our complete guide to SAP ECC end of support and what comes next covers those strategic options in detail.
The Horvath and ISG statistics are not a reason to delay. They’re a reason to start Phase Zero now, with adequate budget and the expectation that initial estimates will need revision. Build contingency in from the start rather than discovering the need for it mid-project — that’s what separates the 8% who finish on schedule from the 92% who don’t.
A 200-employee organisation with approximately 100–120 SAP users can expect a total project cost in the range of $1.2 million–$3.5 million, based on published benchmarks of $1,000–$3,000 per named SAP user for implementation services plus 15–25% for data migration.
That assumes adequate Phase Zero investment. Compress preparation and you should add 20–40% to the upper bound. The cost components include implementation services (SI fees), data migration and remediation, infrastructure, internal resource time, training, and a post-go-live contingency reserve — not just licence fees. No publicly available empirical data exists for mid-market migrations; these figures are derived analytically from enterprise-scale disclosures.
The 8% on-schedule completion rate reflects three compounding causes. Phase Zero neglect means scope is unresolved at project start. ABAP custom code volumes are consistently underestimated — organisations often don’t know what they have. Governance failures mean scope changes get renegotiated ad hoc rather than controlled through defined processes.
ISG identifies governance failure — unclear decision-making rights and weak SI accountability — as the top cause of project delays, not technical complexity. Horvath Partners found the average SAP S/4HANA implementation takes 30% longer than originally anticipated.
Phase Zero is the structured pre-migration preparation stage — equivalent to the Discover phase in SAP’s Activate methodology — conducted before formal project kickoff.
It produces four key deliverables: a data readiness assessment, a custom ABAP code audit, a system landscape map, and defined scope with acceptance criteria. Organisations that invest in Phase Zero consistently outperform those that compress or skip it. ISG identifies weak Phase Zero governance as the leading cause of migration failures.
Brownfield (system conversion) carries existing ECC configuration, customisations, and historical data into S/4HANA — lower immediate disruption but inherits all ABAP technical debt. Greenfield (new implementation) starts with a clean S/4HANA instance and re-implements business processes from scratch — eliminates ABAP debt but requires full redesign and higher upfront investment. Selective data transition (SDT) is a hybrid approach migrating selected processes or data subsets.
Only 18% of organisations implement new processes during migration per ISG, which explains why brownfield remains the most common choice despite its worse long-term outcome profile.
ABAP (Advanced Business Application Programming) is SAP’s proprietary language for customising and extending ECC functionality. Over years of operation, SAP ECC installations accumulate thousands of custom ABAP programmes that are not automatically compatible with S/4HANA.
Every custom ABAP programme must be inventoried, tested, and either refactored, retired, or replaced with standard S/4HANA functionality — a process that reveals scope larger than initial estimates. Technical debt that isn’t addressed during transformation multiplies and makes future upgrades harder.
Poor data quality is the silent killer in SAP migrations — organisations pour effort into technical configuration while data issues slip under the radar until go-live exposes them. Duplicate customer records, incomplete vendor data, and inconsistent financial account structures that look clean on the surface cause operational failures once S/4HANA starts processing them.
Over 90% of data migration projects run over time or budget due to data quality problems, per Gartner figures cited by DataVapte. Master Data Management — building clean “golden records” for core business objects — is the remediation approach, but it requires Phase Zero investment to scope and implement before migration begins.
ISG identifies governance failure as the primary cause of SAP migration delays — not technical complexity, but the organisational structures controlling the project. The specific failures: unclear business ownership of requirements, inability to make binding decisions on scope trade-offs, and absence of contractual accountability mechanisms over systems integrators.
Without defined scope change management processes, each new discovery — undiscovered ABAP debt, data quality problems — becomes an ad-hoc renegotiation rather than a controlled decision. Governance investment is a Phase Zero deliverable: define decision-making rights, scope change thresholds, and SI acceptance criteria before project kickoff, not after the first change order.
What SAP ECC End of Support Actually Means and Why 17000 Companies Are Not ReadySAP ECC is the operational core for roughly 35,000 large and mid-market organisations worldwide. For most of them, it has been running finance, payroll, procurement, inventory, and compliance reporting for the better part of two decades.
SAP has confirmed it will stop mainstream maintenance on a fixed schedule. The problem is that most public coverage squashes all ECC customers into a single “2027 deadline” — and that framing is wrong. Some companies are already past their deadline without knowing it.
This article answers three things: which deadline actually applies to your system, what operationally changes on the day after that deadline, and why so many organisations are not ready. It is the entry point to the complete SAP ECC end-of-support guide.
SAP ECC 6.0 — also known as SAP ERP 6.0, part of SAP Business Suite 7 — has been the dominant on-premises ERP platform since 2005. It was perpetually licensed: customers paid once and owned the software. That is precisely why moving away from it is so sticky.
Approximately 35,000 enterprises run ECC globally. SAP confirmed in 2023 that there will be no further extensions to the end-of-mainstream-maintenance dates. Once that support gap opens, the operational and regulatory exposure starts to accumulate.
Here is the thing most coverage gets wrong: the “2027 deadline” does not apply to all SAP ECC customers.
SAP ECC 6.0 supports Enhancement Packages (EHP) — incremental add-on releases installed on top of the base system. The EHP version you are running determines your exact end-of-mainstream-maintenance date. Two groups, two different deadlines.
SAP’s Arne Schmidthals confirmed this split directly: “For SAP ERP 6 with Enhancement Packages 0-5, mainstream maintenance ends on December 31, 2025. Those still using these versions at that point will automatically transition into Customer Specific Maintenance.”
The split matters beyond the date. Extended Maintenance — the paid option that keeps security patches and legal updates flowing through 2030 — is available only for EHP 6-8 customers. If you are on EHP 0-5, there is no Extended Maintenance option. Your only SAP-supported post-2025 path is Customer-Specific Maintenance, which provides no new security patches and no new legal or regulatory updates.
EHP 0-5 customers can upgrade to EHP 6-8 to push their deadline to December 31, 2027 and gain eligibility for Extended Maintenance. But as Natuvion notes, this “typically makes little sense” — it is time, resources, and money poured into a temporary solution.
To confirm your EHP version, check the SAP Product Availability Matrix or reference SAP Note 2269324.
Mainstream Maintenance is SAP’s full-coverage support tier. Here is what actually changes when it ends.
What stops:
What does NOT stop:
As Forrester’s Akshara Naik Lopez put it: “Support from SAP is ending for the product, but it does not mean that the ECC environment is, all of a sudden, going to stop working.” The risk is not binary.
What accumulates instead: unpatched CVEs, legal changes not reflected in your software, and — as Natuvion notes — auditors who are “unable to certify the system or requiring significant additional effort to do so.”
One distinction worth being clear on: “end of mainstream maintenance” is not “end of support.” You automatically fall into Customer-Specific Maintenance, which technically continues — but its scope is so narrow that treating the two as equivalent is a mistake.
Day one: the system runs exactly as before. Nothing breaks. That absence of immediate failure is precisely why so many organisations treat the deadline as theoretical rather than operational.
From there, the exposure builds. SAP stops issuing new security patches — CVEs discovered after December 31, 2027 will not receive SAP-issued fixes. Tax law changes and payroll legislation amendments stop being incorporated into the software. The audit risk — SOC 2, ISO 27001, financial audit — typically becomes a formal control deficiency in the 12-24 months following the deadline, not on day one.
Rixmind’s analysis captures the trajectory well: companies that delay end up paying for legacy SAP maintenance AND future migration costs at the same time. Not a cliff. A steady grade.
For EHP 6-8 customers who elect Extended Maintenance before 2027, this plays out differently — Extended Maintenance covers security patches and legal updates through 2030. The scenario above applies to those who do neither. For alternatives to SAP’s native options, see our guide to SAP ECC alternatives and third-party support.
The 17,000 figure comes from Gartner. As of end-2024, only 39% of SAP’s 35,000 ECC customers — roughly 14,000 organisations — had purchased SAP S/4HANA transition licences. Purchasing a licence is a proxy for intent, not completion. Gartner projects 17,000 holdouts by 2027, with more than 13,000 still running ECC in 2030.
Gartner VP Fabio Di Capua was blunt about it: “When SAP tried to make people move to RISE, we told them, ‘You convinced less than half of your clients to migrate in 15 years. How can you think you will migrate the next 50% in five years?'”
The Horváth study (2025) of 200 SAP user companies found projects running 30% longer than planned, only 8% finishing on schedule, and more than 60% exceeding budget. Of those 200 companies, only 37 had actually completed migration. ISG research from February 2026 found nearly 60% of projects delayed and over budget, with two-thirds still in the planning stage.
For a detailed breakdown of why, see why so many SAP migrations exceed budget and schedule.
Three options exist. They differ fundamentally in scope, cost, and eligibility.
Extended Maintenance (EHP 6-8 only): January 1, 2028 through December 31, 2030. Includes new security patches and legal/regulatory updates. Adds approximately 2 percentage points to your SAP maintenance fee. Must be elected in advance — it is not automatic.
Customer-Specific Maintenance: The default fallback for all ECC customers after their deadline. You keep access to existing SAP Notes but get no new security patches, no new legal or regulatory updates, minimal bug fixes — at the same cost as mainstream maintenance. That last point is where most of the confusion comes from.
SAP ERP, private edition, transition option: Announced Q1 2025. Available to select large, complex customers who sign a RISE with SAP agreement and commit to migrating their database to SAP HANA by end of 2030. Provides continued ECC support past 2030. Not general availability. SAP has confirmed it is “only centered on ECC 6 and does not include the full scope of Business Suite 7.”
The distinction that matters most here: Extended Maintenance and Customer-Specific Maintenance are not the same thing. Companies who fall into Customer-Specific Maintenance by default receive less coverage at the same cost. That is worth repeating.
For detailed cost modelling see the true cost of SAP S/4HANA migration. For third-party support options see SAP ECC alternatives and third-party support.
RISE with SAP and GROW with SAP are SAP’s two commercial packages for accessing S/4HANA. The naming is confusing. The distinction matters.
RISE with SAP targets larger, more complex ECC customers migrating to S/4HANA private cloud. It bundles managed cloud infrastructure, migration support tooling, and access to the Private Edition Transition Option.
GROW with SAP targets mid-market customers heading toward S/4HANA Cloud, Public Edition — standardised process fit, limited customisation.
For ECC customers: heavily customised systems typically follow a brownfield path to private cloud via RISE. Simpler environments can use GROW for a greenfield move to public cloud. As Arne Schmidthals at SAP put it: “For customers already using SAP ERP, the private cloud is the usual path.” Neither package is inherently cheaper.
Here is a five-step framework for arriving at a defensible recommendation.
Step 1 — Confirm your EHP version. Check the SAP Product Availability Matrix or reference SAP Note 2269324. EHP 0-5 means your deadline was December 31, 2025 — already passed. EHP 6-8 means December 31, 2027. Most organisations skip this step. Do not.
Step 2 — Assess your compliance and regulatory exposure. Which legal and regulatory changes must your ECC system incorporate annually — payroll legislation, tax law, government reporting? Estimate the workaround burden if those updates stop. Regulated industries face more exposure here than most.
Step 3 — Run SAP Readiness Check. SAP’s free tool analyses your ECC system for S/4HANA compatibility, identifies custom code volume, and documents database migration requirements. Do this before talking to any consultants.
Step 4 — Assess internal capacity. Do you have a dedicated SAP team or are you relying on external consultants? Do you have budget for a 12-24 month project? The Horváth data points to the biggest failure drivers: lack of IT integration (28%), insufficiently defined processes (24%), knowledge gaps around third-party interfaces (23%).
Step 5 — Model three paths. (a) Migrate at current rates. (b) Elect Extended Maintenance (EHP 6-8 only) and target 2030 — buys time at roughly 2% extra fees, but consulting rates tend to rise as the window narrows. (c) Evaluate third-party support as a deliberate strategic choice — Rimini Street offers support through 2040 at approximately 50% of SAP’s pricing.
There is no universal right answer. The right choice depends on your regulatory exposure, migration complexity, and internal capacity.
For help building the financial model, see the true cost of SAP S/4HANA migration and why so many SAP migrations exceed budget and schedule. Our complete SAP ECC end-of-support guide covers each path in depth.
No. After December 31, 2027, EHP 6-8 customers automatically fall into Customer-Specific Maintenance — same cost as mainstream maintenance, but no new security patches and no new legal or regulatory updates.
Extended Maintenance adds patches and legal updates through 2030 at approximately 2 extra percentage points. It must be elected in advance. There is no free support path after the deadline.
SAP ECC is the legacy on-premises ERP system — built on traditional relational database architecture like Oracle, MS SQL, or IBM DB2. Perpetual licence, in production since the early 2000s.
SAP S/4HANA is the current-generation platform, built exclusively on SAP HANA in-memory database. Faster, simplified data model, available on-premises or in the cloud. The migration is not a simple upgrade — it requires a database migration and, depending on your approach, business process re-engineering and custom code adaptation.
No. The 2027 deadline applies only to EHP 6, 7, or 8. Customers on EHP 0-5 had an earlier deadline — December 31, 2025 — which has already passed. EHP 0-5 customers have no Extended Maintenance option; their only SAP-supported post-2025 path is Customer-Specific Maintenance.
It is the default tier after mainstream maintenance expires. Same cost, but: no new security patches, no new legal or regulatory updates, no new HR compliance updates, minimal bug fixes. Organisations relying on it for compliance-critical processes accumulate growing exposure over time.
Extended Maintenance is exclusively for EHP 6-8 customers. It runs January 1, 2028 through December 31, 2030 and includes new security patches and legal/regulatory updates. It costs approximately 2 additional percentage points on top of existing maintenance fees, must be elected in advance, and is not available for EHP 0-5 customers.
Announced Q1 2025. Select large, complex customers can continue using ECC past 2030 within an SAP-managed private cloud environment — but only if they sign a RISE with SAP agreement and commit to migrating their database to SAP HANA by end of 2030. Not general availability. Commercial terms require direct engagement with SAP.
Limited internal SAP expertise, no dedicated migration team, budget constraints, and underestimation of complexity. More than half of surveyed organisations had over-customised legacy ERP to the point where standardisation now feels risky — inertia that blocks decisions.
The Horváth study found more than 60% of migrations deviate significantly from planned budget, schedule, or quality targets, with only 8% finishing on schedule. The challenge is structural, and it is widespread.
Projects average 30% longer than planned; only 8% complete on schedule (Horváth, 200 SAP user companies). Gartner has worked with clients anticipating three- to seven-year projects for complex environments.
For organisations targeting 2027 completion, timeline compression is real. Start your readiness assessment now.
At end-2024, only 39% of SAP’s 35,000 ECC customers had purchased S/4HANA transition licences — a proxy for intent, not completion. Gartner projects 17,000 holdouts by 2027 and more than 13,000 still on ECC in 2030.
Third-party SAP support replaces SAP’s maintenance contract with an independent provider. Rimini Street offers support for SAP ECC 6.0 through 2040 at approximately 50% of SAP’s pricing, including patches for newly discovered CVEs and legal/regulatory updates that Customer-Specific Maintenance does not cover.
It is a deliberate strategic choice for some organisations — when the migration business case is unclear, when more time is needed, or when the long-term ERP strategy is still being worked out. Not suitable for everyone; it carries commercial and legal complexity worth assessing properly.
Yes. EHP 0-5 customers can upgrade to EHP 6-8, moving their deadline to December 31, 2027 and gaining eligibility for Extended Maintenance through 2030. An EHP upgrade is not a migration — it does not move you to S/4HANA. Given the 2025 deadline has already passed for EHP 0-5 customers, treat this as an urgent near-term decision.
The authoritative source is the SAP Product Availability Matrix (PAM). SAP Note 2269324 in the SAP Support Portal covers ECC 6.0 maintenance end dates and enhancement package distinctions. Seidor’s summary is a well-organised secondary reference.
What the SaaS Reckoning Means for Your Software Stack and What to Do About ItIn the first week of February 2026, over $1 trillion in market capitalisation was erased from software stocks. HubSpot dropped 51%. Monday.com fell 44%. ServiceNow shed 36%. The press called it the SaaSpocalypse. The more accurate label is the SaaS Reckoning: an accountability moment for an industry whose core business model — charging per seat for software that AI agents can now operate without human seats — is under pressure from a shift in how work gets done.
Per-seat pricing dropped from 21% to 15% of SaaS vendors in twelve months (Bain). 35% of dev teams have already replaced at least one SaaS tool with a custom AI-built alternative (Retool 2026). SaaS spending overall is still growing — Forrester projects $512 billion by 2028 — but the distribution across vendors and pricing models is shifting.
This guide is the hub for our seven-article deep dive. Each section answers a key question and links to the full analysis.
In this guide:
Suggested reading order: The SaaS Reckoning Explained → Vendor Survival Framework → AI Agent Mechanisms → AI-Native vs Incumbents → Pricing Shift → Audit Playbook → Build vs Buy Economics.
The SaaS Reckoning did not arrive from a single event — it arrived from a convergence. Anthropic‘s Claude Cowork launch on January 12, 2026, demonstrated that AI agents could replace multi-seat SaaS workflows. When ServiceNow reported earnings on January 28 and acknowledged slowing growth tied to AI displacement, investors repriced the entire sector. More than $1 trillion in SaaS equity value was erased in the following weeks.
The sell-off exposed an underlying repricing that had been building since late 2025 — Infinite Runway’s “Great SaaS Crash” narrative traces the pressure from November 2025 onwards. HubSpot (-51% YoY), Monday.com (-44%), ServiceNow (-36%), Atlassian (-26.9% YTD) — these are not identical businesses, but the market applied an “uncertainty tax” to each because the five-year revenue model is now opaque. The collapse was not a repeat of the 2022 SaaSacre (rising rates, over-valued growth stocks) — this time the structural threat is to the business model itself, not just multiples. SaaSpocalypse is the informal label; SaaS Reckoning is the more accurate frame — an imposed accountability moment, not extinction.
Full analysis: The SaaS Reckoning Explained
SaaS is not dying — it is bifurcating. Global enterprise SaaS spending is still projected to grow from $318 billion (2025) to $512 billion (2028). What is collapsing is a specific business model: software that charges per seat for orchestrating workflows that AI agents can now perform without human seats. Systems of record — ERP, compliance infrastructure, core HR — remain structurally sound. The risk is concentrated in workflow wrappers.
The K-shaped bifurcation framework is the key analytical lens: some SaaS companies will adapt and emerge stronger; others will lose revenue as seat counts compress without a pricing model replacement. “System of record” versus “workflow wrapper” is the vocabulary to bring to every vendor review — it is the single most useful diagnostic for whether a tool is defensible. The “dumb pipe” risk — where SaaS becomes commoditised storage beneath an AI agent layer — is real but not universal; it applies primarily to horizontal workflow software. SaaS spending overall will grow; what will shrink is per-seat licence revenue at the layer AI agents are replacing.
Deep dives: The SaaS Reckoning Explained | Which SaaS Vendors Will Survive
AI agents attack SaaS business models through seat compression: they complete multi-step workflows — form submission, data retrieval, ticket routing, CRM updates — without a human operator at each step. Because SaaS vendors charge per seat, fewer human operators means less licence revenue, even if the same amount of work is being done. The revenue model depends on human headcount; AI agents decouple output from headcount.
Seat compression is the mechanism: the number of paid user licences a customer needs falls as AI agents absorb task sequences previously requiring human attention. AI unbundling goes further — AI agents can replicate the core function of a workflow wrapper without any SaaS licence at all, effectively reducing the tool to zero marginal value. The “dumb pipe” risk is the extreme version: SaaS becomes infrastructure (storing data) while an AI agent layer above it does the actual workflow work — vendors collect storage fees while the value migrates upward. Three tiers of disruption risk emerge from mechanism analysis: (1) deterministic workflow wrappers (highest risk), (2) probabilistic systems requiring human judgement (medium risk), (3) regulated systems of record (lowest risk).
Full mechanism breakdown: How AI Agents Actually Attack SaaS Business Models
Vulnerability maps to two factors: how much of the vendor’s value is in workflow orchestration (vs. proprietary data storage), and how deterministic the workflows are (structured sequences vs. complex judgement calls). Project management tools, basic CRM data entry, and customer support ticketing are most vulnerable. ERP systems, regulatory compliance infrastructure, and vertical industry SaaS with deep data moats are most defensible.
Bain’s four-scenario framework provides a useful classification: Core Strongholds (defensible), Open Doors (vulnerable workflow wrappers), Gold Mines (AI-native challengers taking share), Battlegrounds (incumbent vs. AI-native fight in progress). Vendor evaluation requires looking past the AI washing — many incumbents are bolting chatbots onto existing products without structural architectural change; Salesforce Agentforce and ServiceNow Now Assist are test cases for whether this strategy constitutes genuine adaptation. Systems of record (Workday, SAP, Veeva) carry high switching costs, deep data integration, and regulatory compliance — AI agents need these data backbones, not replacements for them. Horizontal SaaS (project management, HR tools, generic CRM) faces the most structural disruption; vertical SaaS built for specific industries (HealthTech, FinTech, legal, construction) has defensible domain data moats.
Full framework: Which SaaS Vendors Will Survive the AI Reckoning
The evidence leans toward genuine structural shift, not hype. AI-native companies captured 63% of the enterprise application layer in 2025, up from 36% in 2024 (Menlo Ventures). Cursor reached $1 billion ARR with 300 employees. Harvey reached $8 billion valuation at $100 million ARR. But the Jasper AI trajectory — peak $1.5 billion valuation followed by rapid decline as ChatGPT commoditised its niche — is a necessary counterpoint.
The valuation premium for AI-native companies at Series D is 50–80x vs. 6–12x for traditional SaaS (SaaStr data) — investors are pricing in the structural advantage of being built around AI from inception rather than retrofitting it. Enterprise AI spending grew from $1.7 billion in 2023 to $37 billion in 2025 (Menlo Ventures) — this is not a speculative market; it is an accelerating reallocation of budget from SaaS seats to AI capability. AI-native challengers exist in nearly every major SaaS category: DayAI (vs. Salesforce CRM), Decagon/Sierra (vs. Zendesk), Rillet (vs. traditional ERP) — this is not a distant threat for most CTO portfolios. The cautionary signal: AI-native companies that do not own proprietary data or workflow complexity face their own commoditisation risk as AI capabilities become more accessible.
Full evidence analysis: AI-Native Startups vs SaaS Incumbents
Per-seat pricing is declining as the dominant SaaS revenue model — it dropped from 21% to 15% of SaaS vendors in 12 months (Bain). The replacements are usage-based pricing (pay per API call or transaction) and outcome-based pricing (pay for results). Gartner predicts 40% of SaaS spending will shift away from seat-based models by 2030. Your next renewal conversation will likely include a new pricing structure, whether you initiate it or not.
Usage-based pricing (UBP) is already the dominant model among AI-native SaaS — 83% of AI-native vendors offer UBP vs. a minority of incumbents (Maxio survey data). Outcome-based pricing is earlier stage but directionally significant: Zendesk was the first major incumbent to offer an outcome-based tier (August 2024), pricing by resolved tickets rather than agent seats. Salesforce’s Agentic Enterprise License Agreement (AELA) signals how major incumbents are restructuring contracts to account for AI agents — a template for what you may see from other enterprise vendors. At the 50–500 employee scale, per-seat pricing often means you are paying for seats tied to headcount that AI tools are already reducing — the renewal window is your leverage point to restructure terms.
Full pricing analysis: SaaS Pricing Is Shifting from Per-Seat to Usage and Outcome
Four actions, in sequence: Audit your current stack to identify tools with high AI disruption exposure. Renegotiate contracts using AI alternatives as pricing leverage before auto-renewal windows close. Evaluate AI-native alternatives against each at-risk tool. Decide: keep, renegotiate terms, replace with an AI-native product, or build a custom alternative using AI coding tools. The Forrester REAP model structures exactly this sequence with a practical decision matrix.
The audit step requires a scoring framework: vulnerability (workflow wrapper or system of record?), replaceability (does a credible AI-native alternative exist?), renewal timing (how much runway before the next contract window?). The renegotiate step has time-bound leverage — the existence of AI alternatives changes your BATNA (Best Alternative to a Negotiated Agreement); this leverage is strongest before renewal auto-triggers. The evaluate step is where vendor AI roadmap credibility becomes critical: distinguish between genuine agentic capability (Salesforce Agentforce, ServiceNow Now Assist — in progress) and AI washing (chatbot added to a 2019-era product interface). The decide step feeds directly into build-vs-buy calculations — AI coding tools have materially lowered the cost floor for custom-built replacements, which affects the ROI threshold for the “build” option.
Step-by-step playbook: Auditing and Rebuilding Your SaaS Stack | Pricing negotiation: SaaS Pricing Shift
AI coding tools — Cursor, GitHub Copilot, and comparable tools — have materially lowered the cost and skill floor for custom software development. Vibe coding (natural-language-prompted AI development) now makes replacing a mid-market SaaS tool with a custom-built alternative economically viable in timeframes that previously would not have justified the development cost. Retool’s 2026 survey found 35% of dev teams had already replaced a SaaS tool with a custom AI alternative.
The build-vs-buy calculus has historically favoured buy for all but the most specialised workflows; AI coding tools have shifted the cost input substantially, particularly for teams with existing developer capacity. Vibe coding is not zero-cost: governance, security review, maintenance, and compliance obligations (critical for FinTech/HealthTech CTOs under HIPAA or SOC 2 requirements) add TCO that does not appear in the initial development estimate. Shadow IT risk is elevated in the vibe coding era — individual contributors can now build functional SaaS-replacing tools without IT oversight, creating data governance and security exposure. The decision framework: build makes sense when the SaaS tool is a workflow wrapper (not a system of record), when a credible AI-native replacement does not yet exist, and when the team has the capacity to maintain what it builds.
Full economic analysis: How AI Coding Tools Have Changed the Economics of Building vs Buying Software
No. Global enterprise SaaS spending is projected to grow to $512 billion by 2028. What is under structural pressure is a specific revenue model — per-seat pricing for workflow orchestration software — not enterprise software as a category. Systems of record, vertical SaaS with deep domain data, and platforms with genuine AI integration are all positioned to grow through the transition.
Deep dive: The SaaS Reckoning Explained
SaaSpocalypse is the informal industry label — popularised by Forrester analyst analysts in late 2025 and widely adopted in media coverage — for the wave of SaaS valuation collapses and business model disruption driven by AI agent adoption. The term has high search volume and genuine cultural resonance, but it overstates the uniformity of the outcome. Not all SaaS faces the same disruption risk.
Seat compression is the mechanism by which AI agents reduce the number of paid user licences a SaaS customer needs. When AI agents automate multi-step workflows that previously required a human operator at each step, the headcount required to do the same amount of work decreases — and with it, the number of seats the customer must purchase. This is the primary structural threat to per-seat SaaS revenue models.
Deep dive: How AI Agents Actually Attack SaaS Business Models
The highest-risk categories are horizontal workflow wrappers: project management tools, basic CRM data-entry layers, customer support ticketing at the human-interaction tier, and generic marketing automation. The lowest-risk categories are systems of record with deep regulatory integration (ERP, core HR, compliance infrastructure) and vertical SaaS built for specific regulated industries (HealthTech, FinTech, legal, construction).
Deep dive: Which SaaS Vendors Will Survive the AI Reckoning
Vibe coding refers to AI-assisted software development using natural-language prompts to tools like Cursor or GitHub Copilot, enabling developers (and increasingly non-developers) to produce functional code rapidly. It has significantly lowered the cost floor for custom-built internal tools, making the “build” option economically viable for use cases where the SaaS renewal cost exceeds the vibe-coded replacement cost plus ongoing maintenance.
Deep dive: How AI Coding Tools Have Changed the Economics of Building vs Buying Software
AI washing is the practice of relabelling existing product features as “AI-powered” without structural capability change — typically manifested as a chatbot interface overlaid on a 2019-era product architecture. Key interrogation signals: Does the vendor’s AI capability function as an autonomous agent (multi-step workflow execution) or as a single-turn assistant? Can it take actions, or only surface recommendations? Is the AI layer trained on your proprietary data, or generic?
Deep dive: Which SaaS Vendors Will Survive the AI Reckoning
The Forrester REAP model is a four-step framework for SaaS buyers navigating the AI disruption transition: Renegotiate existing contracts using AI alternatives as leverage; Evaluate AI-native alternatives against at-risk tools; Audit the current stack for disruption exposure; Prioritise action based on renewal timing and risk score. It provides the structural backbone for the audit → renegotiate → evaluate → decide action sequence described in this cluster.
Deep dive: Auditing and Rebuilding Your SaaS Stack in the Age of AI
How AI Coding Tools Have Changed the Economics of Building vs Buying SoftwareFor most of your career, the answer to “build or buy?” has been obvious. Building a meaningful SaaS MVP costs $500K–$1M, takes 6–12 months, and needs a team. Buying was almost always the rational call.
That assumption is now wrong for a growing category of tools.
AI coding tools — Cursor, Claude Code, GitHub Copilot — have collapsed the cost of building a functional SaaS alternative to near-zero in tooling cost over roughly the past 18 months. The build vs. buy ROI calculation looks entirely different when development time shrinks from months to days. This article is part of our comprehensive SaaS Reckoning guide, which covers the full landscape of AI’s impact on enterprise software.
For a growing category of point tools, the question is no longer “can we afford to build it?” It is “can we afford to keep paying for it?”
This article covers what has changed, what the evidence shows, and a practical framework for when building now makes sense. Shopify, Duolingo, and Cursor are corporate-scale evidence — not proof-of-concept demos.
Let’s be specific about the numbers. Previously: $500K–$1M, a team of 5–10 engineers, 6–12 months. That cost structure made buying almost always rational. The SaaS vendor had amortised those costs across thousands of customers — you could not compete on price.
AppDirect reached more than 90% AI-generated code in one year, reporting a 70% reduction in development costs and a 5x output multiplier. In-house teams building five times more applications than traditional IT teams could support. At Google, over 30% of new code is now generated with AI assistance. These are operational realities at scaled organisations — not experiments.
When build cost drops from $500K to $5K in engineering time, tools that were obviously “buy” become rational “build” candidates. As Joe Reis put it: “That ‘build versus buy’ spreadsheet you’ve been using? It’s increasingly obsolete, so factor in what AI can generate, how quickly, and at what cost.”
Vibe coding — Andrej Karpathy‘s term for AI-assisted development via natural language prompts — is the name that has stuck. The name undersells the tools.
Cursor, Claude Code, GitHub Copilot, and Codex are full development environments. They handle architecture, testing, refactoring, documentation, and debugging — not just autocomplete. The workflow is Plan → Code → Review: build a feature specification with the LLM, generate code via an agentic loop, then review. It is a genuinely different process from writing code manually. (The same agentic loop dynamic is what makes AI agents disruptive to SaaS business models at a mechanism level — worth understanding before committing to a build or buy position.)
AppDirect reached 90% AI-generated code in one year: speed increased, onboarding improved, quality held. The work shifted from typing syntax to architecture, assumptions, and product thinking.
AI-generated code carries real security and maintenance risks if your review process is weak. The productivity gain is documented. So is the discipline requirement. The question is not whether the tools are ready — it is whether your team has the discipline to use them well.
Compound engineering — referenced in a16z’s analysis of the AI software development stack — describes a single developer using AI coding agents to maintain and ship multiple products simultaneously. AppDirect’s CEO puts the ratio at 5x. Engineers who adopt AI tools at OpenAI open 70% more pull requests than their peers.
“We don’t have the engineering capacity to build and maintain it” was a legitimate objection when an internal tool required a dedicated team. For narrow-function tools, that objection no longer holds in the same way. One developer with AI tooling can own what previously required three to five.
What compound engineering does not mean: it is not a case for eliminating headcount. Your team-sizing cost models were built for pre-AI output rates. Those need updating.
The most credible evidence operates at scale — not in startups with nothing to lose.
Shopify’s AI-first policy: Tobi Lütke’s mandate requires developers to demonstrate they cannot use AI tools before requesting additional headcount. AI use is a baseline performance expectation — built into hiring and performance evaluation, not a productivity suggestion.
Duolingo’s 148 languages: Duolingo launched 148 new language courses in under a year, more than doubling its existing content. Under traditional development this would have required years and a much larger team — the most concrete output-per-developer data point in the public record.
Cursor as dual evidence: Cursor reached $500M ARR and approximately $10B valuation within 15 months — a company built using its own AI-coding paradigm, adopted at a rate that signals category-level acceptance in professional engineering teams. For a broader analysis of how AI-native startups are challenging SaaS incumbents, Cursor is one of many examples across the application layer.
The Shopify and Duolingo examples are the ones to anchor to: established organisations with mature engineering practices and real customers.
The $0 MVP concept refers to near-zero tooling cost, not zero cost. Cursor costs under $100 per developer per month. Claude Code and GitHub Copilot are similarly priced. The remaining cost is engineer-hours — and that number has dropped significantly.
Ben Yoskovitz at Highline Beta built a full contacts tool in approximately 2 days with Lovable, replacing a CRM subscription for 30–40 users. A basic CRM dashboard — previously 3–4 months at $150K–$200K — can now be built in 1–2 developer weeks.
What the $0 MVP does not include: ongoing maintenance, security review, infrastructure costs, and developer time to iterate. As the Focused Chaos analysis notes: “You have to maintain the software. Users will want more features. They’ll report bugs and want support.” There is also the institutional knowledge risk — if the people who built it leave, you are left with an orphaned application.
When annual SaaS cost exceeds the cost to build and maintain internally, building is now economically rational. The SaaS CFO frames this well: customers do not even need to build an alternative to change renewal negotiations — they just need to credibly threaten it. The broader SaaS reckoning framework explains why this negotiating leverage has shifted so decisively toward buyers.
The answer in 2026 is not “always build.” Klarna replaced Salesforce CRM with an internally developed AI system, customer satisfaction declined, and they reversed course. Targeted replacement of narrow-function point tools is the right model.
Four criteria determine the build case:
1. Workflow type: Point tools with narrow, well-defined functionality are now prime build candidates. Systems of record — payroll, ERP, compliance data, financial ledgers — are still firmly “buy.” AppDirect’s CTO Andy Sen is direct: “For anything where the results have to be one hundred percent predictable, there’s no room for hallucinations. Financial software, core billing, systems of record for medical information — those aren’t going to be replaced by AI anytime soon.”
2. Regulatory exposure: Any workflow touching regulated data — healthcare, financial reporting, payments, HR compliance — should remain “buy.” Validation overhead negates build cost savings for most mid-market teams.
3. Team capacity for maintenance: Compound engineering enables one developer to own more, but it requires that developer to exist and stay. If the team cannot absorb ongoing maintenance, the economics shift back toward buying.
4. Competitive differentiation potential: If the functionality is a source of competitive advantage, building gives you roadmap ownership. If it is commodity workflow management, the differentiation value is zero.
The practical trigger: SaaS tool costs more per year than four weeks of a developer’s fully-loaded time, it is not in a regulated category, scope is narrow, and your team has maintenance capacity — the build case is worth running.
The full portfolio audit and vendor renegotiation playbook is covered in Auditing and Rebuilding Your SaaS Stack in the Age of AI.
The compound engineering model changes what is valuable in engineering work, not just how fast it gets done.
The developer who can specify system behaviour precisely, review AI output critically, and make sound architectural decisions is more valuable than the developer who writes boilerplate quickly. Language polyglot skills are becoming less important — system design, architectural judgement, code review discipline, and domain expertise are the differentiators now.
Shopify’s AI-first policy made this explicit: AI tool proficiency is built into hiring criteria and performance evaluation. “Can you work effectively with AI tools?” is the baseline expectation.
If your team is already using AI coding tools, the maintenance overhead of building internal tools is lower than your cost model suggests. A16z’s framing: staff for judgement and ownership, not headcount-to-output ratios.
The Refactoring FM survey of 340 engineering teams found 44% have no dedicated time for AI experimentation. The output gap is already observable. Shopify’s policy and Duolingo’s output metrics are not future projections.
For the complete picture — from understanding the SaaS market shift through to auditing your stack and renegotiating vendor contracts — see the full SaaS Reckoning guide.
Vibe coding — popularised by Andrej Karpathy in early 2025 — means writing software specifications in natural language and having AI generate the code. It is production-ready when used with proper code review and security discipline. AppDirect runs 90%+ AI-generated code in production with a 70% reduction in development costs. The risk is weak review processes that introduce problems expensive to fix later.
Tooling cost is near-zero — Cursor, Claude Code, and GitHub Copilot each cost under $100 per developer per month. The real cost is engineer-hours: a point tool with narrow scope can be built in 1–2 developer weeks. Ongoing maintenance is what most calculations underestimate — budget 10–20% of initial build time per year.
They serve different use cases. Cursor is an AI-first code editor for greenfield development. Claude Code handles complex reasoning and architecture. GitHub Copilot integrates tightly with existing IDE workflows. Most engineering teams use more than one — they are complementary, not competing choices.
One developer using AI coding agents can maintain and ship multiple software products simultaneously — an output ratio that previously required teams of five to ten. AppDirect’s CEO puts the ratio at 5x. AI handles implementation; the developer focuses on architecture, specification, and review.
The validation overhead changes the economics significantly. In regulated contexts — HIPAA, PCI-DSS, SOX — every piece of code requires security review, audit trail documentation, and compliance testing. Time saved in writing is partially offset by validation requirements. For most mid-market teams, payroll, financial ledgers, and healthcare data platforms remain “buy.”
Tobi Lütke’s mandate: developers must demonstrate they cannot accomplish a task with AI tools before requesting additional headcount. AI use is a baseline performance expectation built into hiring and evaluation. For other engineering leaders, this is a policy precedent worth watching.
No. Klarna replaced Salesforce CRM with an internally built AI system, customer satisfaction declined, and they reversed course. Targeted replacement of point tools where the economics favour building is the rational approach. ERP, payroll, financial systems of record, and tools where vendor support is load-bearing should remain “buy.”
Build candidates: reporting dashboards on your own data, simple internal portals, basic workflow automation, lightweight CRM-adjacent tools, data pipeline tools, and simple ticketing systems. Still buy: ERP, payroll, financial and healthcare data platforms, billing and subscription management, identity and access management, and security tooling. The principle: system of engagement, narrow scope, no regulated data — realistic build candidate.
When annual SaaS subscription cost exceeds (initial build cost + annual maintenance + infrastructure cost). A rough heuristic: if the tool costs more than four weeks of a developer’s fully-loaded time, is a point solution outside regulated categories, and your team has capacity to maintain it — the build case is worth running the numbers.
A team of five using AI tools may now outship a traditional team of ten to fifteen. This does not mean reducing headcount — it means hiring for judgement (system design, architecture, domain expertise, review discipline) rather than implementation throughput. Re-run your headcount projections with compound engineering assumptions before finalising the number.
Cursor reached $500M ARR and approximately $10B valuation within 15 months — a company built using its own AI-coding paradigm, growing at a rate that signals category-level acceptance in professional engineering teams.
Traditional: developer writes code manually, cost front-loaded in engineering time, maintenance permanent. AI-assisted: developer specifies behaviour, AI generates implementation, developer reviews and iterates, cost reduced by 50–70%+ depending on task. The key difference: AI-generated code still requires maintenance — the ongoing cost is lower, but not zero, and your team must retain the skill to understand and modify what was built.
Auditing and Rebuilding Your SaaS Stack in the Age of AI — A Practical PlaybookIn early February 2026, more than $1 trillion in enterprise software market cap disappeared in seven days. The SaaSpocalypse — as Jefferies and Forrester have labelled it — is forcing decisions that most CTOs at 50–500 employee companies have been putting off.
The problem is SaaS sprawl. Forrester identifies uncontrolled portfolio growth as a primary pain point for technology leaders — and AI is making it both more expensive (vendor pricing uplifts) and more solvable (AI-native alternatives at a fraction of the cost).
This playbook gives you four phases: inventory and classify, triage, build vs. buy, and renegotiation. You’ll end up with a ranked vendor action list and a 90-day plan, with AI investment funded from SaaS savings — which is the framing that makes this a board-level conversation instead of just an IT project. This article is part of our comprehensive SaaS reckoning guide, where we cover the full strategic landscape from market context through to tactical execution.
The per-seat pricing model is collapsing. According to Bain, in three years any routine, rules-based digital task could move from “human plus app” to “AI agent plus API” — and vendors are already pricing accordingly. 65% of the 30+ SaaS vendors Bain analysed have introduced a hybrid approach, layering an AI usage meter on top of seat-based pricing, while 35% have bundled AI into per-seat price increases. Gartner predicts 40% of enterprise SaaS spending shifts to usage- or outcome-based pricing by 2030 — and that shift is already happening at renewals now, not in four years.
The opportunity is in the gap between vendor uncertainty and buyer inaction. One company that spent $18K per month on Datadog discovered 12 people logged in per month and 89% of metrics were never viewed. Audit proactively and you lock in favourable terms before vendors regain confidence. The political case for AI tooling depends on showing reallocation from SaaS savings — not addition. That framing starts here.
Start with spend data, not software lists. Pull actual invoiced SaaS spend from finance for the last 12 months — all vendors, all amounts, seat counts. Most CTOs are surprised to find 30–40% of tools are used by fewer than 20% of their licensed seats. Include free-tier and browser-based tools to capture the full shadow IT footprint.
Once you have the data, apply the Bain Four-Scenario Framework to classify each vendor across two dimensions: the potential for AI to automate the core workflow, and the potential for AI to penetrate the product category.
Core Strongholds — low automation potential, low AI penetration. Procore‘s project cost accounting and Medidata‘s clinical-trial randomisation both require deep domain expertise and regulated data flows. Don’t waste energy on replacing these.
Open Doors — low automation potential, high AI penetration. Third-party agents can already hook into exposed APIs and replicate the core value. HubSpot list building and Monday.com task boards are the canonical examples.
Gold Mines — high automation potential, low AI penetration. Incumbents hold exclusive data and rules that give them a head start. Look for AI feature extension rather than replacement.
Battlegrounds — high automation potential, high AI penetration. Intercom‘s Tier 1 support, Tipalti‘s invoice processing, and ADP‘s time-entry approvals are all easy to automate — and just as easy for others to copy.
Layer the Forrester REAP Model on top as the disposition layer: Reassess, Extract, Advance, and Prune. It maps to business fitness and technical fitness. Open Door vendors typically get Prune or Extract. Core Strongholds get Extract. Battleground vendors get Reassess or Advance. For a deeper look at how to evaluate which specific vendors are likely to survive this transition — and which are structurally exposed — see our vendor survival framework.
Focus your audit on the top 20 vendors by spend — these account for 80–90% of your SaaS budget. Don’t attempt to audit the full tail immediately. Create an AI vulnerability score for each using three inputs: workflow type (deterministic vs. probabilistic), seat utilisation rate, and availability of viable AI-native alternatives today. Deterministic SaaS — payroll, ERP, compliance, healthcare records — scores low vulnerability. Probabilistic SaaS — content, task management, marketing automation — scores high.
The output is a ranked priority list: each top-20 vendor with its Bain quadrant, REAP disposition, and AI vulnerability score. That list drives everything that follows.
The filter is simple: prioritise vendors where renewal is within 12 months and the vendor falls in the Open Door or Battleground quadrant. When both conditions are true, you have maximum leverage and minimum time.
Tier 1 — act now (0–90 days): Open Door and Battleground vendors with renewals approaching. AI-native alternatives already exist in these categories and vendors negotiate hardest when displacement is demonstrably real. Build a genuine BATNA before entering any negotiation — a theoretical alternative doesn’t move vendors, a real quote from a competitor does. ZoomInfo is flexible because Apollo and Clay exist; Gong negotiates because Clari and Salesloft are options.
Tier 2 — prepare now, act at renewal: Battleground vendors with renewals 12–24 months out. Begin building the AI-native comparison case now so you have leverage when the deadline arrives.
Tier 3 — monitor: Core Strongholds. Renegotiate on price and terms only, not replacement. Don’t waste leverage on vendors whose regulatory depth and data moats protect them.
A realistic Tier 1 action list is three to five vendors. Running too many parallel renegotiations at once exhausts capacity — you’ll execute nothing well.
The build vs. buy calculus has shifted. AI coding tools like Cursor and Claude Code reduce MVP development costs from hundreds of thousands of dollars to near-zero. 35% of engineering teams have already replaced at least one SaaS tool with a custom build, and 78% plan to build more in 2026. But the maths depends on what you’re building, at what cost, and whether you can sustain it. For a full analysis of how AI coding tools have changed the economics of building vs. buying software, including developer productivity data and maintenance cost models, see our dedicated article on that topic.
The practical threshold: a SaaS tool costing $100,000 a year is worth building internally; a tool costing $10,000 a year is probably not. Use four criteria to evaluate each candidate:
1. Workflow criticality: If errors create regulatory exposure or revenue loss, the risk of a custom build exceeds the savings. Stay with a tested incumbent.
2. Team capacity: If your engineering team is fewer than five full-time developers, in-house builds are unlikely to be sustainable without a dedicated maintenance commitment. As Jason Evanish puts it: “The day-one math looks great. Month 18 is where it falls apart.” AI product debt compounds just like technical debt.
3. Regulatory exposure: If the workflow involves PII, financial data, healthcare records, or multi-jurisdictional compliance, build only if you have dedicated compliance engineering capacity.
4. Replacement cost: If an AI-native SaaS alternative exists at 30–50% of the incumbent’s cost with equivalent core functionality, buy first and build later.
The best build candidates are high-volume, low-complexity automation workflows — data pipelines, reporting dashboards, lead scoring, customer notifications — locked inside expensive per-seat tools. ClickUp built six AI tools connected to Salesforce, Zendesk, and Snowflake that cut $200K per year in automation subscriptions. Narrow scope, measurable savings, maintainable by a small team.
The worst build candidates are anything involving compliance audit trails, multi-party regulated integrations, or where a vendor’s data moat is genuinely irreplaceable. One governance note: 60% of engineers have already built something outside IT oversight in the past year. If you don’t have a clear build policy, your team is already making these decisions without you.
The goal of renegotiation is structural contract reform — aligning your costs with actual usage and AI-agent deployment plans. Start the conversation 90–120 days before renewal — vendors are most flexible before the deadline creates urgency on your side. For contracts above $100K, start six months out.
What to ask for:
Seat count right-sizing. Document actual active users over the previous 90 days using login and session data. Present the utilisation data and ask for an adjusted seat count. Vendors have limited grounds to push back when the numbers are clear.
Pricing model transition clause. Request a contractual path to usage-based or outcome-based pricing in the next renewal cycle. Forrester is explicit: “SaaS vendor contracts are primarily based on seats. This will shift to consumption and outcome-based pricing as AI agents are deployed.” Reference Gartner’s 40% shift prediction as market context — this is industry direction, not a novel request.
AI agent licensing clarity. Most SaaS contracts assumed human users with individual logins. As you deploy AI agents accessing SaaS systems via API, vendors are increasingly charging per-agent fees or requiring new tiers. Clarify their current policy before you deploy agents at scale. Salesforce’s emerging agentic licensing model is the most prominent early example.
Consumption cap structure. For vendors already on usage-based pricing, negotiate a consumption cap for the first 12 months as a risk hedge. Zendesk’s AI agent pricing dropped from $2,833/month to $1,500/month within a single year due to competitive pressure. Don’t lock in at first-generation pricing.
What not to concede:
Never concede data portability. Multi-year lock-in without an exit clause tied to AI agent licensing changes is a position to hold. Avoid auto-renewal clauses without a minimum 90-day notice window, and don’t accept seat minimums that exceed your projected active user count.
AI-driven price increases typically arrive at 20–37%. Buyers who negotiate reduce vendor asks by approximately 55% in relative terms, landing an average 12% above pre-AI baselines. That delta, across your top-20 vendor list, is meaningful. The specific mechanics of outcome-based pricing are covered in our article on how SaaS pricing is shifting from per-seat to usage and outcome — this section covers the broader contract structure and relationship tactics that go beyond pricing mechanics.
Klarna deployed an AI customer support bot handling the equivalent workload of 700 to 850 employees, replaced Salesforce CRM with an internally-built AI system, and drove revenue per employee from $300K to $1.3M. Then customer satisfaction declined, Klarna reversed course, and CEO Sebastian Siemiatkowski acknowledged publicly that “people were very angry with me” for his earlier claims about AI replacing workers.
Three failures worth studying:
Ticket type matters. AI performs well for Tier 1 transactional support — account status, simple FAQ, basic transactions. It does not match human agents for complex complaints, billing disputes, or emotionally-charged interactions. Separate ticket types before you automate, not after.
Reversal costs are real. Rehiring, retraining, and restoring institutional knowledge rarely appear in the original build-vs-replace business case. Model the reversal scenario before you commit.
Simultaneous consolidation creates failure modes. Phasing your builds would have avoided the cascading dependencies that emerged from doing everything at once. Klarna had 800 engineers to manage that complexity. Most companies at 50–500 employees don’t.
Gartner predicts half of companies that cut customer service staff due to AI will start rehiring by 2027 — Klarna’s reversal is a leading indicator of a broader pattern, not a one-off. The economic logic of consolidation was sound. The pace and sequencing were the problem. Apply the lesson proportionally: one scoped internal tool, piloted in a non-critical workflow, with a fallback position preserved.
The board presentation works best as a reallocation story. Document current SaaS spend from your Phase 1 audit. Model projected savings using conservative assumptions — Tropic‘s negotiation data provides a usable baseline: AI-driven pricing lands around 12% above pre-AI baselines even after negotiation, meaning well-managed renewals generate meaningful savings relative to unmanaged ones. Add tool consolidation in the Open Door quadrant.
The realistic savings range for disciplined execution at 50–500 employee scale: $200K–$500K annually, depending on portfolio size and current sprawl. ClickUp freed $200K in annual automation software subscriptions from a focused internal build effort — the kind of concrete figure that lands well with a CFO.
Three levers to present:
Seat right-sizing. Unused seat removal across the portfolio. Present utilisation data from the audit; vendors resist less when the numbers are clear. Portfolios with genuine sprawl typically carry 15–25% unused or underutilised seats.
Pricing model transition savings. Outcome-based pricing is typically lower than per-seat for AI-augmented workflows. Gartner’s 40% shift prediction provides the external validation that this direction is standard, not experimental.
Tool consolidation. Eliminating redundant Open Door tools reduces both spend and the management overhead of a sprawling vendor portfolio.
The compound benefit: once Claude Code or Cursor-class tools reach your engineering team, development velocity increases — which reduces the cost of building subsequent internal replacements and extends the savings case. For the full strategic context behind why this reallocation opportunity exists now, see our complete overview of the SaaS reckoning.
Days 1–30: Inventory and classify
Pull 12 months of invoiced SaaS spend from finance. Map your top 20 vendors against the Bain Four-Scenario quadrants. Apply Forrester REAP dispositions to each vendor. Create an AI vulnerability score using workflow type, seat utilisation rate, and AI-native alternative availability.
Output: a ranked priority list with Bain quadrant, REAP disposition, and AI vulnerability score for each top-20 vendor by spend.
Days 31–60: Triage and prepare
Identify Tier 1 vendors: Open Door or Battleground quadrant, renewal within 12 months. For each, run the build vs. buy analysis. For renegotiation paths: pull seat utilisation data and draft the renegotiation brief. For build paths: scope the single workflow to pilot with available engineering capacity. Initiate renegotiation conversations immediately if renewals are approaching.
Output: renegotiation brief for each Tier 1 vendor; one pilot build scoped and resourced; Tier 1 vendor conversations opened.
Days 61–90: Execute and track
Complete Tier 1 renegotiations — signed contract amendments or term sheets. Launch the pilot build at minimum viable scope (no more than one concurrent build). Brief finance on projected savings and establish a budget reallocation proposal. Set up monthly SaaS spend tracking: vendor, spend, seats licensed, seats active, AI vulnerability score, next renewal date. Brief the board on the reallocation framing.
Output: signed renegotiation(s), pilot build launched, board brief delivered, ongoing tracking established.
One scope note: align your co-founder, COO, or CFO before beginning vendor renegotiations. Renegotiations that lack internal alignment stall at the wrong moment — and vendors notice when the person across the table doesn’t have full authority to close.
For a broader view of all the dimensions of this challenge — from the market forces driving the shift to the vendor landscape and competitive dynamics — see our comprehensive SaaS reckoning guide.
Selectively and immediately for Open Door category tools, where AI-native alternatives already match core functionality at lower cost. Cautiously and in phases for Battleground tools. Not at all for Core Strongholds. The timing for renegotiation is now regardless of replacement decisions — audit and renegotiate first.
Apply the Bain Four-Scenario Framework: classify each tool by how much AI can automate the core workflow and how much AI has already penetrated the product category. Probabilistic SaaS — content, marketing automation, task management — is more vulnerable than deterministic SaaS like payroll, ERP, compliance, and healthcare records.
REAP stands for Reassess, Extract, Advance, and Prune — built on business fitness and technical fitness dimensions. Use it as the action output layer on top of your Bain classification: Open Door vendors typically get Prune or Extract; Core Strongholds get Extract; Battleground vendors get Reassess or Advance.
Usage-based pricing charges on consumption volume — API calls, tasks completed, messages sent. Outcome-based pricing charges on achieved results — resolved tickets, closed deals, successful transactions. Vendors are mostly in hybrid territory: 65% of SaaS vendors have layered an AI usage meter on top of seat-based pricing, while 35% have bundled AI into per-seat increases. Pure outcome-based pricing is still rare.
Lead with utilisation data — vendors have limited grounds to argue for full seat billing when you can show 40% of licensed seats are inactive. Use AI-native alternatives as genuine BATNA; get real quotes, not theoretical options. Ask directly: “What would a renewal at our current tier and feature set cost?” and document the response.
Never concede data portability rights. Never agree to multi-year lock-in without an exit clause tied to AI agent licensing changes. Avoid auto-renewal clauses without a minimum 90-day notice window. And always negotiate AI data rights explicitly — who owns outputs, training data, and derivative insights generated by AI features.
Yes, for narrowly scoped automation workflows where annual SaaS spend exceeds $100K. No, for anything involving compliance, multi-party regulated integrations, or workflows requiring a vendor’s proprietary data moat. The threshold question is whether you have sustained engineering capacity for maintenance. Initial build is often straightforward. Month 18 is where AI product debt surfaces.
A single developer using AI coding tools can now maintain and ship what previously required three to five FTEs — 51% of builders are shipping production software with AI and about half report saving six or more hours per week. That changes the ongoing maintenance cost calculation. The caveat: 72% of production builders use AI to write discrete pieces of code integrated into larger projects, not prompting their way to complete apps.
AI customer support degraded satisfaction in complex cases, the reversal cost wasn’t factored into the original business case, and consolidating too many apps simultaneously created cascading dependencies. The lesson is not “don’t build” — it is phase your builds, pilot in non-critical workflows first, and preserve fallback positions.
Document projected SaaS savings from renegotiations and consolidations and present AI tooling investment as funded from that savings line. Use Gartner’s 40% pricing model shift prediction as external validation that this is standard industry direction, not an experiment.
Forrester identifies SaaS sprawl as a primary pain point for technology leaders — the accumulation of tools with poor visibility into actual usage, duplicated functionality, and unchallenged auto-renewals. Making the sprawl visible is the prerequisite for all classification and action that follows.
Most SaaS contracts assumed human users with individual logins. As companies deploy AI agents accessing SaaS systems via API, vendors are increasingly charging per-agent fees or requiring new licensing tiers. Salesforce’s emerging agentic licensing model is the most prominent early example. In any renegotiation, clarify the vendor’s current policy on AI agent access before you deploy agents at scale.
AI-Native Startups vs SaaS Incumbents — The Evidence for Who Is Winning the Application LayerEnterprise AI spending went from $1.7 billion in 2023 to $37 billion in 2025. That is a 22x increase in two years, and that is procurement data — not a forecast, not a projection, not venture-funded hype. Businesses bought it.
So the question is not whether AI is reshaping enterprise software. It is who is capturing the spend. The Menlo Ventures 2025 State of Generative AI in the Enterprise report gives you a specific answer: AI-native startups now hold 63% of application-layer market share, up from 36% in 2024. That is the largest single-year share shift in the report’s history.
This article is not going to hand you a verdict. The companies generating these results — Cursor, Harvey, ElevenLabs, Lovable — are structurally different from traditional SaaS, and the Jasper AI collapse is a reminder that “AI-native” is not a guarantee. What follows is the data, the company trajectories, the cautionary cases, and a category map of who the AI-native challengers actually are. This article is part of our comprehensive SaaS reckoning guide, which covers the full landscape from the market dislocation to the practical CTO playbook.
Quick source note before we get into it: Menlo Ventures is a VC firm with an investment interest in AI-native companies. The survey covers about 500 US enterprise decision-makers who have already adopted AI tools — so it skews toward AI-positive outcomes. With that on the table, the scale of these shifts is difficult to pin on sample bias alone.
Enterprise generative AI spend hit $37 billion in 2025, up from $11.5 billion in 2024. AI-native startups took 63% of the application layer. The mechanism driving this is Product-Led Growth: PLG accounts for 27% of all AI application spend, nearly four times the 7% rate in traditional SaaS. Individual users are driving AI adoption at 4x the rate of traditional software purchasing — reaching enterprise budgets before procurement is even involved. AI deals are converting at 47% versus the traditional SaaS pipeline-to-close rate of 25%. Buyers are moving faster because value is demonstrable earlier.
Category-level data sharpens the picture further. AI-native startups hold 78% of the sales software category, 91% of finance and operations, and 71% of product and engineering. Infrastructure-layer incumbents still hold 56% share where reliability and integration depth matter. But at the user-facing application layer, the shift is documented and it is accelerating.
These are the top performers from a broader population that includes plenty of failures. What matters is not just the growth rate — it is the mechanism behind it.
Cursor (Anysphere): $1 billion ARR in fewer than 24 months, around 300 employees, $29.3 billion valuation at Series D. Revenue per employee: approximately $3.3 million. Salesforce generates approximately $800,000 per employee. Cursor competes against GitHub Copilot — backed by Microsoft — and won by shipping repo-level context and multi-file editing before Copilot did, using a model-agnostic architecture that let developers adopt frontier models immediately.
Harvey AI: $100 million ARR as of August 2025, 500+ enterprise customers, $8 billion valuation — up from $3 billion to $5 billion to $8 billion inside a single year. Harvey raised $760 million in 2025 alone, with ARR largely driven by usage as the tool embeds in daily legal workflows.
ElevenLabs: Over $330 million ARR at end of 2025. $500 million Series D in February 2026 at an $11 billion valuation — more than 3x higher than one year earlier. Enterprise customers include Deutsche Telekom, Square, Revolut, and Meta.
Lovable: Unicorn status in 8 months. $200 million Series A at $1.8 billion valuation, 45 employees, approximately $1.7 million ARR per employee. Investors include the founders of Klarna, Slack, and HubSpot — incumbents betting on the challengers.
A note on valuations: SaaStr data from 3,001 primary rounds shows the top 1% of AI startups command 3–10x normal multiples at equivalent ARR stages. Cursor at $29.3 billion sits above even that — valued as critical AI infrastructure, not a SaaS business. These are winner-take-all investor expectations and not all will materialise. But the revenue efficiency ratios are verifiable and do not depend on investor sentiment to be meaningful.
Jasper is worth reading carefully when you are evaluating AI-native vendors — not because it is a representative outcome, but because the failure mode is specific, identifiable in advance, and absolutely not limited to 2022.
Jasper peaked at approximately $90 million ARR and a $1.5 billion valuation in 2022. By 2024, ARR had declined to an estimated $55–88 million range and both co-founders had stepped down.
The failure mode is what Jasper’s case is really about — the wrapper trap. Jasper’s core product was a text generation interface on top of GPT-3 with no proprietary training data, no fine-tuning, and no workflow lock-in. When ChatGPT launched with comparable capability at lower cost, users could replicate Jasper’s functionality by pasting prompts directly into ChatGPT. Differentiation collapsed.
Compare that to the companies in the previous section. Harvey has a proprietary data flywheel from millions of legal documents. Cursor is embedded in the developer’s daily IDE workflow. ElevenLabs has voice model fine-tuning not available through generic APIs. None of them is a thin interface on a commodity model.
When you are evaluating an AI-native vendor, ask yourself this: does this company’s value proposition survive if OpenAI, Anthropic, or Google ships a direct version of this product’s core feature tomorrow? If the answer is yes, the risk profile mirrors Jasper’s. If the answer involves proprietary data, deep workflow integration, or category-specific fine-tuning, you are looking at a structurally different beast.
This is a category map, not a buying guide. Its purpose: identify which parts of your stack have active, well-funded AI-native challengers — and which vendor relationships carry meaningful obsolescence risk. Verify the metrics before you make any decisions; this landscape moves faster than any article can track.
Developer tools: Cursor ($1B ARR, $29.3B valuation, ~300 employees) vs. GitHub Copilot (Microsoft). Lovable ($75M+ ARR, $1.8B valuation, 45 employees) targets a different wedge — non-technical users for no-code app building. Two distinct approaches to the same category.
CRM and sales: 78% AI-native share — the highest documented category displacement. AI-native companies like Clay win by attacking research, personalisation, and enrichment workflows that sit outside the Salesforce data model. DayAI is an AI-native CRM replacement in this category. The incumbent’s defence is Salesforce Agentforce, which we get into in the next section.
Customer support: AI-native tools captured $630 million in enterprise spend in 2025. Decagon and Sierra represent distinct approaches to AI-native customer service. The Klarna case below is the most detailed evidence of what aggressive deployment in this category produces at scale.
ERP and finance: 91% startup share — the highest of any category. Rillet is cited directly in the Menlo report as an AI-first ERP challenger competing against QuickBooks and the broader mid-market ERP category. Campfire and Numeric are additional challengers.
Legal: Harvey AI ($100M ARR, 500+ customers, $8B valuation) vs. established legal software platforms. Legal vertical AI captured $650 million in enterprise spend in 2025, growing from near-zero in 2022.
Salesforce Agentforce is the most directly relevant incumbent AI adaptation for anyone with CRM exposure — because its success or failure has the clearest read-across if you own Salesforce licences.
The data: per analyst estimates from Q3 FY26 results, Agentforce ARR grew approximately +114% to roughly $1.4 billion. Enterprise deals are closing. The caveat: the +114% figure needs context — the base was small, making the percentage notable while the absolute figure remains modest.
The structural challenge is harder to hand-wave away. Agentforce is built on the Salesforce CRM architecture. There are real benefits — existing customer data, enterprise security, the Salesforce ecosystem — but there is also Salesforce’s path dependence. Every architectural decision made before 2020 constrains what it can do today. As Convequity puts it: “Organisational inertia, path dependence, and diluted talent density leave incumbents structurally disadvantaged compared to startups with small, elite teams.”
Microsoft Copilot has the OpenAI partnership and Office 365 distribution at a scale no AI-native startup can match — but Cursor’s growth against GitHub Copilot suggests distribution does not override architectural advantage where specialisation matters.
The honest position: whether “AI features on a pre-AI CRM architecture” can replicate AI-native performance economics is not yet answered. For a complete overview of the SaaS reckoning — including how the broader market dislocation connects to incumbent adaptation — the pillar article in this series covers the full strategic picture.
Klarna is the efficiency case and the cautionary case in enterprise AI adoption — and it is the most thoroughly documented example we have as of early 2026.
The company deployed an AI customer service agent handling the workload of 700–853 agents. Workforce declined approximately 50% through attrition as AI scaled. Revenue per employee grew from approximately $300,000 to $1.3 million — according to Klarna’s own reporting.
Then the reversal. Klarna reported customer satisfaction decline, reversed elements of the strategy, and began rehiring. CEO Sebastian Siemiatkowski acknowledged the overclaim directly: “People were very angry with me for saying that.” Klarna now positions human support as “VIP treatment” — recognising that customers value direct human contact for complex edge cases.
The read-across for anyone not running a global fintech: replacement decisions made without outcome monitoring and a reversal pathway create avoidable risk, regardless of how good the underlying tools are. Klarna had the runway to reverse course. Not every business does.
Both things are true here. The efficiency gains are real. The customer experience degradation at scale is also real.
The evidence does not support a single verdict. Here is what it actually shows.
The market evidence is structural: Enterprise AI spending grew 22x in two years. AI-native startups captured 63% of the application layer. These are procurement decisions, not forecasts. Ignoring this trend is a higher-risk position than engaging with it selectively.
The company-level evidence is structural, not narrative: Cursor’s $3.3 million ARR per employee versus Salesforce’s $800,000 is a business model comparison with direct competitive implications. The mechanism — AI-native architecture enabling different unit economics — matters more than the headline growth rate.
The cautionary evidence is specific and actionable: Jasper AI represents the wrapper trap — thin differentiation plus commodity model dependence — identifiable in advance. Klarna represents replacement risk without outcome monitoring. Both failure modes are specific, not generic.
The incumbent evidence is genuinely unresolved: Salesforce Agentforce has commercial momentum, but whether incumbent architecture can match AI-native performance economics remains open. The evidence as of early 2026 supports neither “incumbents are doomed” nor “incumbents will catch up easily.”
The practical question to ask yourself: in which specific categories of your stack is AI-native architecture producing demonstrably superior outcomes, and which of your current vendors is in a structural position to adapt? The evidence here builds the case for taking that seriously. The Bain four-scenario framework for evaluating vendor survival is in the vendor framework article. The CTO audit playbook is in the downstream article. The broader strategic picture of what CTOs should do in response to the AI-native challenger surge is in the SaaS reckoning overview for this cluster.
What is an AI-native company and how is it different from a SaaS company that adds AI features?
An AI-native company builds its core product architecture around AI from inception. A traditional SaaS company adds AI features on top of existing architecture designed before AI capabilities were available. Cursor vs. GitHub Copilot makes this concrete — Copilot adds AI to GitHub’s existing platform; Cursor was designed from the start as an AI-first development environment. That architectural difference produces structural differences in cost structures, distribution models, and revenue-per-employee ratios. It is not just a branding distinction.
Why are AI-native startups winning market share at the application layer so fast?
Three structural mechanisms. Product-Led Growth — 27% of AI app spend vs. 7% in traditional software — meaning individual users create bottom-up enterprise demand before procurement is involved. Superior unit economics enabling competitive pricing. And AI-native architecture delivering outcomes incumbents cannot match at equivalent cost. PLG is the most counterintuitive one. Users adopt it, it spreads, procurement follows. It is the reverse of how enterprise software has always worked.
Is the AI startup boom real or another bubble?
The enterprise spending data reflects actual procurement decisions — CFOs are not buying $37 billion in AI software speculatively. Market demand is real. Specific valuations contain speculative elements — some will compress. The honest answer distinguishes between “is enterprise AI real?” (yes) and “are all current valuations justified?” (some are not). Both can be true at the same time.
Why does Cursor have a $29 billion valuation with only 300 employees?
$1 billion ARR, $3.3 million revenue per employee, and investor expectations of dominant market share in developer tools. Cursor is valued as critical AI infrastructure — comparable to Databricks at approximately 40x ARR — not a conventional SaaS business. Whether those expectations materialise is a different question.
What happened to Jasper AI and could the same thing happen to other AI startups?
Jasper built a text generation product on top of GPT-3 without proprietary data, fine-tuned models, or workflow lock-in. When ChatGPT launched with comparable capability at lower cost, differentiation collapsed. Peak: approximately $90 million ARR, $1.5 billion valuation in 2022. Decline: estimated $55–88 million ARR in 2024; both co-founders departed. The same risk applies to any company whose core value proposition is entirely deliverable by foundation model improvements. Companies with proprietary data flywheels (Harvey), deep workflow integration (Cursor), or category-specific fine-tuning (ElevenLabs) have a structurally different risk profile.
Is Salesforce Agentforce genuinely competing with AI-native CRM alternatives?
Analyst estimates show Agentforce ARR growth of approximately +114% to roughly $1.4 billion — commercial momentum is real. But Agentforce inherits both the benefits and constraints of Salesforce’s pre-AI architecture. Whether “AI features on existing CRM architecture” can match AI-native CRM performance economics is not yet answered. Keep a close eye on this one.
How should I evaluate whether an AI-native startup will survive long enough to replace my current vendor?
Four signals: proprietary data or model assets — not just API access; depth of workflow integration creating switching costs; ARR trajectory and revenue-per-employee as proxies for durability; and commoditisation risk if foundation model capability improves. Apply the wrapper test: if OpenAI or Anthropic shipped this product’s core feature tomorrow, would the value proposition survive? If it would not, you know what you are dealing with.
Are AI-native startups really better than established SaaS platforms?
It depends on the category. For developer tools, legal AI, and voice AI — the evidence supports AI-native superiority for those specific workflows. For ERP and core financial systems — the evidence for displacement is less developed. Rillet and other ERP challengers are early-stage relative to Harvey or Cursor. “Better” is a category-specific question, not a universal one.
Should I replace my SaaS tools with AI-native alternatives right now?
Not wholesale and not immediately. The Klarna case shows aggressive AI replacement without outcome monitoring creates customer experience risk even when the efficiency gains are real. The evidence-based approach: identify which categories in your stack have AI-native challengers with documented performance advantages, evaluate those tools, and build in outcome monitoring and a reversal pathway before full migration. The methodology is in the stack audit playbook.
What does revenue per employee mean and why does it matter for evaluating AI-native startups?
Revenue per employee is annual recurring revenue divided by full-time headcount. AI-native: Cursor approximately $3.3 million, Lovable approximately $1.7 million. Established SaaS: Salesforce approximately $800,000, most SaaS companies $200,000–$400,000. The gap reflects AI-native architecture enabling automation of work that traditional SaaS companies handle with more headcount. It is a proxy for durability — a company with high revenue per employee can price competitively and survive downturns better than a headcount-heavy incumbent.