The ERP Integration Problem: Why Custom Software Alone Fails Without System Consolidation

You’ve decided to build custom software. Your ERP from 2015 still handles accounting and purchasing fine, but it can’t give you real-time production visibility. It can’t track job progress. It can’t adapt to how your shop floor actually works. So you’re investing in custom software to solve what the ERP can’t.

Here’s what usually happens next: the custom software gets built, deployed, and immediately becomes a separate system. Your team enters data into it. But the ERP still exists. So now you have two systems. Two sources of truth. Two databases that should match but don’t. And someone - usually your operations manager or an admin - is manually reconciling them every week, making sure that what the ERP says matches what the new software says.

That reconciliation work is invisible. It doesn’t show up in your ROI calculation. But it’s real, it’s expensive, and it’s the reason custom software alone rarely solves your operational problems.

The Shadow System Problem: When Custom Software Becomes Another Spreadsheet

Your ERP is the system of record for the business. It controls GL entries, inventory, purchasing, customer data. That’s by design. But the problem is this: the ERP was built for financial accuracy, not operational speed.

So your operations team has learned to work around it. They pull data out of the ERP. They run it through spreadsheets and analysis. They track real-time job status in a side system because the ERP’s job costing module runs nightly, not in real-time. They maintain a manual schedule because the ERP’s scheduling module doesn’t understand your sequencing logic.

Now you’re building custom software to replace those spreadsheets. And here’s the critical moment: do you build the custom software as a replacement for those workarounds, or as a supplement to the ERP?

Most companies choose supplement. The custom software becomes another tool in the toolkit. It solves the immediate pain - real-time job tracking, better visibility, faster decisions. But it doesn’t replace the ERP. So now you have three systems: the ERP (the source of truth for finance), the custom software (the tool for operations), and increasingly, more spreadsheets to coordinate between them.

The custom software didn’t fix your operation. It just added another layer to maintain.

Data Gravity and the Hidden Tax of Multiple Systems

Here’s a concrete example. You implement custom software for job tracking. Your shop floor team uses it daily. It’s fast, it’s current, it shows real-time status. It’s genuinely better than the spreadsheet they were using.

But the customer invoice still comes from the ERP. The cost accounting still happens in the ERP. The inventory adjustment still runs through the ERP. So at the end of the day, someone has to make sure that what the custom software says about job status matches what the ERP says about costs and materials consumed. If they don’t match, finance gets upset. If they match but one system is behind, your reporting is wrong.

That coordination work is the hidden tax of multiple systems. It doesn’t appear in any budget line. It just appears as “someone spends two hours every Friday reconciling data.” Multiply that across your operation - production, inventory, finance, sales - and it’s a full-time person’s job just keeping systems synchronized.

The financial impact is brutal. You paid $80k-$150k to build custom software. You’re paying $3k-$5k per month in retainer support to maintain it. But you haven’t reduced the manual work. You’ve just shifted it from “people doing spreadsheet calculations” to “people coordinating between systems.”

And when systems drift - when data in one system doesn’t match the other - you’ve created a problem nobody expected. Your production team made a decision based on real-time custom software data that the ERP doesn’t reflect. Now you’re revising customer promises or re-planning your production schedule.

Why Integration Always Fails (And Why You Shouldn’t Start There)

Most companies think the solution is better integration. They say “let’s have the custom software pull data from the ERP every hour. We’ll sync everything automatically.” This sounds logical. It usually doesn’t work.

Why? Because integration is fragile. Every system you connect increases complexity exponentially. The ERP has an API. Maybe. It might require a custom connector built by a consultant at $150/hour. The API pulls general ledger data, but not real-time inventory. So you need a second API call, or a database dump run on a schedule. One system uses a different date format. Another uses a different currency code. The custom software needs logic to transform and reconcile.

And then someone updates the ERP. A patch releases. The API changes. Authentication requirements shift. The integration breaks. Now your custom software is showing stale data, or errors, or nothing. And your team has to call the ERP vendor to understand what happened, which costs money and takes time.

Integration isn’t a one-time cost. It’s an ongoing liability. Every system you connect is a source of potential failure. The more connections, the more places things can break.

Companies that successfully use custom software don’t start with integration. They start with isolation.

The Real Problem Isn’t Integration - It’s Consolidation

The question you should be asking isn’t “how do we integrate our custom software with our ERP?” It’s “do we actually need both systems?”

In many manufacturing operations, the ERP has become a legacy system doing one job really well - managing GL transactions and purchasing - while being terrible at everything else. Your operation has evolved beyond what the ERP was built to do.

That’s not a reason to bolt custom software onto the ERP. It’s a reason to think about consolidation.

Consolidation means this: the custom software becomes the primary operational system. It handles production tracking, job costing in real-time, inventory visibility, shop floor coordination, scheduling. The ERP becomes a secondary system - a place where transactional data gets recorded daily or weekly for accounting purposes. The flow is one-way: operational data flows from custom software into the ERP, not the other way around.

