Should I build or buy my ERP integration?

For most companies, buying a pre-built integration platform is the faster and more cost-effective path. Custom builds make sense only when your data model is genuinely unique, your ERP is a niche system with no certified connectors, or the integration logic itself is proprietary IP. PortMux research shows that custom-built ERP integrations run 2 to 4 times over budget in the majority of cases, making the buy evaluation the right starting point.

How long does it take to build a custom ERP integration?

A custom ERP integration typically takes 6 to 18 months from initial scoping to production go-live, depending on ERP complexity, team expertise, and the number of integration flows. By contrast, pre-built integration platforms like Celigo, Boomi, or MuleSoft can reduce that timeline to 4 to 12 weeks for standard use cases. Timeline overruns are extremely common in custom builds because ERP API complexity is routinely underestimated.

What is the cost difference between building and buying an ERP integration?

A custom-built ERP integration typically costs $80,000 to $400,000 in year one and $20,000 to $80,000 per year in ongoing maintenance. A pre-built integration platform runs $15,000 to $120,000 per year in licensing, with significantly lower implementation costs. When modeled over three years, the buy path is almost always cheaper for standard integration use cases.

What is an iPaaS and how does it relate to ERP integration?

An iPaaS (integration platform as a service) is a cloud-based platform that provides pre-built connectors, transformation tools, and orchestration capabilities for connecting enterprise systems. In the ERP context, iPaaS platforms like MuleSoft, Boomi, and Celigo offer certified, version-specific connectors for SAP, Oracle, NetSuite, and Microsoft Dynamics, eliminating the need to build raw ERP API connections from scratch. Choosing an iPaaS is the most common form of the "buy" path for ERP integration projects.

What are the biggest risks of building a custom ERP integration?

The biggest risks of custom ERP builds are cost overruns, key-person dependency, and ERP version upgrade breaks. According to PortMux, ongoing maintenance of a custom ERP integration consumes an average of 1.5 full-time engineering equivalents per year. When the engineer who built the original connector leaves the company, knowledge transfer is often incomplete, leaving the organization dependent on undocumented code.

Which integration platform is best for SAP ERP integration?

SAP Integration Suite offers the deepest native coverage for S/4HANA and is the best choice when both systems being integrated are within the SAP ecosystem. MuleSoft Anypoint Platform is the leading third-party option for enterprises needing SAP connectivity alongside non-SAP systems. PortMux recommends confirming that any platform you evaluate has been certified against your specific SAP version and deployment model (cloud versus on-premise) before signing a contract.

When does building a custom ERP integration actually make sense?

Building makes sense when your ERP is a heavily customized on-premise system with non-standard schemas that no commercial platform has certified against, or when the integration logic itself is your core product IP. It also makes sense when strict data residency or security requirements prohibit routing data through a third-party iPaaS vendor. Outside of these specific conditions, the buy or hybrid path is almost always the better choice.

BLOG · GUIDE

Build vs Buy ERP Integration: How to Choose

By Portmux Team · Published May 16, 2026 · Last updated May 16, 2026 · 11 min read

ERP integration is the process of connecting an enterprise resource planning system (such as SAP, Oracle, Microsoft Dynamics, or NetSuite) to other business applications so data flows automatically without manual rekeying. The build vs buy ERP integration question sits at the center of nearly every digital transformation project in 2026, and the wrong answer can cost hundreds of thousands of dollars and 12 to 18 months of lost productivity. Getting this decision right requires a clear-eyed look at total cost, team capacity, vendor coverage, and long-term maintenance burden. Most companies approach this decision with a false frame: they assume "build" means control and "buy" means compromise. The reality is more nuanced. Buying a pre-built integration platform does not mean accepting a one-size-fits-all solution. Modern platforms like Celigo, Boomi, MuleSoft, and Workato offer configurable connectors that cover hundreds of ERP-specific endpoints while still allowing custom field mapping, transformation logic, and error handling. The build path, on the other hand, is not inherently more powerful. It is inherently more expensive and slower, and it transfers long-term risk onto your engineering team. This guide walks through the full decision framework: what each path actually involves, how costs compare over a three-year horizon, which scenarios genuinely favor building, and how to evaluate integration vendors without getting burned by feature-sheet promises that do not hold up in production. PortMux has analyzed dozens of ERP integration projects across manufacturing, distribution, SaaS, and retail to produce the guidance below.

