ERP Customisation: 3 Smart Layers That Avoid Upgrade Risk

White Paper

Abstract

“Should I customise my ERP?” is the question most SYSPRO businesses reach for. It is not the full question, and starting there leads the conversation somewhere unhelpful.

Start instead with something truer, the one every SYSPRO business already knows about itself: your business is unique. Your context, your customers, and the reasons you win are not the same as your competitors’, and you do not do things exactly the way they do. If you did, you would slowly cede ground to whoever is innovating and breaking new frontiers. Built into how you operate are years, often decades, of institutional knowledge, and that is a real part of your success story.

Seen from there, the question changes shape. It is not “should I customise my ERP?” but “how do I make sure my systems support my real-world context and the differentiated way of operating I have already established works for me?” That reframe has a sharp implication: the best practice an ERP brings is not good enough on its own. It is a baseline (a solid, necessary floor for the parts of your business that look like everyone else’s), but only a floor. In the domains that make you competitive, you have to build beyond it.

This paper is about how to do that without wrecking what makes ERP valuable in the first place. The answer, drawn from the Lancea team’s work across 100+ SYSPRO customer system landscapes, is a question of layers: keep the ERP core standard, and build your differentiation into the layers designed to carry it: the ERP’s own upgrade-safe customisation layer, and the tailored landscape around it, connected through stable, backward-compatible APIs. AI agents are now joining that landscape too. Lancea’s own products (AGX, Tempo, CuroQuip, TRX) are used throughout as a working example of the pattern.

This paper is written for the person who owns the ERP decision, already running SYSPRO and weighing customisation right now: not a technical deep-dive, but a practitioner’s map of where, and how, to build beyond the baseline.

In this paper

1. The real question is not the one everyone asks
2. Best practice is a baseline, not a destination
3. Where the baseline runs out
4. Building beyond the baseline without breaking your ERP
5. What this means for your operation
6. A bridge in action
7. Build beyond the baseline, deliberately
8. References

The real question is not the one everyone asks

“Should you customise your ERP?” is a question the Lancea team hears constantly, and it cuts both ways. Some customers arrive certain they need SYSPRO customised because it does not meet an exact requirement. Others arrive equally certain they want vanilla: best practice, let the ERP run the way it is meant to run. Both instincts are understandable, and both start from the wrong place, because the question itself is too small.

Here is the bigger one. Your business is unique: not as a motivational slogan, but as an operational fact. Your market position, your customers, your cost structure, and the specific things you are good at are not identical to anyone else’s. And you do not do things exactly like your competitors do. That is not an accident or an inefficiency to be ironed out; it is usually the point. A business that runs identically to its competitors has no reason to be chosen over them, and it tends to lose ground, slowly and then quickly, to the ones who are innovating and pushing into new territory.

More than that: built into the way your business operates are years, often decades, of institutional knowledge. The reason a particular plant schedules the way it does, the reason your pricing logic bends a certain way for certain customers, the reason a supply decision gets made in a way no standard flowchart would predict: that accumulated, hard-won knowledge is part of your success story, not noise around it.

So the honest question is not “should I customise my ERP?” It is: how do I make sure my systems support my real-world context and the differentiated way of operating I have already established works for me?

That reframe leads directly to an uncomfortable but useful conclusion, and the rest of this paper follows from it: the best practice an ERP delivers is not, by itself, good enough. It is a baseline to build from, not a destination to arrive at.

Best practice is a baseline, not a destination

None of this is an argument against standard ERP. It is worth being clear about what standard ERP does well, because it is a lot. ERP’s design brief is to cover the basics fast and cover them well: financial records, transactional integrity, master data, guardrails, the audit trail. Every order, every transaction, every inventory movement, captured and governed. Standard modules exist because most businesses, most of the time, run their finance, their master data, and their core transactional processes in broadly the same way. There is no competitive advantage in reinventing that wheel, and real risk in trying to.

