Executive brief on replacing traditional ERP with modern AI technologies

The market is moving toward agentic ERP, but not in the sense of overnight abandonment of the transactional core. McKinsey states plainly that AI agents are unlikely to replace ERP in the near-to-medium term because of systemic complexity; Deloitte frames the future as modular, API-driven, agentic ERP, in which rules, structures, and auditable transactions remain in the core while agents become a flexible interface and execution layer. In parallel, Gartner is promoting composable ERP as the architectural foundation for AI-enabled scenarios.

In practice this means four clearly distinct strategies. The first is modernizing a tier-1 suite vendor with clean core and embedded AI. The second is composable ERP: a minimal core plus best-of-breed domain services, APIs, event bus, and AI orchestration. The third is an ontology/knowledge-graph layer over existing systems to unify context and actions. The fourth is AI-native ERP, which today can realistically replace classical ERP in finance-led scenarios but rarely yet covers the full breadth of manufacturing/procurement/supply chain for a complex enterprise.

Two groups of players lead the market. The first are the incumbents turning their suites into AI platforms: SAP, Oracle, Microsoft, Workday. The second are the new AI-native companies such as Campfire, Rillet, and Digits, together with the open-source branch — Odoo, ERPNext, and Apache OFBiz — where AI is added either as a built-in layer or as a governed extension. Reinforcing this is a growing market for orchestration and "operational semantics": Palantir, UiPath, and adjacent platforms are becoming candidates for the upper execution layer over an ERP core. IDC has already carved out a dedicated category — AI-enabled large enterprise ERP applications — which is itself an indicator of the segment's maturity.

The main takeaway for leadership: do not try to "replace ERP with a chat". What needs to be replaced is the old interaction model around ERP and the manual labor tied to it — navigation across transactions, reconciliations, matching, exceptions handling, context hunting, policy Q&A, cross-system coordination, and a significant share of project work during migration. Where legally significant accounting, controlled postings, audit trail, segregation of duties, and reproducibility are required, the transactional core still retains strategic value.

In this edition the brief has been extended with four blocks that are usually missing from the ERP discussion. Section 04 covers the hardware layer of local inference — why open-weight networks and unified-memory platforms made on-prem AI a rational rather than ideological choice. Section 05 covers Russian specifics: the sovereign perimeter, GigaChat and Qwen in place of frontier clouds, life without an official NVIDIA presence, and the fork in the road created by forced migration off SAP. Section 06 covers the impact of vibe coding on build-vs-buy economics and the speed of strangler migrations. Section 09 covers my own practice: how the described patterns have been tested on an internal AI-operated management platform and on a commercial SaaS for retail operations, including a project to build an operational control tower for a large federal retail chain.

By 2026 the market has clearly split into an evolutionary and a disruptive track. The evolutionary track is SAP, Oracle, Microsoft, and Workday: they are not abandoning the ERP paradigm but turning ERP into a platform for data, business context, and agentic execution. SAP has Joule Agents/Joule Studio and AI Foundation; Oracle offers Fusion Agentic Applications and AI Agent Studio embedded directly into Fusion processes; Microsoft is expanding Dynamics 365 and Microsoft 365 Copilot Finance/agents; Workday positions Illuminate and its own governed data layer as the foundation for HR/Finance agents.

The disruptive track is AI-native financial platforms. Rillet explicitly calls itself an AI-native ERP; Campfire uses the same term and builds its stack around an AI-powered general ledger, revenue automation, and close management; Digits calls itself the first AI-native general ledger. The market significance of this wave is that it attacks the most expensive human labor of old ERP: period close, reconciliations, manual revenue-recognition rules, intercompany, and ad hoc reporting. But it is important not to overestimate maturity: based on public descriptions, these platforms are primarily strong in the finance stack, not in full enterprise-wide coverage with heavy manufacturing and logistics scenarios.

The open-source branch has also come alive, but differently. Odoo already documents AI functions and customizable AI agents inside its platform. ERPNext remains a full-fledged open-source ERP with an extensible API layer. Apache OFBiz is especially interesting because its recent AI initiative starts from the principle that "AI in ERP is a governance problem first" and builds a phased Assist / Recommend / Act model that includes schema validation, permission model, approval gates, and a full per-run audit trail. For companies with strong internal engineering culture, this approach can be more attractive than black-box SaaS.