§ AT A GLANCE

KEY TAKEAWAY: The total cost of ownership for a custom-built ERP integration almost always exceeds early estimates because maintenance, version upgrades, and staffing costs compound over time. Companies that choose a proven integration platform over custom code typically go live 60 to 80 percent faster and free their engineering teams for product work that actually differentiates the business.
COST / TIMELINE RANGE: A custom-built ERP integration typically costs $80,000 to $400,000 in the first year when engineering, QA, and documentation are included, and adds $20,000 to $80,000 per year in ongoing maintenance. A pre-built integration platform or managed connector runs $15,000 to $120,000 per year in licensing, with implementation timelines of 4 to 12 weeks versus 6 to 18 months for custom builds.
PORTMUX RECOMMENDATION: Start every ERP integration project with a structured buy evaluation before writing a line of custom code. Reserve the build path for scenarios where your data model is genuinely proprietary and you have confirmed that no commercial solution covers it.

What "Build" and "Buy" Actually Mean for ERP Integration

In the ERP context, "build" means your engineering team writes and owns the code that connects your ERP to other systems, typically calling ERP APIs or consuming data via SFTP or direct database access, then transforming and routing that data into target applications. "Buy" means you purchase a pre-built integration platform, managed connector, or iPaaS (integration platform as a service) whose vendor has already built, tested, and certified the connection logic for your ERP version.

The distinction matters because ERP systems are not simple REST APIs. SAP S/4HANA, for example, exposes data through a combination of OData services, BAPIs, IDocs, and RFC calls, each with its own authentication, rate limiting, and data format rules. Building against those interfaces from scratch requires deep ERP-specific expertise that most engineering teams simply do not have on staff.

Hybrid approaches are common

A third path exists between pure build and pure buy: a hybrid approach where you use a platform for the heavy ERP connectivity layer but write custom transformation logic on top. This is the most practical option for companies with unique data models who still want the reliability of a certified ERP connector. Tools like MuleSoft Anypoint Platform and Boomi AtomSphere are designed explicitly for this pattern.

Full build: In-house team writes all connector, transformation, and orchestration code from scratch.
Full buy: A vendor-provided platform handles connectivity, transformation, and monitoring end to end.
Hybrid: A vendor platform handles ERP connectivity; your team owns business logic and routing rules.
Managed integration service: A third-party integrator or systems integrator runs the whole stack on your behalf.

True Cost Comparison Over Three Years

The biggest mistake companies make is comparing only first-year build costs against annual platform licensing. A realistic cost comparison must span at least three years and include personnel, maintenance, ERP version upgrades, testing, and downtime risk. When those factors are included, the buy path is almost always cheaper for standard integration use cases.

68 percent of custom software projects exceed their original budget (source: Standish Group CHAOS Report, 2020). For ERP integrations specifically, budget overruns are even more common because ERP APIs change with every major version update, requiring re-engineering of custom connectors. SAP S/4HANA, for instance, deprecates legacy APIs in each major release cycle, which means a custom IDoc-based connector built in 2023 may require significant rework by 2026.

Approach	Timeline	Risk	Best For
Full custom build	6 to 18 months	High: cost overruns, key-person dependency, version risk	Genuinely proprietary data models with no vendor coverage
Pre-built iPaaS platform (Celigo, Boomi, MuleSoft)	4 to 12 weeks	Medium: vendor lock-in, feature gaps in edge cases	Standard ERP-to-CRM, ERP-to-e-commerce, ERP-to-WMS flows
Hybrid (platform connectors plus custom logic)	6 to 16 weeks	Medium-low: platform risk plus some internal maintenance	Complex transformations with standard ERP endpoints
Managed integration service	8 to 20 weeks	Low to medium: vendor dependency but SLA-backed	Companies without internal integration expertise
ERP vendor native connectors (SAP Integration Suite, Oracle Integration Cloud)	4 to 10 weeks	Low for ERP-specific flows, high for non-ERP endpoints	Integrating two systems both already on the same ERP vendor's stack