But notice what “best practice” actually means. Best practice is shared practice: the codified, common way of doing a thing, distilled from many businesses and handed back to all of them. That is exactly why it is valuable for the common ground, and exactly why it cannot be where your differentiation comes from. If your competitive edge lived in the same best-practice processes your competitors are also running, it would not be an edge at all. Best practice makes you as good as the field. It does not, and cannot, make you better than it.

That is the sense in which best practice is a baseline rather than a destination. For the parts of your business that genuinely look like everyone else’s, the baseline is the right place to stop: staying standard there is a smart, deliberate choice, not a compromise, and the costs of tailoring it are real. ERP customisation carries genuine, documented costs: a higher maintenance burden, added implementation complexity, and more upgrade risk. Panorama Consulting Group’s research on ERP implementations found that customisation “can greatly increase maintenance costs,” and that even before customisation is added, ERP projects are lengthy and expensive undertakings, often running into the millions for mid-sized and larger organisations.1 For SYSPRO implementations specifically, the Lancea team’s own delivery experience puts a full implementation at 6 to 18 months. Where the standard is genuinely good enough, spending that cost buys you nothing.

But for the domains that carry your differentiation, the baseline is where you start, not where you finish. There, the goal is not to match best practice but to build beyond it: to make your systems reflect the specific, better-than-standard way you have learned to operate. The rest of this paper is about how to do that deliberately, and how to do it without paying the upgrade-risk cost that rightly worries people.

Where the baseline runs out

Take something as ordinary as inventory planning. Standard MRP processes in SYSPRO cover most inventory planning scenarios quickly and well. But some customers need instant visualisation of how a scenario is changing in real time, or a last-minute alternative supply route with no standard path through the system: a preferred supplier goes short, and the decision about where else to source from, at what price, and with what lead time, does not follow a route the standard module was built to anticipate. It is a small example, but the pattern behind it recurs everywhere in SYSPRO environments, from customer-specific pricing logic to production scheduling nuances that only make sense once you understand why a particular plant runs the way it does.

The pattern is this: you cover the standard ground fast, and then you hit a point where “I don’t do it exactly like that.” That gap is not a flaw in your operation. It is the operational signature of everything the previous section described (your uniqueness, your institutional knowledge, your reason for being chosen) showing up in a specific process. It is where the baseline runs out and your differentiation begins.

You can’t let your processes mend to the systems. Your processes is what actually is the differentiator. Your systems need to support that differentiation.

As I said to our team directly in a recent working session: “You can’t let your processes mend to the systems. Generally that’s not a great idea, because your processes is what actually is the differentiator. Your systems need to support that differentiation.” That is the essence of it. When a business bends its processes to fit standard software, it is quietly trading away the very thing that makes it competitive in exchange for a slightly easier implementation. This holds true across business sizes, and it matters more, not less, as AI lowers the cost of building the tailored capability that supports differentiation.

Building beyond the baseline without breaking your ERP

Operational efficiency: where systems actually earn their keep

A business’s competitive edge can come from several angles: a unique product, exclusivity, brand strength. But from a systems perspective, the biggest lever most businesses have is operational efficiency, and very few can avoid the need to keep improving it. Product advantages erode, and brand strength takes years to build; operational efficiency is the one lever a business can keep pulling, quarter after quarter, largely on its own terms. That forces a choice: adopt systems that grow with you as you sharpen your specific competitive drivers, or fall behind competitors who do.

Even before AI arrived, the businesses that made a real step-change in their industries tended to take a systems-first approach. Uber, Airbnb, and Amazon are widely cited as examples: technology press and, in Airbnb’s case, the company’s own public statements, describe each of them running on architecture built specifically around their own operations rather than off-the-shelf software.2 That pattern is illustrative rather than a claim that standard software would have failed any of these companies outright; the point worth taking from it is narrower and more useful: businesses that treat systems as a strategic asset built around their own processes, rather than a generic utility, tend to unlock a different scale of operational advantage. Most SYSPRO customers are not operating at that scale, but nearly all of them have some version of the same pattern in their own operation: a place where building past the baseline pays for itself.