Strategically, analysts and practitioners converge on one point: the new value cycle is not being created around another monolith, but around decomposition, openness, and semantic context. Gartner links AI-enabled ERP to a composable strategy; IDC forecasts that by 2027, 75% of global businesses will begin gradually decoupling monolithic enterprise apps via the strangler pattern; Deloitte describes lean composable core as the target form of agentic ERP. This is no longer a fringe hypothesis but the dominant direction of the market.

Below is the target reference model of modern enterprise automation that, in practice, most often wins over a "full rip-and-replace in one wave" scenario. It combines an auditable transactional core, event-driven integration, data fabric/ontology, a retrieval layer, and an agentic action layer. This approach is most consistent with the logic of SAP business data fabric, Oracle Fusion AI Agent Studio, Microsoft event-driven integration, Palantir Ontology, and Microsoft Research's GraphRAG approach.

Within this model five architectural patterns stand out. AI-augmented suite is the path of SAP/Oracle/Microsoft/Workday: AI is embedded into existing processes and a shared data/security model. Composable modular ERP is an API-first assembly around a lean core. Event-driven microservices are critical for real-time orchestration and decoupling. Ontology / knowledge graph layer ties together business objects, permissions, policies, and actions. AI-native functional replacement substitutes individual domains, most often finance, where transactions are standardized and context is well-typed.

Moving from patterns to technology, LLMs are already the standard interface layer for enterprise software, but they are not a sufficient foundation. Deloitte emphasizes that AI "consumes and computes data; it is not the data itself," so without a system of record, semantics, and rules a manageability ceiling emerges.

RAG and vector DBs are needed wherever an ERP process leans not only on tables but also on documents: policies, contracts, SOPs, supplier letters, procedures, specifications. Microsoft Research has shown that GraphRAG adds graph indexing of entities and community summaries on top of ordinary retrieval, which is particularly useful for private corpora and more general enterprise queries. To build the retrieval layer, the market relies on managed or open-source vector stores such as Qdrant, Milvus, Azure AI Search, and Databricks AI Search.

Agents are becoming the execution layer. Oracle directly embeds multi-agent flows in Fusion; SAP allows building custom agents in Joule Studio; Microsoft delivers AI actions and Copilot extensibility in finance and operations; Workday builds purpose-built finance/HR agents and separately invests in agent verification through Agent Passport. On the open-source side, LangGraph and MLflow are increasingly used as a control plane for long-running, stateful, and observable agentic systems.

MLOps, evaluation, and AutoML are not going away — they are shifting into the infrastructure layer. MLflow's official documentation already covers tracing, evaluation, prompt management, and governance for LLM/agent workloads, while recent MLOps research shows that production discipline maturity remains a bottleneck. In an ERP context this is especially important for forecasting, anomaly detection, policy classification, and continuous monitoring of agent performance. AutoML here is typically useful as an accelerator for specialized models, but not as the main user interface of ERP transformation.

Multimodal models become mandatory as soon as automation touches invoices, packing slips, bank statements, PDF contracts, photographs of documents, forms, and multi-page financial packets. The LongFin and DocLLM studies show that "text only" is no longer sufficient for financial documents; moreover, a recent ACL position paper explicitly notes that enterprise document understanding faces serious gaps in datasets, models, and evaluation. This means any serious AI-ERP target architecture must plan for multimodal ingestion and document QA from the outset.

The debate about ERP replacement almost always tacitly assumes cloud inference. Meanwhile, by 2026 a mature market for local and on-prem inference — running LLMs (in colloquial terms, "a local neural network") on your own hardware — has taken shape, and for the enterprise perimeter it has ceased to be an enthusiast's ideology. There are four drivers. First, data and regulation: transparency obligations under the EU AI Act from August 2026, industry rules, personal data, trade secrets, and air-gapped perimeters in finance, industry, and the public sector. Second, economics at scale: at high document volumes the consumption model of cloud tokens loses to capex; for moderately intensive use a local workstation pays back against cloud APIs in roughly 10–16 months, and under heavy load in a matter of months. Third, latency and autonomy: edge scenarios in the warehouse, in the store, and on the production floor should not depend on an external API. Fourth, predictability: no rate limits, and independence from tariff and vendor-policy changes.

