Nobody should pick an ERP from a three-row table. But most organisations can tell within seconds which row describes them, and knowing your starting position makes the rest of this article faster to read. Score the five factors before you commit to anything, particularly if two rows both feel partly true.
| If this is you | Default answer |
|---|---|
| Standard processes, many legal entities, several countries, no product team | SAP. Statutory localisation across jurisdictions is maintained for you, and that alone usually outweighs everything else. Budget for the licence line to grow every year and keep your core clean so upgrades stay routine. |
| Unusual operating model, changes often, no package fits without heavy modification | Custom build. You would be paying for custom software either way, just inside someone else’s licensing model. Only proceed if you can fund a permanent product team, not a one-off project. |
| Standard finance, but one or two workflows are your actual differentiator | Hybrid or two-tier. SAP as the system of record, custom software at the differentiated edge. Works only if one owner is accountable for the integration layer and the master data model. |
Most writing on this question comes from someone selling one of the two answers. This comes from a custom development firm, so read the case for SAP first. If it holds up for you, the rest is academic.
What Is the Difference Between SAP and a Custom ERP?
SAP is off-the-shelf software, or COTS in vendor documents: you buy a system that already encodes standard business processes and configure it to fit. A custom ERP, or bespoke ERP software, is written for one company against its own requirements. You own the code, the roadmap and the maintenance bill. Panorama Consulting puts SAP S/4HANA, Oracle Fusion Cloud and Infor CloudSuite in Tier I, aimed at enterprises above $750 million in revenue.
It is not a binary. Most enterprises sit somewhere between stock configuration and a full build, and most got there by accident.
Why the SAP ECC 2027 Deadline Is Forcing This Decision Now
SAP set a deadline and most of its customers have not met it. Mainstream maintenance for ECC 6.0 ends in 2027, with extended maintenance to the end of 2030 at a 2% premium. Gartner has estimated that more than 60% of SAP customers are still on ECC6 on-premises with no migration decision made.
A forced migration is the one moment a CFO will reconsider the platform instead of defending money already spent. SAP has added a private-edition transition option covering 2031 to 2033 for large complex customers, and providers such as Rimini Street will support ECC past SAP’s own dates. Either way, staying on ECC buys runway rather than a destination.
Four options are genuinely on the table. Brownfield conversion is fastest and carries your technical debt across. Greenfield rebuilds processes: cleanest result, hardest project. Selective transition moves some entities and rebuilds the rest. The fourth is reconsidering the platform, and nobody sells you that one.
ERP Selection Criteria: Five Factors That Decide SAP vs Custom
Feature checklists are a bad way to choose, because most platforms tick most boxes in a demo. What separates a good decision from an expensive one is an honest read on five things about your own organisation.
1. Process Differentiation
Ask whether a customer would notice if you ran a process exactly like your closest competitor. Order-to-cash in distribution, usually not. Production scheduling in a made-to-order shop, often yes. There are fewer genuinely differentiated processes than the operations team believes.
2. Regulatory Footprint
Count your legal entities, tax jurisdictions, and how often the rules change. SAP maintains statutory localisation across dozens of countries as part of the product. Building that yourself is a permanent compliance function, not a project. Past three or four jurisdictions this often settles the question alone.
3. Internal Engineering Capacity
Can you staff a permanent product team, or only a project team? A custom ERP never finishes. Companies that can fund a project but not a team should not build, and it is the most predictable reason custom programmes fail.
4. Time-to-Value Pressure
A 2027 cliff, a carve-out, a merger. Packaged software gets you to a working system faster. Custom gets you to the right system faster, which only helps if you have the time.
5. Cost Horizon
Year one or year seven? Licensing is cheaper at signature and dearer every year after. Development is the reverse.
Score each option 1 to 5 on how well it fits, then weight. The arithmetic matters less than the argument you have while doing it.
The ERP Decision Matrix, Scored
Here it is worked through for the manufacturer used in the cost model below: $300 million revenue, three countries, five legal entities, no in-house product team, and a 2027 deadline. Production scheduling is genuinely differentiated, everything else is standard.
| Factor | Weight | SAP | Custom | SAP weighted | Custom weighted |
|---|---|---|---|---|---|
| Process differentiation | 25% | 2 | 4 | 0.50 | 1.00 |
| Regulatory footprint | 25% | 5 | 2 | 1.25 | 0.50 |
| Engineering capacity | 20% | 4 | 2 | 0.80 | 0.40 |
| Time pressure | 15% | 5 | 2 | 0.75 | 0.30 |
| Cost horizon | 15% | 3 | 4 | 0.45 | 0.60 |
| Total | 100% | 3.75 | 2.80 |
SAP wins by 25%, which is well outside the margin where the answer is ambiguous. Three countries and no permanent engineers decide it, and no amount of enthusiasm about the scheduling problem should override that.
Read the rows rather than the total, though. Custom scored double on the one factor where this business is actually different. That points at running SAP as the system of record and building the scheduling piece alongside it, which is the hybrid pattern described further down.
Adjust the weights before you score. A single-country manufacturer should not be running 25% on regulatory footprint. A twelve-country group should. If the totals finish within about 10% of each other, neither pure option fits.
When SAP Is the Right Choice, and When To Weigh SAP Alternatives
SAP wins more often than a custom development firm likes to admit.
Buy it if you file statutory reports in several countries and want that maintained for you. Buy it if auditors, insurers and acquirers need to recognise the system, which is not a technical argument but shortens diligence anyway. Buy it if you cannot keep engineers on payroll permanently. Buy it if you need the hiring pool: recruiting an SAP FI consultant is a solved problem, while recruiting someone who understands your bespoke platform means finding the three people who built it. And buy it if your processes look like everyone else’s, because then the pre-configured version is free process design rather than a compromise.
The complaints people make about SAP are often self-inflicted. Overruns and rigidity usually trace back to buying a standard system and then insisting it behave like the old one.
When Does a Custom ERP Make More Sense Than Buying?
Building earns its cost in a narrower set of situations than most development firms will admit.
It makes sense when every shortlisted product needs heavy modification to work at all, because then you are paying for custom software development regardless, inside someone else’s licensing model. It makes sense when the differentiated workflow changes every quarter, since each revision in a packaged system is a change request and a regression cycle. It makes sense when you already run a product organisation, or when per-seat pricing that worked at 200 users has become the largest line in the IT budget at 5,000.
The disqualifiers matter more than the reasons. No named product owner. No maintenance budget past go-live. No tolerance for eighteen months of running less functionality than the system you replaced. A board that treats software as a capital project with an end date. Any one of those turns a custom ERP development into an expensive rewrite of what you already had.
SAP Clean Core: Why ERP Customization Gets Expensive
Changes made inside the standard SAP core have to be retested and often rewritten every time SAP ships an upgrade. Clean core is SAP’s principle for avoiding that: keep your changes outside the standard objects and upgrades stay routine.
| Approach | What it means | Upgrade impact | Long-run cost |
|---|---|---|---|
| Configuration | Setting parameters the product already exposes | None | Low |
| In-core modification | Changing standard objects and code | Rework at every upgrade | High and compounding |
| Side-by-side extension | Building on SAP BTP via released APIs | Minimal | Moderate and predictable |
Buyers confuse the first two constantly during selection. Configuration uses what the vendor built, customisation changes it. Demos show the first and implementations discover the second.
Once you are extending heavily on BTP you already have a development team, a release process and custom software to maintain. The gap between that and a custom build is narrower than the licence invoice suggests. Panorama’s 2026 ERP Report shows how organisations get there without meaning to: among those that went over budget, the most common cause was an unexpected need for additional technology, which the report traces to fatal misfits found late, leading to scope expansion and custom builds. If you will maintain custom software either way, compare which architecture leaves you able to upgrade.
ERP Implementation Cost and Total Cost of Ownership Over Five Years
More than either proposal shows. Implementation is typically 50% to 70% of first-year spend once you add integrator fees, data migration, training and change management. Licensing is only 20% to 30%.
The model assumes a $300 million manufacturer, 400 ERP users, five legal entities, three countries and six to ten integrations. SAP is costed as S/4HANA Private Cloud under RISE, custom as a blended onshore and offshore build. Change the profile and every number moves.
RISE prices in Full Use Equivalents, not headcount. One FUE equals one advanced user, five core users, or thirty self-service users. Split 400 people into 60 advanced, 240 core and 100 self-service and you get about 111 FUEs, or $187,000 to $294,000 a year at the $140 to $220 per FUE per month benchmark. Your user mix moves this bill more than your user count does.
| Cost category | SAP (5 years) | Custom (5 years) | Notes |
|---|---|---|---|
| Licence / subscription | $1.0M – $1.56M | none | ~111 FUE at $140-$220/month, 3% escalation |
| Initial development | none | $600K – $1.6M | Offshore-weighted teams sit at the bottom |
| Implementation / rollout | $350K – $900K | $80K – $250K | SI fees are 40-60% of SAP implementation, at $150-$350/hr in North America |
| Integration | $80K – $400K | $80K – $400K | $10K-$50K per interface, identical either way |
| Data migration | $50K – $200K | $50K – $200K | Driven by your data quality, not the platform |
| Training | $60K – $180K | $30K – $90K | More surface area to learn on SAP |
| Change management | $75K – $250K | $50K – $150K | Lower for custom, process change is smaller |
| Infrastructure | $55K – $110K | $50K – $260K | RISE bundles it. BTP credits are 1% of net ACV, floor €10K, cap €20K/yr |
| Maintenance and support | included in RISE | $360K – $1.28M | The 22% figure is on-premise perpetual only. Custom runs 15-25% of build cost a year |
| Internal headcount | $400K – $900K | $250K – $600K | SAP needs functional owners. For custom the dev team is the line above |
| Upgrades | $100K – $400K | none | Scales with how clean your core is |
| Roadmap / change requests | none | $150K – $500K | Year-one change requests run 25-40% of build cost |
| Subtotal | $2.17M – $4.90M | $1.70M – $5.33M | |
| With 20% contingency | $2.60M – $5.88M | $2.04M – $6.40M | Hidden costs add 15-30%, half of projects exceed budget |
The two ranges sit almost on top of each other. Anyone telling you custom is dramatically cheaper, or that SAP is the safer financial bet, is selling something. What differs is the shape. SAP front-loads implementation then bills a licence line indefinitely, so the cost never stops and never drops. Custom front-loads development then converts to a run-rate you control and can cut in a bad year.
Integration, data migration and testing cost the same either way. If a proposal shows those cheaper on one side, they have been scoped out rather than solved. To sanity-check a quote: implementation lands at 1x to 3x your first-year software fee, five-year cost at 3x to 5x the licence fee, roughly $7,200 per user.
How To Measure ERP ROI Honestly
Panorama found efficiency benefits reliably materialise while operating-model benefits rarely do. Baseline days-to-close and order-to-cash before you start, because you cannot claim an improvement you never measured.
SAP Implementation Timeline Compared With a Custom Build
Panorama’s 2026 report, covering 170 organisations with median revenue of $200.5 million, found a median project timeline of nine months. SAP sits above that median once several entities and countries are in scope.
| Phase | SAP | Custom |
|---|---|---|
| Selection and business case | 3-4 months | 3-4 months |
| Design | 2-3 months (fit-gap) | 3-5 months (full process and data design) |
| Build or configure | 4-8 months | 6-12 months |
| Testing and UAT | 2-4 months | 2-4 months |
| Total to first go-live | 9-18 months (12-24 private cloud or brownfield) | 12-24 months |
| Time to change a process afterwards | 4-12 weeks | 1-4 weeks |
Phases overlap, so the totals are shorter than the column adds up to. SAP reaches a working system sooner. A custom platform reaches your working system sooner.
SAP Implementation Timeline Compared With a Custom Build
Outright failure is rarer than the folklore suggests, but overruns are routine. Panorama found more than a quarter of organisations over budget and almost a quarter over schedule, and neither leading cause was technical. Budget overruns came mostly from unexpected technology needs, which is a selection failure showing up as a cost failure. Schedule overruns came from governance and delayed sign-offs. Fewer than a quarter reported an intense focus on change management.
Public figures on what failure costs are rare because most companies do not disclose. Tennant Company did. On its Q4 2025 earnings call the manufacturer reported that a November go-live in North America cost roughly three weeks of order entry and parts shipping, put the hit at about $30 million in Q4 sales and $22 million in adjusted EBITDA, and paused the planned EMEA rollout. It had spent roughly $98 million on the programme since 2023.
ERP Vendor Lock-In and the Risks That Differ by Path
That was a cutover failure, not a platform choice, and the same risk sits on both sides of this decision. Where the risks genuinely differ: SAP concentrates lock-in and renegotiation leverage with the vendor, while custom concentrates key-person risk on the team who built it and puts compliance maintenance permanently on you.
Two-Tier ERP: The Hybrid Most Enterprises Actually Choose
Two-tier ERP runs a Tier I system such as SAP at corporate level for consolidation and statutory reporting, while subsidiaries or specific business units run lighter or custom systems connected by APIs.
It works when a group contains genuinely different businesses. A manufacturing parent and a services subsidiary do not need the same ERP, and forcing one on both usually produces a system neither uses properly. It also helps when acquisitions arrive with their own systems and immediate migration would destroy value.
It fails when nobody owns the integration layer, or when the split follows political lines rather than operational ones. Done well, two-tier has one master data model and one owner for integration. Done badly, two finance teams reconcile two versions of the truth.
ERP Vendor Selection: How To Run the Evaluation and the RFP
Twelve to sixteen weeks is realistic, with named owners and fixed timeboxes.
- Baseline what you run today: processes, integrations, data quality and actual spend.
- Split must-have from nice-to-have before you see a single demo.
- Score the five factors with the executive sponsor in the room. Half a day, and it will be contentious.
- Issue the RFP with the custom option included as a formal alternative, even if you expect to buy.
- Run scripted demos, same script and data for every vendor, never vendor-led.
- Model five years of cost using the vendors’ own numbers, then reference-check on delivery rather than sales.
Four questions worth putting in the RFP in writing. What is the total five-year cost including licences, implementation, support and infrastructure? Which requirements are met by configuration, and which need custom development? What are the exit terms, and in what format do we get our data back? And what proportion of your implementations in the last two years went live on the original date and budget? The last one changes the conversation.