ERP customisation: the real decision is about layers, not “customise or don’t”

Once you accept that you need to build beyond the baseline, the fear that follows is legitimate: isn’t that exactly the customisation that makes ERPs expensive to maintain and painful to upgrade? It can be, but only if you build it in the wrong place. The trick is to stop thinking about “the ERP” as a single thing you either modify or leave alone, and instead see three distinct layers:

• The core: financial records, master data, transactional integrity, the audit trail, the built-in guardrails. This is the system of record, and it is the part the vendor keeps evolving with every release. Customising here is where the real upgrade pain and long-term cost come from. This is the baseline you protect: keep it standard.
• The ERP’s own customisation layer: the presentation and configuration layer the vendor deliberately built to be tailored. In SYSPRO this includes customised panes, custom form fields, user-defined screens, VBScript-driven behaviour, and in-ERP workflow configuration. This is customisation inside the ERP, but by design it rides on top of the core rather than altering it, so it is engineered to survive upgrades.
• The surrounding landscape: the bespoke systems, workflow tools, and, increasingly, AI agents that sit around the ERP and talk to it through stable, backward-compatible APIs. This is where deeper, process-specific differentiation lives without ever touching the core.

Set out this way, the old advice (“customise around the ERP, not inside it”) turns out to be a rough approximation of a better rule. The real principle is simpler: build your differentiation into whichever layer keeps your upgradability and the ERP’s forward roadmap intact. Both the ERP’s own customisation layer and the surrounding landscape meet that test. The core, by and large, does not. That is the line that matters: not the boundary of the ERP product itself, but the boundary between what the vendor keeps changing and what is built to be tailored.

Concretely, that means much of your differentiation can and often should live outside the ERP entirely: in systems around it, provided those systems are properly integrated so the whole functions as one system rather than a set of disconnected parts. Many SYSPRO customers already run a full internal system for their own nuanced operations, with SYSPRO directly behind it: no duplicated master data, with transactional integrity and the guardrails staying inside SYSPRO, while the tailored process logic lives in the systems talking to it. Other tailoring is best handled in SYSPRO’s own customisation layer, close to the data but still upgrade-safe. What matters is that neither route reaches into the core.

That arrangement creates an obligation: maintaining that layer yourself, or partnering with someone who owns it alongside you. Integration discipline is what makes the whole thing work, and it has become more important over the last decade, not less. It is not a one-off project. Systems around the ERP need the same ongoing attention as the ERP itself: someone accountable for keeping the integration healthy, for testing it against SYSPRO upgrades, and for making sure the periphery does not quietly drift out of sync with the core it depends on.

This is the industry’s own direction

This is not just a Lancea view. It matches where ERP architecture thinking has been heading more broadly, and two major analyst firms land on the same underlying pattern independently. McKinsey’s guidance on ERP strategy recommends implementing new customisation on a digital platform connected to the ERP core via APIs, a “façade layer” that keeps the core itself stable while bespoke capability sits around it.3 Deloitte reaches a similar conclusion from a different angle, framing the future ERP core as an “intelligent core”: still the single source of truth for the business, augmented rather than replaced at the edges.4

Implementation-advisor commentary is blunt about the risk on the other side of this coin: composable, periphery-based architecture “only works when the core is clean and governed.”5 That is a fair caution as much as a validation. Building beyond the baseline is not a shortcut around discipline; it depends on the ERP core staying genuinely standard, well-governed, and trustworthy as the system of record. It is precisely because the core stays standard that the layers around and on top of it can be tailored freely.

Gartner’s research, as reported by Rambase, projects that by 2027 more than 80% of organisations will be revisiting their ERP strategies specifically to enable easier, faster adoption of new functionality.6 That is consistent with the shift this paper describes: the ERP staying the stable core, with the pace of change happening in the layers around it.