The key shift of 2025–2026 happened not so much in hardware as in models. MoE architectures made large models physically executable locally: models of the Llama 4 Scout class or the new Qwen family activate only ~17 billion parameters per token against hundreds of billions total, while linear attention mechanisms (Gated Delta Networks and similar) bring the inference cost of a huge MoE close to that of a small dense model. In parallel, 4-bit quantization has become effectively "free" — degradation on standard benchmarks is measured in single-digit percentages. The upshot: open-weight models cover the majority of routine enterprise tasks — data extraction, classification, policy QA, matching, summarization — on your own hardware, and the gap versus frontier models remains meaningful only in complex reasoning and long agentic chains.

Two practical nuances of 2026 that are often overlooked in presentations. First, memory has become a scarce resource: the global DRAM/GDDR shortage has driven prices up across the board (even DGX Spark got more expensive, and some vendors have trimmed the top configurations), and it is memory capacity, not FLOPS, that determines which models can even be loaded. Second, compact unified-memory machines are strong on capacity, not bandwidth: decode of a dense 70B model on a desktop workstation is slow, and multi-user production loads require data-center GPUs with an order of magnitude more bandwidth. Hence the working rule: the "box on the desk" is for development, personal agents, and sensitive pilots; production workloads belong on the server tier.

Onto the ERP perimeter this maps to four patterns. First, document pipelines: bulk multimodal processing of invoices, waybills, receipts, and contracts, where the cost per document and the ban on moving data out of the perimeter drive the decision. Second, policy QA and internal copilots over corpora that cannot leave the perimeter. Third, agentic sub-tasks: small local models of 3–9B cover a significant share of the steps of an agentic loop (classification, extraction, routing), while complex reasoning is offloaded to cloud frontier models. Fourth, hybrid routing through a model gateway is becoming a de facto standard and, importantly, part of governance: the policy "which data goes to which model" must be as auditable as access rights in ERP.

In Russia, local inference is not an option for the cautious but the baseline scenario, and the reasons here are tougher than the global average. Access to frontier clouds is complicated legally and operationally: payments, sanctions risk, direct restrictions on cross-border data transfer for entire categories of organizations. The regulatory perimeter is stricter than the market average: Federal Law 152-FZ with personal-data localization, Federal Law 187-FZ and requirements for critical information infrastructure operators, certification of protected environments through FSTEC and FSB, and the domestic software registry as a condition for working with the public sector and state-owned companies. Finally, the very experience of 2022–2024 turned sovereignty from an ideology into a practice: companies that lived through a one-off vendor exit will not deliberately walk into that kind of dependence a second time.

The model landscape has settled into two tracks. The first is national providers: GigaChat (Sber) and YandexGPT (Yandex) with enterprise and on-premise delivery options, joined by models from MTS AI and T-Bank. A notable shift of the past year is the opening of the flagship weights: the latest GigaChat generation — a MoE with hundreds of billions of parameters and several tens of billions active — is compatible with the standard vLLM/SGLang/TensorRT-LLM stack. A "national model" no longer means "closed box," and that has sharply simplified embedding it in your own perimeter. The second track is the open Chinese Qwen and DeepSeek families, which have become the de facto standard for Russian-language open-weight inference: permissive licenses, strong Russian language, economical MoE architecture. The practical conclusion: for document and agentic tasks in a closed perimeter, the quality of open models is already sufficient, and specialized fine-tunes — for example, on Russian law — outperform global frontier models in their niches, since the frontier models tend to slip in norms of foreign jurisdictions.

Hardware is the hardest part. There are no official NVIDIA channels — the market lives on parallel imports with a price premium and extended lead times; the alternative is Chinese accelerators (Huawei Ascend), whose software stack is maturing but demands separate engineering expertise. Working economics for most companies is three-tiered: parallel-imported and used RTX configurations for pilots and small environments; renting GPUs from Russian clouds (Cloud.ru, Yandex Cloud, Selectel, VK Cloud) as an intermediate perimeter with "data in Russia, hardware not ours"; and one's own cluster only for proven, sustained workloads. The shortage of top-tier cards has not stopped adoption — it has made it more inventive: quantization, MoE, and compact SLMs for shop-floor and in-store tasks make it possible to live on modest hardware.

A special layer is the Russian ERP context. After the departure of SAP and Oracle, the market is going through a forced migration whose main beneficiary is the 1C ecosystem. And here a fork arises that I see on transition projects: reproduce the monolith "as it was, only on 1C" — or use the forced migration as a window to move straight to the target architecture from section 03: 1C as a lean system of record, with an API and event layer, semantics, and an agentic layer on top. The second path is not always cheaper in the moment, but it turns forced spending into modernization rather than the preservation of technical debt for another fifteen years. My own background is years of ABAP development, so I know both sides of this transition from the inside: the main risk of pulling out SAP is not functional gaps but the thoughtless carryover of two decades of customizations into a new core.

