Custom ERP vs Off-the-Shelf: When to Build, Buy or Extend

Most advice on custom ERP versus off-the-shelf is written for a company choosing its first system. A large enterprise starts somewhere else. It already runs SAP, Oracle or Microsoft Dynamics, often several instances, wrapped in two decades of custom code, interfaces and spreadsheets that hold the real process. The live question is which capabilities belong in the standard suite, which deserve software of your own, and where that software should sit so the next upgrade does not break it.

• 54%of 198 German-speaking SAP user companies still used SAP ECC or the older Business Suite, in a 2026 survey¹
• 70%+of recently implemented ERP initiatives Gartner expects to miss their original business case goals by 2027²
• 35%of 817 builders Retool surveyed had already replaced at least one SaaS tool with a custom build³

Custom ERP vs off-the-shelf: the three real options

An enterprise has three options for any capability its ERP touches: buy and configure a standard suite, build a custom system of record, or keep the suite's core standard and build what differentiates you around it. The choice is made capability by capability, and most large estates end up using all three. General ledger, payables and payroll are rarely where a company wins. A pricing engine, a production scheduler or a settlement process often is.

Why the ERP decision is live in 2026

The decision is live because SAP's mainstream maintenance for the Business Suite 7 core applications, which include SAP ECC, ends at the end of 2027, and every move off them forces a verdict on the custom code built up around them.⁴ Oracle E-Business Suite customers have no such clock, so their case has to stand on value alone.⁶

The installed base shows the pressure. In the 2026 investment survey of DSAG, the German-speaking SAP user group, 54% of 198 member companies still used SAP ECC or the older Business Suite, down from 68% in 2024 (companies could name more than one system).¹ Each of those migrations asks the question this guide answers for every custom object in the old system: carry it forward, rebuild it beside the new core, or retire it.

Customization vs configuration: why changes to the core block upgrades

Configuration uses settings the vendor builds and tests, so upgrades carry it forward; customization adds or changes code, and only code that stays outside the vendor's own survives upgrades cleanly. Microsoft enforces that line in the product: it removed overlayering, the modification of its own code, from Dynamics 365 finance and operations apps. Extensions are the only customization framework, because frequent cloud updates need a customization model that updates are less likely to break.⁷

SAP makes the same argument in its clean core guidance: custom code, undocumented changes and hard-to-maintain integrations limit flexibility, slow down upgrades and increase total cost of ownership.⁸ In 2025 SAP introduced four extensibility levels that grade each extension by how upgrade-safe it is.⁸

When to buy and configure a standard ERP

Buy and configure when the process is one your industry already agrees on and the suite can represent your entities without modification. For finance, procurement, HR and payroll at most enterprises, that holds, and the suite brings work you would otherwise build and audit yourself: statutory reporting, tax and e-invoicing changes, segregation of duties, and a controls framework your auditors already know.

• The main complaint about the current system is its interface or its reports. Both can be fixed beside the core without touching it.
• The process is standard but undocumented. Document it first; the suite often supports more of it than the team assumes.
• The capability carries regulatory change you do not want to own, such as tax, payroll or statutory reporting.

When a custom ERP is worth building

Build a custom system of record only when the process is the reason customers choose you and no suite can model it without modification. At enterprise scale that means one domain built as a system you own, such as a pricing engine, a production scheduler, a claims or settlement ledger, or a trading book, posting its results to the standard ledger.

• The process is the differentiator. Moving how you price, schedule or fulfill onto a vendor's model gives away the advantage.
• The workarounds have become the system. When the real logic lives in spreadsheets, macros and one person's memory, you already run custom software, undocumented and unsupported.
• The suite cannot represent your entity model: unusual units of measure, shared ownership across parties, event-driven pricing, or volumes the standard objects were never designed for.
• Integration is most of the project anyway. If connecting a product to your estate costs close to building the capability, you would pay for both.

Two conditions come first: a named business owner with time for decisions every week, for the life of the system, and acceptance that every regulatory change in that domain is now your own funded work.

When to extend: keep the core clean and build around it

Extend when a process is standard at its core and differentiated at its edges, which is the usual case in a large company. The ledger, the material master and purchase-to-pay stay in the suite, configured and upgradeable. What sets you apart runs beside it in software you own, reading and writing through the vendor's released APIs and events. SAP recommends a BTP-first approach when deciding where such an extension should run.⁸

• Side-by-side applications Applications for work the suite handles poorly, such as field service scheduling or a dealer portal, calling the ERP through released APIs and keeping their own state.
• Event-driven integration The ERP publishes business events, such as an order released or a goods receipt posted, and your services react to them. Nothing polls tables or writes into them.
• A service layer you own A thin set of your own APIs over the ERP that hides vendor-specific objects from the rest of the estate, so the next migration changes one layer instead of every consumer.
• Agents over the ERP AI agents that read and act on ERP data through governed APIs or MCP servers, under a role you define and with approval for irreversible postings.