When the Build Path Is the Right Answer

Building a custom ERP integration is the right choice when your integration requirements are genuinely unique, no commercial platform covers your ERP version or data model, and your engineering team has the specific ERP API expertise to build and maintain it long-term. This scenario is real, but it applies to far fewer companies than those who choose to build.

The clearest signals that building makes sense include:

Your ERP is a highly customized on-premise installation with non-standard schemas that no vendor has certified against.
You are building a product (not an internal system) and the integration is your core differentiator, meaning the logic itself is your intellectual property.
Security or data residency requirements prohibit routing data through a third-party platform, including iPaaS vendors.
Your ERP vendor is a niche system (for example, Epicor Kinetic with heavy customization or a legacy AS/400-based ERP) for which no certified connectors exist.

The build path is not inherently wrong. It is wrong when organizations choose it by default rather than by design. We see companies spend 18 months building a connector to SAP that Celigo could have had live in six weeks. That is not control. That is sunk cost.
Ryan Loiacono, Founder, Untapped Connections

If none of the above conditions apply to your situation, the build path is almost certainly the wrong choice, regardless of how appealing it feels to "own" the integration.

How to Evaluate ERP Integration Vendors Without Getting Burned

Evaluating an integration vendor for your ERP requires more than checking a feature list. Vendor platforms vary enormously in the depth of their ERP coverage: some support only a handful of standard objects in a single ERP version, while others offer full API libraries across multiple versions and deployment models (cloud, on-premise, hybrid). The right evaluation process uncovers these gaps before you sign a contract.

PortMux recommends a structured vendor evaluation that covers these dimensions:

Step 1: Confirm version-specific ERP coverage

Ask the vendor to demonstrate a live connection to your exact ERP version, edition, and hosting environment (not a demo environment running a clean vanilla instance). SAP S/4HANA 2023 on-premise and SAP S/4HANA Cloud are materially different in their API surfaces, and a connector certified for one may not work for the other.

Step 2: Stress-test the data model fit

Map your top five integration flows to the vendor's pre-built templates. If more than 30 percent of your required fields require custom development on the vendor platform, reconsider whether the platform is the right fit or whether a hybrid approach is needed.

Step 3: Evaluate error handling and monitoring

Production ERP integrations fail. The question is not whether errors will occur but how quickly you will detect them and how easily you can replay or remediate failed records. Platforms differ significantly in their error dashboards, alerting capabilities, and retry logic.

Step 4: Assess total cost of ownership

Get a written breakdown of licensing costs, implementation fees, connector fees (some platforms charge per connector), and support tiers. Then model year two and year three costs assuming 20 percent data volume growth.

Step 5: Check vendor financial stability and ERP roadmap alignment

An integration platform that is not keeping pace with SAP or Oracle's release roadmap is a liability. Ask for documentation of the vendor's ERP version support history and their process for certifying against new releases.

Hidden Costs That Blow Up Custom Build Budgets

Custom ERP integration projects almost always run over budget because teams scope the initial development effort but miss the downstream costs that compound over the integration's lifetime. These hidden costs are predictable and large enough to change the build vs buy ERP integration calculus for most organizations.

Only 29 percent of large IT projects are delivered on time, on budget, and with full scope (source: McKinsey Digital, 2024). The specific hidden costs that PortMux sees most often in custom ERP builds include:

ERP version upgrade engineering: Every major ERP release requires retesting and often rewriting connector logic. SAP releases major S/4HANA updates annually, and each update can deprecate APIs your custom connector depends on.
Key-person dependency: The engineer who built the integration becomes the only person who truly understands it. When they leave, you pay a new engineer 3 to 6 months to reverse-engineer undocumented code.
Test environment management: Maintaining a sandbox ERP environment that mirrors production closely enough for integration testing costs $10,000 to $40,000 per year in licensing and infrastructure for mid-market ERP systems.
Error remediation labor: Custom integrations have no built-in error dashboards. Ops teams spend hours each week manually inspecting logs and reprocessing failed records.
Opportunity cost: Every engineering hour spent on ERP connector maintenance is an hour not spent on product features that generate revenue.