Hybrid routing in the Russian perimeter is three-loop, not two-loop as in global practice. The local perimeter is for personal data, critical information infrastructure, and trade secrets. Russian clouds with GPUs are for scalable workloads that require "data in Russia." External frontier models are only for anonymized tasks and only through a gateway with DLP filtering. The routing policy thereby ceases to be a technical document and becomes a compliance artifact that lawyers and the security function review on par with the access-rights matrix in ERP.

The term "vibe coding," introduced by Andrej Karpathy in February 2025, has lived through a rapid evolution: a year later the author himself declared it obsolete in favor of agentic engineering — a discipline in which agents do the building while the human is accountable for specification, architecture, and review. Behind the shift in language sit serious numbers: the overwhelming majority of developers already use AI tools daily; Gartner projects that by the end of 2026 around 60% of new code will be AI-generated, and by 2028 up to 40% of new enterprise production software will be created using this technique. For the ERP market this is not a side plot but direct pressure on the economics of all four strategies from section 02.

The main shift is build-vs-buy. The cost of custom development in the outer layer has fallen by a multiple: on boilerplate, integrations, CRUD, and test suites time savings reach 80%, and McKinsey records an average −46% in time on routine tasks and −35% on review cycles. Composable services around a lean core are once again rational to build in-house; the license rent of both suite vendors and niche SaaS is called into question; and the strangler pattern accelerates, because integration layers, connectors, migration scripts, and regression tests are the ideal workload for code generation. This directly supports McKinsey's thesis about the potential halving of ERP-program effort: a significant share of that reduction is precisely agentic development and agentic testing.

The other side is equally well documented. A meaningful share of AI-generated code contains OWASP Top-10-class vulnerabilities; analysis of real pull requests shows a multi-fold increase in serious defects in code with AI co-authorship; teams without governance already spend up to 20–30% of a sprint by the third month on bugs traceable to generated code; Gartner separately warns about an explosion of defects from the citizen-developer "prompt-to-app" approach without quality controls. On top of that comes a new layer of shadow IT: employees build themselves hyper-individualized applications that bypass corporate data policies and become "orphans" after the author leaves.

The management response is symmetrical to the agentic perimeter of section 07 — the same stages and the same gates. Coding agents work in Assist/Recommend modes by default; mandatory review gates and tests as a contract; SAST and license controls in the pipeline; a named owner for every service; and a ban on direct writes by generated code into the transactional core — the clean-core principle applies not only to customizations but to code itself. It is not the fastest generators who win, but those who combined speed with engineering discipline: the market formula of 2026 is "speed plus structure."

Organizationally this redefines the main counterargument against a composable strategy — "we don't have enough people for our own development." Small teams get the leverage of large ones; value shifts from writing code to specification, architecture, review, and ownership of the ontology; hiring shifts from "can write code" to "can bring working software into operation." For ERP programs in 2026 headcount sufficiency has ceased to be a default argument — the argument has become the presence or absence of engineering discipline around agents.

For an ERP replacement program, the best practical principle is coexistence before decommissioning. IDC forecasts that by 2027, 75% of global businesses will begin incrementally decoupling monolithic applications through the strangler pattern. McKinsey also writes that the transformation will not happen overnight and that a hybrid approach makes it possible to capture value while preserving a cleaner core. This is consistent with the lessons of failed programs: the biggest risks arise when organizations do too much too fast without redesign, testing, and business change.

The practical migration stack consists of five layers. The first is process fit-to-standard and clean core. The second is data remediation and canonical business objects. The third is API/event integration for coexistence and gradual strangling of the old core. The fourth is AI copilots and agents in low-risk Assist/Recommend modes. The fifth is controlled actioning with approval gates, SoD, and journaling. SAP community and architecture materials on clean core and event-driven integration, Oracle migration guidance and workshops on ERP business events, and Microsoft Dataverse/business events all point at roughly the same logic.

On governance and security the minimum baseline is already clear. At the level of external frameworks — NIST AI RMF, ISO/IEC 42001, and the requirements of the EU AI Act. The European Commission indicates that the prohibitions and AI literacy obligations apply from 2 February 2025, obligations for GPAI from 2 August 2025, transparency rules from August 2026, and part of the high-risk rules in 2027–2028. For enterprise automation this means that deployer organizations must set up in advance an inventory of AI systems, supplier controls, transparency, human oversight, and documented risk classification.