SYSPRO’s own architecture points the same way, and SYSPRO supports building beyond the baseline on both fronts. On the periphery side, SYSPRO’s e.net Solutions integration layer exposes Business Objects that represent its business processes, and these run against the same business logic, validation, and security as SYSPRO itself: SYSPRO documents a “single set of security settings [that] applies to both business objects and core SYSPRO functionality.”7 In practice, that means a system built around SYSPRO through e.net inherits SYSPRO’s own governance rather than working around it: exactly the kind of properly integrated landscape this paper is describing, not a bolt-on that quietly bypasses the core’s guardrails. SYSPRO also documents e.net’s “version-independent functionality, ensuring compatibility across all versions.”7 So what you build around the core is not left exposed each time SYSPRO is upgraded. At the same time, SYSPRO ships a rich in-product customisation layer for tailoring the ERP itself without altering the core. Both routes are built into the product on purpose. SYSPRO itself is built around this core-plus-customisation-plus-periphery pattern, not against it, which is a useful thing to know when you are deciding where your own differentiation should live.

AI raises the stakes

AI takes the same pattern further. Where people used to sit outside the ERP doing tailored, judgement-heavy work, AI agents increasingly will too: some inside the ERP, more outside it, integrating in. That is the same category of tailored, need-specific capability (bespoke systems, workflow tools, AI agents) taking part in your system landscape and playing its part against the ERP, not independently of it, and it is fast becoming one of the most accessible ways to build beyond the baseline.

This is a real, sizeable shift rather than hype. Workflow automation is already a market valued at roughly $23.77 billion in 2025, and intelligent process automation is projected to grow from about $14.55 billion in 2024 to $44.74 billion by 2030.8 9 Colin Preller’s observation, raised in a recent working session with the team, that “workflow” is becoming as much of a coin phrase as “AI” itself, has real market weight behind it rather than just good timing. What sits under that word has also broadened: it now spans electronic routing, intelligent document capture, and rule-based or AI-assisted decision-making, not just the simple approval chains “workflow” used to describe.12

It is worth being honest about where this is, and is not, working well. Gartner also warns that by 2027, fewer than 10% of organisations that have implemented agentic AI within their ERP systems will have realised significant measurable value from it.6 The pattern that tends to work is agents operating in the periphery against clean, well-governed core data, not agents crammed inside the core expecting the data quality and governance problem to solve itself. That is a governance point as much as a technical one: an agent acting against poor-quality or poorly understood data will act on it just as confidently as it would on good data, which is exactly why the discipline in the sections above (a clean core, properly integrated peripheral systems) matters more, not less, as AI becomes part of the landscape.

Where AI belongs relative to the ERP boundary is the subject of our first white paper, ERP after AI: where structured discipline meets unstructured intelligence.

That leaves the upgradability fear, which deserves a direct answer, because it is the whole reason the layers matter. Upgradability is protected by where you build, not by refusing to build. Tailoring that sits in the ERP’s own customisation layer rides on top of the core by design; tailoring that sits in the surrounding landscape reaches the ERP through API layers that are built to be backward-compatible. SYSPRO’s own e.net Solutions layer is built on that principle (SYSPRO documents its “version-independent functionality, ensuring compatibility across all versions”), as are the API versioning approaches SAP, Oracle, Microsoft, and NetSuite all document.7 What you build in those layers should not normally break when SYSPRO upgrades. Where changes do happen, they are typically small, manageable adjustments rather than a rebuild. The upgrade pain people rightly fear is real, but it belongs to core customisation specifically, which is exactly the layer this paper argues you should leave standard.

Get the next white paper first

Practitioner perspective on ERP, AI and manufacturing operations, written by the team working across 100+ SYSPRO customer system landscapes. No product pitches.

Subscribe

What this means for your operation

