Custom ERP vs SAP: what actually decides it for a mid-size manufacturer

The question is almost never “custom or SAP”. It is “which parts of this business should run on somebody else’s model of how manufacturing works, and which parts should run on ours”. Framed that way, the answer stops being ideological and starts being answerable.

This guide is written for manufacturers somewhere between roughly 50 and 500 people, with real production complexity, an accounting system that mostly works, and a growing pile of spreadsheets holding the operations together.

Why this decision is on your desk in 2026

Two forces are pushing it.

The first is a hard vendor deadline. SAP has confirmed that mainstream maintenance for SAP ECC 6 and Business Suite 7 core applications ends on 31 December 2027, with optional extended maintenance to the end of 2030 at an additional fee widely reported at around 9%, and reduced customer-specific maintenance after that. If you run ECC, doing nothing is now a decision with a date on it.

The second is subscription drift. Across the wider software market, 79% of IT leaders reported SaaS price increases at renewal in the preceding twelve months, with typical annual increases of 8–12% and aggressive vendors at 15–25%. Per-seat licensing that was affordable at 40 users behaves differently at 140.

Neither force tells you what to do. Both make “leave it alone” more expensive than it was.

Where each option genuinely wins

Strip away the sales material and the two approaches are good at different things. They are not competitors for the same job.

Dimension	Tier-one ERP (SAP, Dynamics, NetSuite)	Custom-built operations system
Statutory finance and tax	Strong — maintained by the vendor across jurisdictions	Weak — you would be rebuilding a solved problem
Consolidation across legal entities	Strong	Possible but rarely worth building
Auditor and bank familiarity	Strong — recognised on sight	Requires explanation and documentation
Your non-standard production process	Weak — you adapt, or you pay for customisation	Strong — the process is the specification
Speed of change after go-live	Slow, gated by upgrade and partner cycles	Fast — days to weeks, if you own the code
Cost as headcount grows	Rises with users under per-seat licensing	Flat — no per-user licence on an owned asset
Upgrade obligation	Vendor-driven, on the vendor's calendar	Yours, on your calendar
Exit and portability	Data export, but process logic stays behind	Full source and schema, if contracted properly

Two rows in that table do most of the work.

“Your non-standard production process.” Every manufacturer has three or four things it does differently, and those things are usually why customers buy from you rather than a competitor. A package will model them as an approximation, a bolt-on, or a spreadsheet somebody maintains beside the system. That last option is the most common and the most expensive, because it is invisible in the budget.

“Cost as headcount grows.” Published 2026 list pricing puts Dynamics 365 Business Central at $80–110 per user per month and NetSuite in the $100–200 range depending on negotiation, with a platform fee on top. Whether that is expensive depends entirely on how many people need a licence — and on whether the shop-floor operator who only scans a job number needs one.

The hybrid answer, and why it is usually correct

The pattern we see most often in mid-size manufacturing looks like this:

• The financial core stays standard. General ledger, receivables, payables, fixed assets, statutory reporting, e-invoicing. This is where being conventional is a feature.
• The operational layer is custom. Production scheduling against real constraints, quality and traceability records, maintenance, dealer or distributor ordering, field service. This is where being conventional costs you margin.
• The two exchange data through defined interfaces, not through people retyping. Stock movements, cost postings, invoices out, master data in.

This is not a compromise. It is a correct allocation of a fixed budget: standard where standardisation is valuable, custom where differentiation is valuable. We describe the integration side of it on the integrations page and the manufacturing scope on the manufacturing solutions page.

Five questions that settle the decision

Work through these in order. Most companies know their answer by question three.

1. Where does the money actually get made or lost? Not where the most transactions are. Where margin is created or destroyed. If it is in production scheduling, changeovers, scrap, or how fast you can quote a non-standard order, that is the custom candidate. If it is in purchasing terms and financial control, the package is doing more for you than you think.

2. How many spreadsheets sit beside the current system, and who owns them? Count them properly. Each one is a process the system does not model, running on one person’s laptop with no audit trail. That count is the honest measure of package fit. Two is normal. Eleven is a diagnosis.

3. How often does the process change? If your operations change meaningfully once a year, package rigidity is tolerable. If they change quarterly because customers keep asking for something new, rigidity compounds. Ask any package vendor how long a moderate process change takes after go-live, and what it costs.

4. How many people need to touch it? Multiply your realistic five-year user count by the per-seat price. Include the people you currently exclude because licences are expensive — warehouse, shop floor, field engineers, dealers. If the honest number is uncomfortable, per-seat is the wrong shape for your business.

5. What happens if the supplier disappears? For a package, you keep running and lose the roadmap. For custom, the answer depends entirely on your contract: whether you hold the source code, the schema, the deployment recipe and the repository history. If you do, another team can take over. If you do not, you have bought a package with worse economics. This is covered in detail in code ownership and lock-in.

What ERP projects actually fail on

It is worth being clear-eyed, because this failure mode is shared by both paths.

Panorama Consulting’s research puts the overall ERP failure rate at around 68%, and attributes the top three causes — inadequate change management, poor data migration and inexperienced teams — to more than three-quarters of failures. Analyses of discrete manufacturing report substantially higher cost overruns than in other sectors.

Read that list again. None of those three causes is “we picked the wrong product”. Choosing between SAP and a custom build is not the risky part of this project. Migrating dirty master data and asking people to change how they work is the risky part, and it is identical either way.

The practical implication: whichever path you take, budget seriously for data cleanup and for the people side, and structure the project so that failure is discovered early and cheaply rather than late and expensively.

A staged path that limits what you can lose

If you are leaning custom, or hybrid, this is the sequence we recommend.