At the platform level, requirements converge around the same controls: roles and permissions, isolation of knowledge sources, tool allowlists, logging of prompt/tool/action, validation before write operations, human approval for irreversible actions, and continuous runtime monitoring. Microsoft describes security and governance controls in Copilot Studio; SAP runs an AI ethics impact assessment on each use case; Oracle emphasizes shared security, data governance, and business context in Fusion AI; Workday introduces Agent Passport as a separate test/verify/monitor loop; Apache OFBiz makes the same ideas explicit in an open-source form.

From a management perspective, the most effective scheme is to split use cases into three classes: Assist without writes, Recommend with a human decision, and Act only for low-risk actions and only after passing enterprise guardrails. This step-wise approach best reduces resistance from audit, internal controls, and legal, and enables faster measurable value.

The economics of ERP replacement have changed but not become simpler. McKinsey notes that large enterprises typically spend on ERP migration between $100 million and $1 billion, with one-off implementation cost often a multiple of subscription cost; for a transformation scenario, the payback period is often 4–5 years. At the same time McKinsey believes AI agents can cut ERP implementation effort by at least 50% and halve program duration, though this is still a direction rather than a universally proven standard.

The structure of TCO is shifting as well. Classical ERP created a cost base through licenses, integrators, upgrades, and business support. The new AI layer adds consumption economics: LLM tokens, retrieval/vector search, model monitoring, safety evaluation, and new governance spend. For Microsoft part of the AI has a public seat-based model; for LLM/API and vector search, cost is more often tied to usage, capacity, or DBU/tokens. This makes cost forecasting look more like cloud observability/compute than traditional perpetual ERP budgeting.

The best publicly observable results today are not tied to a mythical "ERP is gone" but to concrete, measurable areas. The strongest enterprise reference is UiPath + Deloitte + SAP S/4HANA: the company reported 93% clean core, 60% test-case automation, and more than 85% of critical financial workflows executed by unattended automation. This is an important signal: AI and automation are already changing the economics of ERP transformation and post-go-live operations.

A good incremental example is U.S. Venture / U.S. AutoForce on Microsoft. The company replaced an aging on-prem ERP, rolled out Dynamics 365 and later Copilot for Finance; setting up Copilot took four weeks, the team gains more than 30 hours of savings per month, and one bank reconciliation process was cut by roughly 80% in time. This illustrates the most pragmatic 2026 scenario: not a total replacement but a fast reduction of manual load on an already modernized core.

On the AI-native side, Campfire and Rillet show that finance-led companies can move faster. Campfire publishes cases with close reduced by 4+ days and 80+ hours saved per month, along with migration-from-NetSuite stories that eliminate middleware cost through direct API integration. Rillet describes over 500 teams and a typical outcome of "the month closes in days, not weeks." These examples should be treated as convincing for the mid-market digital-native segment, but not as direct proof of readiness to replace a large cross-domain ERP across all industries.

More radical results are also appearing in research. The FinRobot paper describes its architecture as the first AI-native agent-based framework for ERP in finance and reports up to 40% reduction in processing time and 94% reduction in errors on representative workflows. But for now this should be treated as a strong research indicator of direction rather than market-wide production proof.

Examples of failures are equally instructive. The Birmingham City Council officially acknowledged the need for a strategic reimplementation of Oracle Fusion after a failed implementation; its own cabinet report cites flawed configuration, lack of process redesign, insufficient testing, and insufficient change management. Tennant Company in an SEC filing described how the go-live of a new ERP triggered order-management disruptions, manufacturing scheduling issues, and reduced inventory visibility; the company estimated the negative effect at roughly $30 million in net sales and about $22 million in adjusted EBITDA. This is not an argument against modernization, but against hasty modernization without project discipline.

On timelines the market is accelerating but remains two-speed. Gartner projects that by 2026 up to 40% of enterprise applications will have embedded task-specific AI agents; IDC expects that by 2026, 40% of G2000 will use enterprise app vendors' tools to build customized GenAI capabilities grounded in their data, and by late 2026, 65% of organizations will be using AI assistants/advisors/agents for immediate business value. By 2027 IDC expects broad strangler decoupling, while Gartner warns about the risk of agent sprawl by 2028. The 2026–2028 window is therefore not the "end of ERP" window but the window of active transition to an AI-operated enterprise stack.