This is where custom software development belongs in an enterprise estate, and it is where we start: every custom object in the current system is mapped to one of the three paths before anyone writes new code.

Which path fits: the signals for each

The path follows from six questions asked of each capability: how it wins, what it must model, how fast it changes, what it touches, who owns it and what the vendor will ship.

Five-year total cost of ownership: the eight lines to compare

Compare the three paths over the same five years, scope and eight cost lines, with your own people's time counted in every one. The business case is where ERP programs most often disappoint: Gartner expects more than 70% of recently implemented ERP initiatives to fall short of their original business case goals by 2027, and points to weak executive commitment and underestimated organizational change as the usual causes.²

five_year_tco(path) = sum over years 1..5 of
    licenses + implementation + customization_debt + upgrades
  + integration + data_migration + run_and_support + change

customization_debt(year) = custom objects touched by that year's upgrades
                           × (refit effort + retest effort per object)

Watch the new usage metrics: Microsoft bills tool calls to its Dynamics 365 ERP MCP server from agents built outside its own agent platform in credits per call.¹¹ Then run two checks. Recompute each path with benefits halved and effort doubled, the stress test in How to Calculate AI ROI. And price the exit: what leaving each path would cost in year six, data and code included.

How AI-assisted coding changes build economics

AI coding tools have cut the cost of writing software, so building around the ERP is cheaper than it was; specifying, migrating, certifying and running a system of record cost what they always did. In a survey of 817 Retool customers and builders published in February 2026, 35% had already replaced at least one SaaS tool with a custom build and 78% expected to build more in 2026.³ The sample already builds software for a living, and the tools replaced most often were workflow automations and internal admin tools: the edges of the estate, where extension lives.

The core is a different matter. Gartner predicts that more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits because buyers overestimate what generative AI tooling can do with complex legacy code.¹⁰ An ERP core holds the same kind of accumulated logic. So the bar for extending has fallen: a portal, an approval flow or a planning screen can be built beside the core and kept current by a small team. The bar for replacing the core has not moved.

How AI agents change the ERP interface

AI agents are becoming a new kind of ERP user, and the vendors now ship the interface for them: MCP servers that expose the suite's data and business logic to agents under a security role. Microsoft's Dynamics 365 ERP MCP server gives agents data, form and action tools, filtered by the security role assigned to the agent, and builds its context from the environment's configuration and extensions, so extensions made the supported way reach agents automatically.¹¹ Its earlier static version retires on October 1, 2026.¹¹

SAP uses MCP to give its own agents access to SAP business capabilities, offers an MCP gateway in SAP Integration Suite that exposes APIs as agent tools, and prefers the A2A protocol for agents from other vendors.¹² DSAG notes that in highly customized systems, AI innovations have so far been usable only to a limited extent.¹ Three consequences follow:

1. A clean core pays twice. The extensions that survive upgrades are the same ones agents can reach through the vendor's interface.
2. An agent's authority is an ERP role. Design it with the same segregation of duties as any user, give each agent its own identity, and hold irreversible postings for approval.
3. A custom system of record needs its own agent interface, which is one more thing to build, secure and keep current. MCP and A2A in the Enterprise covers the protocols.

Plan data migration as its own workstream

Data migration needs its own owner, plan and sign-off, because it runs on a different critical path from the build: it depends on the business cleaning its own data. Every path needs it, including extend, which still moves the core and often splits data out to the services around it. When the council described above re-planned its implementation, its auditor singled out a data migration strategy covering phased loads, verification, reconciliation and sign-off as good practice.⁹

1. 1Decide what moves Open items, balances and master data move. Closed history usually goes to a queryable archive, which shrinks both the migration and the new system.
2. 2Profile and cleanse Measure duplicates, gaps and orphaned records in the source, and have the business owners fix them there before the first load.
3. 3Map and transform Map every field to the target model with rules the data owner signs off, and version the mapping like code.
4. 4Rehearse Run full, timed trial loads into a copy of production until the load fits the cutover window with time to spare.
5. 5Reconcile Agree the reconciliation rules in advance: record counts, control totals, open balances by account and entity. Finance signs off the result.
6. 6Cut over and keep the archive Freeze, load, reconcile, go live, and keep the legacy data read-only for as long as retention and audit rules require.

Red flags for each path

Each path fails in a recognizable way, and the warning signs show before the budget is committed.

Keep the core standard where your industry agrees, extend where you differ at the edges, and build only where the process itself is the product. Decide it capability by capability, on a five-year view that counts the debt, and the platform question that follows gets easier.