When a custom system beats an off-the-shelf ERP after GP

Let us start with the disclosure, because it colors everything on this page: Webisoft is a software engineering firm. Building custom systems is what we do. Which is exactly why you should weigh what follows carefully, and why we are going to argue against custom for most readers anyway. A custom system sold to the wrong company fails loudly, and we would rather point most GP shops at a packaged ERP, usually Odoo, than build something they will resent.

With that said: there is a real minority of GP customers for whom another packaged ERP is the wrong answer, and almost nobody in the migration industry will tell them so, because almost everybody in the migration industry is paid to resell a package.

How much off-the-shelf ERP there already is to buy

Before getting to when custom wins, look at how much packaged capability already exists to buy instead of rebuild. The global ERP software market was valued at $64.8 billion in 2024 and is projected to reach $123.4 billion by 2030, an 11.7 percent compound annual growth rate.1 A second independent estimate puts the same market at $81.15 billion in 2024, growing to $92.6 billion in 2025.2 The two research firms scope the market differently, which is normal across analyst houses, but both agree on the direction: this is a large, fast-growing, heavily funded category, not a niche where you are unlikely to find a fit.

That scale is a proxy for how much engineering effort has already gone into problems a custom build would otherwise ask your team to solve from a blank page: multi-entity consolidation, tax engines, audit trails, localized payroll, inventory costing methods, approval routing, bank reconciliation. Dozens of vendors compete for the same mid-market dollar a GP shop is about to spend, and Odoo, Business Central, NetSuite, and Sage Intacct between them cover the overwhelming majority of what a departing GP shop’s finance and operations actually need. Before evaluating a custom build, make the packaged options prove they cannot do the job. Most GP customizations turn out to be gaps a well-configured package closes for a fraction of build cost, not gaps only custom code can close.

Why some companies are still on GP in the first place

GP lasted 30 years in some businesses not because it was loved, but because it was moldable. Dexterity let VARs and internal developers change core behavior. eConnect and Integration Manager let it talk to anything. A deep ISV ecosystem (field service, distribution, payroll niches, industry verticals) filled every gap. Companies poured 20 years of process knowledge into those layers.

That is why the standard migration pitch (“just move to the modern equivalent”) lands wrong for these shops. The modern equivalents are far less moldable by design. Cloud ERPs constrain customization on purpose, and the constraint is a feature for the 90 percent and a wall for the 10 percent.

The first question is which group you are in.

The honest test

Custom is worth a real evaluation in some situations, and it is worth avoiding in far more of them. The line between the two rarely comes down to taste. It comes down to whether the customization encodes how you make money or just how you are used to working.

Read the left column again before the right one. In our experience most companies that ask us about custom belong there, not on the right, and the honest conversation starts by checking which column actually describes them.

What “custom” actually means here

Nobody should hand-build a general ledger in 2026. Accounting is the most commoditized software category on earth, and a custom GL creates audit friction forever. So the realistic architectures are:

Packaged financial core plus custom operational modules. Odoo, Business Central, QBO, or Xero runs GL, AP, AR, and financial reporting. Custom software runs the differentiating operations (pricing, scheduling, production, the vertical workflow) and posts summarized journals into the core through its API. This is the right shape for the large majority of “custom” cases, and it is what we recommend most often when custom is on the table at all. Odoo in particular is built for this shape natively: its own framework is a modular system of apps sharing one database, which is closer to how GP shops used Dexterity than a rigid cloud suite is, without the risk of building the financial core from scratch. Our Odoo migration page walks through that architecture in detail; treat this page as the test for whether you need to go further than it.

Fully custom operational system with accounting outsourced to the package. Same idea, heavier on the custom side: the business runs its day in the custom system, and the ERP is reduced to a financial book of record your accountants and auditors live in.

Fully custom everything. Rarely justified. Software companies, marketplaces, and businesses whose product is the system itself. If you are reading a GP migration site, this is probably not you.