The conclusions of this brief are not armchair ones for me. A significant share of the described patterns has been tested on two systems that I design and develop: an internal AI-operated company-management platform (Orion) and a commercial SaaS for managing retail operations (MD Audit). Below is what has held up in practice — and what turned out tougher than analyst reports suggest. I deliberately do not name clients.

Orion is built exactly along the logic of section 03, but at mid-market scale. Systems of record — CRM, task tracker, repositories, the finance and HR perimeters — were not replaced by anyone: they remain sources of truth. On top of them, three layers are assembled. The first is an MCP layer of roughly two hundred tools as a unified API/action layer to all systems. The second is a semantic layer: a knowledge base plus an ALM metamodel of 34 business-object types and 22 relationship types (goals, KPIs, initiatives, capabilities, risks, architectural artifacts) that ties strategy to execution — essentially the same ontology-first approach the market discusses in relation to Palantir, implemented without a rack-scale budget. The third is an agentic layer: specialized agents (financial pulse, portfolio success manager, technical writer, presales analyst) with an explicit capability model — each agent has a tool allowlist and a permission perimeter over resources.

The key design decision turned out to be the propose pattern: an agent does not create a task, goal, or link in the models directly — it proposes, and a human approves in a review interface; runs are logged, and result artifacts are persisted. This is exactly the Recommend stage from section 07, and it is what removed the main resistance to adoption: the business trusts agents exactly to the extent that their actions are transparent and reversible. The finance perimeter confirms the same logic from the other side: budget versions, plan vs. actual, a 13-week cash forecast, and SaaS metrics — the agent reads them, explains them, and highlights anomalies, while decisions stay with people.

MD Audit is an example of how the same trends work outside classical ERP. The store-operations category is structured like an "ERP for retail operations": the flow of audits, checklists, findings, and tasks is a transactional core on top of which intelligence is built. The most illustrative project is an operational control tower for a large federal non-food chain (over a thousand stores). On top of the flow of inspections, a single management perimeter is assembled: a KPI panel (overdue tasks, share of closed items, recurrence of findings), a "management blocks × operational subsystems" gap map, an organizational maturity matrix, and segment cuts by division. Critical here was a data-integrity layer: automatic detection of geo-fraud (when an "on-site check" was performed away from the site) and duplicated photo evidence. A practical conclusion not found in most analyst reports: before giving agents the right to act, one must first prove that the data they lean on is honest — the integrity layer turned out to be the precondition for any autonomy. The economics of the effect are of the same kind as in the public cases of section 08: manual coordination load has been removed from regional management, while no system of record has been replaced.

The overall conclusion from practice matches the main thesis of the brief: what wins is not "replacing ERP with a chat" but redesigning the operating model — lean core, semantic layer, agentic interface, and strict gates. The only difference is scale: for a mid-market business this stack today is assembled in months, not years, and that is what makes the 2026–2028 window a window for action, not observation.

Given the current state of the market, the recommended shortlist is best framed not as a single list of "best ERPs" but as a set of target architectures for different contexts. Below is a practical shortlist for a general corporate assessment without ties to industry and company size.

Selection criteria should be formalized as a scorecard of eight blocks: process fit, data model and semantics, API/event maturity, agent governance, migration path, ecosystem and SI availability, TCO transparency, regulatory readiness. At the board level the most discriminating criteria are usually not "who has the better LLM," but: can clean core be sustained, how are approval gates implemented, how open is the platform to non-vendor agents, and can P&L impact be measured use case by use case. These are exactly the points McKinsey, Deloitte, and the Gartner-oriented composable ERP agenda are focused on today.

The recommended roadmap below assumes a conservative but fast program with a notional start on 1 September 2026. It assumes the company does not know in advance which layer will end up "winning" and therefore first builds a governed architecture rather than betting on a single product. This approach is most consistent with Deloitte's phased adoption model, IDC's strangler pattern, and the lessons of public successes and failures.

The final recommendation is as follows. For a large company without a predetermined industry context, the most sensible choice is not an "ERP replacement program" but an "enterprise operating model modernization program". Its aims should be: a lean auditable core, composable domain services, event-driven integration, a governed semantic layer, and an agentic interface to work. If the company is digital-native and finance-heavy, AI-native ERP can already today be considered as the main replacement candidate. If the company is large, multi-geographical, and regulated, the main bet should be on modernizing the core plus aggressive automation around the core. This is the most reliable way to capture the value of AI without losing manageability, auditability, and the ability to scale.