None of this starts with a technology decision. It requires clarity about your own system landscape, and three questions are a reasonable place to start. The honest answer to each sits with you and your team, not with us: what it takes is time set aside and the willingness to be precise rather than general about your own operation. Where an outside perspective would help you get there faster, a partner can help you see it more clearly.

Where are you genuinely differentiated, and where are you just meeting the baseline? This is the most important question, and the hardest to answer honestly. Where do you run comfortably on standard SYSPRO because there is nothing special about how you do it, and where have you learned, over the years, that you do not do it like the standard process because your way is genuinely better for your business? The “why” matters more than the “what”: a gap that exists because of a real operational edge is worth investing behind; a gap that exists only because a process was never revisited is a candidate for coming back to the baseline, not building past it.

Where you do need to build beyond the baseline, which layer should it live in? There are three honest options, not two: the ERP core, the ERP’s own upgrade-safe customisation layer (configuration, custom panes and fields, in-ERP workflows), or a system around it talking to SYSPRO via stable APIs. The core is the layer to protect: the closer a decision sits to financial reporting, compliance, or master data integrity, the stronger the case for leaving it standard. Everything else is a question of which of the two safe layers fits best: tailoring that stays close to the ERP’s own data and screens often belongs in SYSPRO’s customisation layer, while deeper, process-specific logic usually belongs in a properly integrated system around it. The workflow lens is a useful test: as AI develops, workflows that sit outside the ERP increasingly need to integrate back into it, and that is often where the richer differentiation genuinely belongs. The one option to rule out in almost every case is customising the core itself.

Is your system landscape integrated as one system, or fragmented? Most SYSPRO environments already have a fair amount living around the core. The question is whether that is properly integrated so the whole functions as one system, or whether integration debt is quietly building up: systems that were connected once, for a specific need, and have not been revisited since SYSPRO itself moved on. Data sovereignty and API governance matter more as AI reads this data at higher frequency, and for South African businesses that is a live, practical question rather than an abstract one.

That last point has a South African dimension worth naming directly. Nearly half of South African enterprises, 49%, are now creating dedicated AI budgets.10 AI and IoT investment is projected to contribute R380 billion to South African manufacturing GDP by 2030.11 Those numbers describe momentum, not certainty, which is exactly why the audit above is worth doing deliberately, on your own terms, rather than reactively once the pressure to move is already on you.

A bridge in action

The Lancea team does not just advise on building beyond the baseline. The team has built parts of it, and the products are worth naming as a working example of the pattern rather than an abstract argument.

AGX is an AI-generated experience layer for SYSPRO: a conversational, AI-native way to work with ERP data without touching the SYSPRO core itself.

Tempo addresses inventory planning and procurement, the exact “instant visualisation of changing scenarios” gap described earlier in this paper, solved around SYSPRO rather than inside it.

CuroQuip covers equipment and asset maintenance and field service, a domain SYSPRO’s standard core is not built to specialise in.

TRX is a low-code dashboard and workflow platform, a direct, practical answer to the “which layer should workflow tailoring live in” question from the previous section: a periphery tool, not a core customisation.

Each of these exists because a customer had a real gap of exactly the kind described in this paper: a process that mattered to their competitive position, where standard SYSPRO best practice was only a baseline, and where building beyond it made more sense around the core than inside it. None of the four were built as generic products first and found a use case afterwards; each came out of a specific operational need, in a specific customer’s system landscape.

None of this is a case for customising your ERP core. It is the opposite: four different ways of building beyond the baseline around SYSPRO while keeping the core standard, built by a team that works inside SYSPRO environments every day and has had reason to solve each of these problems for real customers. Where differentiation is better handled inside the ERP’s own customisation layer, that is equally part of the same discipline: the point is never to touch the core.

The next step, if any of this is live for your business, is not a product decision. It is a conversation about which of your processes are actually your differentiator, and where the systems supporting them should live. That conversation starts with your business and your operation, not with what Lancea happens to build; what the team has learned from building AGX, Tempo, CuroQuip, and TRX is offered here because it may be useful to that conversation, not as a pitch in place of it.