Note what this framing does to the migration itself: your GP history, open transactions, and payroll cutover follow the same playbook as any ERP migration, because the financial core is still a package. The custom work is additive, not a substitute for doing the accounting migration properly.

The risk custom scope amplifies

Packaged ERP projects already carry real risk before anyone adds a line of custom code. In Panorama Consulting’s 2024 survey of 131 organizations running ERP projects, 32.8 percent went over budget and 31.3 percent went over schedule.3 Asked why, the single largest named cause of budget overruns was not a vague “things came up.” It was an unexpected need for additional technology, cited by 51.2 percent of over-budget projects, ahead of underestimated staffing, organizational issues, and data problems.3

That statistic matters directly for a custom decision, because “unexpected need for additional technology” is exactly the failure mode a custom scope invites if it is not tightly bounded. A packaged ERP has a fixed, demoable feature set; scope creep usually means turning on a module you already licensed. A custom build has no such ceiling. Every “while we are in there” request is new code, new testing, and new maintenance, on a system with no vendor roadmap to point to and no other customer’s bug reports to lean on. If roughly a third of packaged projects still get surprised by technology needs they did not scope, a custom project without firm boundaries will get surprised more, not less.

This is not an argument against custom. It is an argument for scoping it like an engineer instead of like a wish list: a fixed, written specification for the operational edge you are building, a packaged core that absorbs everything else, and a hard rule that new requests become the next phase, not this one.

The cost and ownership tradeoffs, plainly

The median off-the-shelf ERP implementation costs $450,000 and takes 15.5 months.3 That is the number a custom estimate has to beat, not the number it starts from. A custom quote that undercuts it on paper and then runs into the same categories of overrun (unexpected technology needs, underestimated staffing, data issues) has not actually beaten the packaged option. It has just delayed the moment the packaged option would have looked cheap.

Two things GP veterans should recognize in that table. First, the ownership model of custom is the ownership model you already lived with GP plus a VAR: you paid for control and you got it, along with the responsibility. Second, per-user subscription pricing compounds. A 60-user shop paying mainstream cloud ERP rates spends serious money over a decade, and for heavily customized shops that math is part of what makes custom rational, provided the differentiating workflow is real.

The failure mode to fear is not the build. It is year three, when the original developers have moved on, nothing was documented, and the system cannot change. That risk is managed the boring way: written specifications, code in your own repository (you own it, not the vendor), automated tests, and a standing maintenance arrangement. If a custom proposal does not address ownership and continuity explicitly, walk away.

Rebuild versus buy: the risk question

Buying a package risks a bad fit you discover slowly. Building risks a bad project you discover expensively. The honest comparison:

• A packaged implementation that goes wrong usually limps to a working state. A custom build that goes wrong can deliver nothing.
• Custom risk concentrates in scope definition. GP shops actually have an advantage here: 20 years of GP usage is a running specification. Your SmartLists, your modified windows, your Integration Manager jobs are a precise record of what the business needs. A good discovery process mines that instead of starting from a blank page.
• De-risk with sequencing. Keep GP running: it is supported for tax and technical purposes until December 31, 2029, and it receives security updates until April 30, 2031.4 Stand up the packaged financial core first, then build the custom modules one at a time against a live, working system. Never a big bang.

How Webisoft thinks about it

When a GP shop comes to us, the default recommendation is a packaged ERP, usually Odoo and sometimes Business Central, and we say so even though implementing a package is the smaller engagement for us. Custom comes up when discovery surfaces a workflow that is both differentiating and unfittable, and even then the answer is almost always the hybrid: packaged core, custom edges. A full custom rebuild is the answer for a small number of companies whose process moat is real, stable, and worth a decade of ownership, not for anyone who just dislikes the idea of change.

If you suspect you are in that minority, the cheap next step is a short technical review of your GP environment: what is customized, what those customizations do, and what each candidate architecture, packaged, hybrid, or fully custom, would cost to reach the same capability. That produces a defensible decision either way, which is worth more than either sales pitch.