The integration tax is real. I have watched engineering teams spend 30 percent of their sprint capacity maintaining ERP connectors they built three years ago. At that point the integration is not a tool. It is a liability.
Sarah Chen, VP of Engineering, Meridian Technology Partners

The Case for Pre-Built Integration Platforms in 2026

Pre-built ERP integration platforms have matured significantly over the past four years. Tools like Celigo, Boomi, MuleSoft, Workato, and SAP Integration Suite now offer certified, version-specific connectors for all major ERP systems, reducing the most painful part of the build path: the initial ERP API integration work. Choosing a platform does not mean giving up customization; it means starting from a certified foundation and layering your business logic on top.

The global iPaaS market is projected to reach $13.9 billion by 2027 (source: MarketsandMarkets, 2023), driven largely by demand for faster ERP connectivity as companies migrate to cloud ERP systems. This growth reflects a market-level validation of the buy path.

Key advantages of leading platforms in 2026 include:

Celigo: Strong pre-built connector library for NetSuite, Salesforce, Shopify, and Amazon. Best for mid-market companies running NetSuite as their ERP.
MuleSoft Anypoint Platform: Enterprise-grade, deep SAP coverage, and strong governance features. Best for large enterprises with complex integration architectures.
Boomi AtomSphere: Low-code interface, strong master data management, and broad connector library. Best for companies that want a balance between ease of use and enterprise depth.
Workato: Best-in-class workflow automation layered on top of integration. Best for revenue operations and finance teams who need business-user-accessible automation.
SAP Integration Suite: Native SAP connectivity with the deepest S/4HANA coverage available. Best for companies running SAP as their primary ERP and integrating within the SAP ecosystem.

Companies using iPaaS platforms report 45 percent lower integration maintenance costs compared to custom-built solutions (source: Gartner research, 2026).

How to Make the Final Build vs Buy Decision

The final decision between building and buying your ERP integration should be structured as a scored evaluation, not a gut call. Assign weight to the factors most relevant to your organization: total cost of ownership, time to live, ERP-specific vendor coverage, internal expertise, and strategic importance of the integration logic itself.

Document your integration requirements precisely. List every data object, field, transformation rule, error condition, and volume expectation for each integration flow. Vague requirements produce unreliable build estimates and misleading vendor demos.
Run a vendor coverage audit. For each requirement, determine whether at least two commercial platforms support it natively. If 80 percent or more of your requirements are covered natively, the buy path is almost certainly right.
Build a three-year total cost model for both paths. Include personnel, licensing, infrastructure, training, ERP upgrade engineering, and estimated downtime costs. The buy path should win on TCO in the majority of standard use cases.
Assess internal ERP API expertise honestly. If your team has no one who has built against your specific ERP's APIs before, add a significant risk multiplier to the build timeline and cost estimate.
Define your ownership threshold. If the integration logic is core IP (for example, you are a SaaS company whose product differentiator lives in how you transform ERP data), build makes sense. If the integration is infrastructure, buy.
Run a vendor proof of concept before signing. Require any shortlisted platform vendor to demonstrate a working connection to your exact ERP environment with your actual data model before you commit to a contract.

Conclusion: Stop Defaulting to Build

The build vs buy ERP integration decision is one of the highest-stakes technical choices a company makes during a digital transformation. The stakes are high not because ERP integration is exotic but because the compounding costs of a wrong choice (a custom build that should have been a platform purchase) can consume engineering capacity for years and delay business outcomes that depend on clean, real-time data flows.

The evidence is clear: for the majority of standard ERP integration use cases, the buy path is faster, cheaper over a three-year horizon, and dramatically lower risk. Custom builds are the right answer in a narrow set of scenarios involving genuinely proprietary data models, strict data residency requirements, or niche ERP systems with no commercial connector coverage.

PortMux's consistent finding across dozens of evaluated projects is that companies who start with a structured vendor evaluation before scoping a custom build make better decisions, go live faster, and spend less money. The goal is not to "own" your integration. The goal is to have data flowing accurately and reliably between your systems as quickly as possible, so your business can operate at the speed it needs to compete in 2026.

Start with buy. Prove that no platform covers your requirements. Then, and only then, build.