1. Pick one workflow, not a system. The one that costs the most in rework, delay or margin. Write it down in one page: who touches it, what triggers it, what must come out.
2. Get a clickable prototype in two weeks. Not a slide deck. Screens your own staff can walk through and argue with. Most scope errors surface here, when they are free to fix.
3. Put one module into production in 2–4 weeks. Real users, real data, running alongside whatever it replaces. Our published band for a single focused module is $3,000–6,000; the full table is on the pricing page.
4. Connect it to the ERP before you build the second module. Integration is where estimates go wrong, so find out early. One interface built properly de-risks every later module.
5. Then decide about scale. If module one landed, module two is a known quantity. If it did not, you have learned that for the price of six weeks rather than a programme.
6. Keep the accounts in your name throughout. Repository, cloud, domain — created in your organisation before the first invoice, not transferred after the last one.

What a hybrid actually looks like

Abstractly, “standard finance, custom operations” sounds like a slogan. Concretely, in a manufacturer of 120 people, it usually looks like this.

The ERP holds items, bills of materials, suppliers, customers, purchase orders, stock valuation, the general ledger and statutory reporting. It is the system of record and the auditor’s reference point. Nothing about that changes.

Custom modules sit alongside it and own the parts the ERP models poorly:

• Production execution. Work orders pulled from the ERP, started and stopped on tablets on the floor, with stop reasons, scrap causes and operator and machine attribution. Completions and consumption posted back. This is covered in detail in MES vs ERP.
• Quoting for non-standard orders. The estimating logic that is currently a spreadsheet owned by one engineer, turned into something the sales team can run without them.
• Distributor ordering. Prices, stock and order status exposed to your dealers so they stop emailing. Covered in B2B ordering portals.
• Traceability and compliance evidence. Batch, material and document chains that increasingly have to be producible on demand.

Between the two sits a small number of well-defined interfaces, each with an owner, a schedule and an exception queue. Not a nightly file drop nobody monitors.

The reason this works is that it puts the change frequency in the right place. Finance changes when legislation changes, which is slow and external. Operations change when customers ask for something new, which is fast and internal. Putting both on the same platform forces the fast half to move at the speed of the slow half.

Questions worth putting to a package vendor

If you are evaluating a package, these five questions produce more signal than a feature comparison:

1. “Show me this specific process in your product.” Bring your actual most awkward process. Not a generic scenario — the one with the subcontracted operation in the middle, or the customer who orders in cases and is invoiced in kilograms.
2. “What does it cost to add an approval step after go-live, and how long does it take?” The answer tells you the real cost of change.
3. “Which of my users need a full licence and which do not?” Then multiply by your five-year headcount, including the shop floor.
4. “What happens to my data and my process configuration if I leave?” Data export is usually available. The configuration that encodes how you work usually is not.
5. “Who does the implementation, and have they done my industry?” With tier-one packages the product and the implementer are different companies, and the implementer determines the outcome.

Ask a custom supplier the mirror image of the same questions, particularly the fourth. The answer should be that you hold the source code, schema, deployment recipe and repository history from the first commit.

If your driver is the 2027 ECC deadline

Do not let a vendor deadline choose your architecture. It is a date for the finance core, not a mandate to rebuild every operational process on the same platform in the same programme.

A defensible sequence: decide the finance core path first, on its own merits and its own timeline. Then, separately, identify the operational workflows the new core will not serve well, and treat those as a parallel custom track that can run before, during or after. Trying to solve both in one programme is how a maintenance deadline turns into a three-year transformation.

Practical next steps: the delivery bands and timelines are on the pricing page, the sequencing approach for moving off a legacy system is in the migration guide, the trade-off in general terms is on package vs custom, and a single module can be scoped through the quote form.

Frequently asked questions

Is custom ERP cheaper than SAP for a mid-size manufacturer?

The upfront numbers usually favour custom, but that comparison is misleading because the two rarely cover the same ground. A tier-one ERP brings a full statutory finance stack; a custom build typically covers operations and integrates with an existing accounting system. Compare like for like — same scope, five-year horizon, including licence renewals and internal effort — or the comparison means nothing.

What happens to SAP ECC in 2027?

SAP has confirmed mainstream maintenance for SAP ECC 6 and Business Suite 7 ends on 31 December 2027, with optional extended maintenance available to the end of 2030 at an additional fee reported at around 9%. After that, systems move to a substantially reduced customer-specific maintenance scope. It is a real deadline, and it is what is currently pushing thousands of ERP decisions forward.

Can custom software and SAP run together?

Yes, and this is the most common outcome we see. The ERP remains the system of record for finance, stock valuation and statutory reporting. Custom modules handle production scheduling, quality records, dealer ordering or field service, and exchange data with the ERP through defined interfaces. Nothing is ripped out and nothing is duplicated.

How long does a custom ERP module take to go live?

On our published delivery bands, a single focused module runs 2–4 weeks with an interactive prototype inside the first two weeks. A multi-department operations system runs 4–8 weeks, and an end-to-end platform 3–6 months. The important part is not the total — it is that something real is in production in weeks, not at the end.

What is the biggest risk in a custom ERP build?

Scope that was never written down. Panorama Consulting's research attributes the majority of ERP failures to inadequate change management, poor data migration and inexperienced teams. All three are process failures, not technology failures, and all three are equally capable of sinking a package implementation.

Do we lose best practice by building custom?

Partly, and deliberately. A package encodes an industry's average way of working, which is genuinely useful for finance and compliance where being average is correct. It is a liability in the operations that differentiate you, where the package forces you to work like everyone else. Build custom exactly where being different is the point.

Related guides

• ERP customer portal vs dealer portal: which one your network needs
• AI automation: how European, Gulf and Turkish buyers differ
• AI workflow automation vs RPA: choosing the right layer

Service page: Package vs custom