This is fundamentally different from the integration approach. Instead of keeping two systems synchronized, you’re treating the ERP as a recorder, not the source of truth for operations.

Why does this matter? Because it eliminates the reconciliation tax. The custom software is the system your team uses every day. The ERP gets what it needs - GL entries, payables, costs - pulled from the custom software in a controlled way. There’s no manual reconciliation because there’s no competing source of truth.

What Consolidation Looks Like in Practice

Here’s a real manufacturing scenario. A mid-size job shop has an ERP from 2010. It handles GL, AP/AR, and basic job costing. It’s slow for anything requiring real-time visibility. The shop floor supervisor spends two hours every morning manually updating spreadsheets because the ERP doesn’t show current job status.

They’re building custom software for real-time production tracking, scheduling, and job visibility. Here’s the consolidation approach:

The custom software becomes the operational system of record. It tracks all production activity, job status, labor, materials consumed, and sequence. It’s where the shop floor team works every day.

Daily data feeds from custom software to ERP. Every night, the system automatically generates GL entries from the day’s production activity. Materials consumed flow into inventory GL. Labor hours flow into payroll GL. Cost adjustments flow into job costing GL. The ERP’s accounting system stays accurate without manual intervention.

The ERP handles financial transactions only. AP/AR, purchase orders, GL consolidation, reporting. These functions stay in the ERP because they’re already working there and because they’re financial controls you don’t want to move.

Reporting integrates both systems, but custom software is the source. When you need to know “what’s our cost to date on job X?” the answer comes from the custom software. When you need “what’s our total GL cost by job?” that comes from the ERP, which got its data from the custom software the night before. One direction of truth, no reconciliation.

This approach costs more upfront than just bolting on custom software. You need to think through how data flows. You need GL mapping logic. You need automated reconciliation where differences are flagged for review, not hidden. But the ongoing cost is much lower because you’re not paying people to manually sync systems.

When to Replace vs. When to Consolidate

Not every company should move to full consolidation immediately. Some manufacturers are ready. Some aren’t. Here’s how to decide.

You’re ready for consolidation if:

• Your ERP is a legacy system (5+ years old) that your operation has outgrown
• The ERP primarily handles finance, not operations
• Your team has already built workarounds (spreadsheets, side systems, manual processes) to do operational work the ERP can’t do
• You’re planning to invest in custom software that will be in place for 3+ years
• Your operations are complex enough that the ERP’s standard modules don’t apply

You should keep the ERP and integrate cautiously if:

• Your ERP is relatively modern (2018 or newer) and still being actively updated
• The ERP is handling both financial and operational requirements reasonably well
• The custom software you’re building is a tactical fix to one specific problem, not a complete operational platform
• Your operation is relatively standard and the ERP’s modules apply

If you’re building custom software, you need to make this decision upfront. Not after the custom software is built. Because the decision affects architecture, data flows, and where you invest your limited budget.

The Consolidation Conversation You Need to Have

Most manufacturing companies never have this conversation because nobody raises it. They say “let’s build custom software” without asking “what is our legacy ERP actually doing well, and what should we consolidate?”

The conversation should go like this:

Question 1: What does your ERP do better than everything else? Usually it’s GL and financial controls. Keep that. Everything else is candidate for consolidation.

Question 2: What is your operation paying for - in time, in accuracy, in visibility - because your ERP can’t do it? This is what the custom software fixes. But if you consolidate, the custom software becomes your primary operational system, not a supplement.

Question 3: What data needs to flow from operational systems to finance every day? This defines the integration you absolutely need - in one direction.

Question 4: Can you manage two systems during the transition, or do you need a hard cutover? Most companies run parallel systems for 1-3 months. Some run longer. This affects timeline and cost.

If you’re building custom software without asking these questions, you’re building a shadow system. You’ll solve one problem. You’ll create another. And you’ll be paying forever to keep them synchronized.

What Jetpack Does Differently

We’ve built custom operational software for manufacturing companies that still have legacy ERPs. We’ve learned that integration-first thinking creates long-term problems. So we start with consolidation thinking.

When you tell us you want to build custom software, we ask: “Does this replace something in your ERP, or does it supplement it?” If it supplements, we talk through whether that’s sustainable. Often it isn’t. That conversation happens before we write a single line of code.

If consolidation makes sense, we design the custom software as the operational system from day one. We design it to be the source of truth for your operation. We build the data flows to the ERP, not the other way around. That changes architecture decisions early, which saves cost and complexity later.

We also own the integration responsibility. If we’re building the custom software, we handle getting data to your ERP reliably. You’re not left managing the integration yourself.

The result is custom software that actually reduces your operational burden instead of adding to it.