Build beyond the baseline, deliberately

“Should you customise your ERP?” was always the wrong question. The right one starts from the fact that your business is unique, and asks how your systems can support the differentiated way of operating that has taken you years to build.

Three things are true at once. Standard ERP is genuinely good, and best practice is a real, valuable baseline: for the parts of your business that look like everyone else’s, staying standard is the right call, not a compromise. But best practice is only a baseline; in the domains that make you competitive, matching the field is not the goal, and your systems have to be built past it. And that building belongs in the layers designed to carry it safely (the ERP’s own customisation layer, or a properly integrated system around it), but not the core. AI agents are joining that landscape now, at real pace, and the businesses that treat this as a question of how to build beyond the baseline rather than a blunt “customise or don’t” will be the ones ahead of it.

The fact that you will have to build your systems around your processes, in some form, is a given. Every business that takes its operations seriously ends up doing this, whether it names the decision or not. The only real question is whether you do it deliberately (around a stable, well-governed core, in the layers designed to be tailored) or by accident, one workaround at a time, until something reaches into the core that should never have been touched.

That decision sits with you and your team, not with any vendor or implementation partner. The Lancea team’s role, where it has one, is to empower that decision: grounded in what SYSPRO actually does well, honest about what customisation costs and what it buys, and clear about which layer of the landscape around and on top of your ERP is the right place to build beyond the baseline. That is what we mean when we say innovate within a stable core, integrate around it deliberately, and elevate the operation your systems were built to support.

Which layer does your differentiation belong in?

The next step is not a product decision. It is a conversation about which of your processes are actually your differentiator, and where the systems supporting them should live. Talk to the team working across 100+ SYSPRO customer system landscapes.

Start the conversation

References

1. Panorama Consulting Group (2008; 2020). 2008 ERP Report Part III. Panorama Consulting Group. The 2020 ERP Report. Panorama Consulting Group. ↩
2. Airbnb Newsroom. Sharing More About the Technology That Powers Airbnb. Airbnb. SiliconANGLE (June 2023). Uber’s real-time architecture represents the future of data apps. SiliconANGLE. Finale Inventory. Amazon Warehouse Management System: Technology & Features. Finale Inventory. ↩
3. McKinsey & Company. The ERP platform play: Cheaper, faster, better. McKinsey & Company. ↩
4. Deloitte. The intelligent core: AI changes everything for core modernization. Deloitte Tech Trends 2025. ↩
5. Pemeco Consulting. Composable ERP Risks: Why Microservices Fail Without a Strong Core. Pemeco Consulting. ↩
6. Rambase, reporting Gartner. Gartner® Predicts 2025: Revisit ERP strategies to prepare for the future. Rambase. ↩ ↩
7. SYSPRO. SYSPRO e.net Solutions: Integration Framework. SYSPRO. SYSPRO (2025). Developer Considerations: SYSPRO e.net Solutions. SYSPRO 8 2025 release. SYSPRO (2023). Best Practice: Connecting to SYSPRO. SYSPRO 8 2023 release. SAP, Oracle, Microsoft, and NetSuite each publish comparable versioned API documentation: SAP S/4HANA API versioning. Oracle REST API versioning. Microsoft Graph versioning and support policy. NetSuite SuiteTalk REST Web Services. ↩ ↩ ↩
8. Mordor Intelligence. Workflow Automation Market – Size, Report & Forecast. Mordor Intelligence. ↩
9. Grand View Research. Intelligent Process Automation Market Size Report, 2030. Grand View Research. ↩
10. Dell Technologies (Q2 2024). Innovation Catalyst Research: 49% of South African enterprises creating dedicated AI budgets. As reported by Intelligent CIO Africa (January 2025). ↩
11. Tech in Africa (2025). AI Adoption in Africa 2025: South Africa Leads, Others Catch Up. Tech in Africa. ↩
12. Hyland Software. What is Process Automation? Hyland. ↩