Everything You Wanted to Know About ERP* (*But Were Afraid to Ask), Part 3: Do I Choose Cloud or On Premises?

The (literal) million-dollar question.

And where budgets can go to die. Or be saved.

This question also goes well beyond just your ERP system, to your business philosophy around your infrastructure, system management, and expense modeling. It’s your operating model, not just the software.

To clarify - for ERP, cloud refers to the OEM software-as-a-service (SaaS), subscription-based model. An ERP vendor will consider your environment on-prem even if you run it in your own tenant in a cloud service like Azure.

Questions to consider in determining a cloud ERP vs on-prem - these are the questions that actually decide your answer.

What is your current infrastructure planning and philosophy?

Are you all in on cloud? Don’t trust those big companies? Whatever makes sense for this particular thing we’re doing right now? These all play into the choice of whether you want to go with a SaaS or on-prem solution for your ERP.

What staff do you have to do system administration tasks for your ERP?

Do you have an extensive support staff for servers, OS, database, and ERP system tasks?

Or does your CFO do IT admin in his spare time?

If you have people already doing these tasks, on-prem might be more justified from a cost perspective. If you have a lean IT support system, a cloud ERP may ease some of the burden on that staff - although it is still not zero internal effort to support the system.

Cloud/SaaS does reduce infrastructure responsibilities, but ownership of the ERP operation does not move - it still belongs to the customer (you).

Some of those tasks in a cloud environment include:

• User/security management
• Batch job management
• Integrations
• User support
• Data access
• Monthly update cycle testing
• Servers to support local connectivity to the cloud

What they don’t really need to do:

• Hardware maintenance for a full ERP ecosystem
• OS/Database patching
• ERP patching (they need to be aware and do testing, but typically don’t have to perform the updates)
• Infrastructure monitoring

SaaS platforms also provide uptime Service Level Agreements (SLAs) which provide uptime guarantees and define the penalties if they aren’t met. They also allow for instant scalability - if you need additional users, or more storage, you just pay a little more and it’s instantly available.

Infrastructure security is part of this too - since the vendor owns the infrastructure, they have security teams working on things like intrusion detection, Distributed Denial of Service (DDoS) protection, security auditing (SOC2, GDPR, etc…). Most companies, especially small and midsize, will not have this level of security in place, so this can be a big upgrade - although, they still need to be aware that the application access and security roles are their responsibility.

SaaS should reduce infrastructure work - that doesn’t mean “no work”.

How often do you patch your ERP system?

Historically, in on-prem environments, patching of ERP systems was not necessarily a priority. Due to the interconnected nature of an ERP system, the testing required to install a single patch can be onerous and the longer it’s been since any kind of patching, the higher likelihood that more patches need installed (sometimes thousands), and the bigger the testing cycle may need to be.

For cloud environments, the good thing (and potentially bad thing) is that this choice is taken from you. There is typically a monthly patching cycle, with scheduled downtime once a month for the patching. This keeps the system as current as possible.

The cost shows up in the need to do monthly testing to validate nothing breaks. And sometimes it does. Also, extensions/customizations need to be considered in the testing as the underlying architecture and functionality they were designed on may change. Most months are fine – it’s the one month that’s not that is a problem.

For on-prem, it’s kind of the wild west. You can keep as up to date as the vendor makes available - but, in my experience, this tends to not happen. The most common scenario I’ve seen is not to patch unless a known bug arises, then do what needs to be done to address that. Outside of that, what usually happens is the minimum required incremental patching that’s more related to requirements around being able to use more modern OS and database platforms as the underlying ERP technology ages.

What are your requirements for direct access to the underlying data of the ERP system?

For on-prem, you typically have direct access to your database platform, either through the database tools, or through data access technologies like ODBC. This allows you to access the data in real-time and build your own reporting/analytics directly.

In cloud environments, vendors don’t typically allow direct access to the underlying database. Infor, for example, uses a data lake to provide access to the data. The ERP system feeds data to the data lake, which can then be accessed by various tools (Application Programming Interfaces (APIs), Java Database Connectivity (JDBC), vendor-provided streaming connectors, or other technologies) to pull that data from the data lake to your own repositories. Functionally these can appear similar, but the cloud environment does require a few more hoops to jump through. There is also a potential cost depending on API executions or volume of data moved.

An important note - this means that you may not have real-time access to your data in those scenarios. It is often near real-time but there can be delays, depending on replication and Extract/Transform/Load (ETL) cadence (and capability).

Most vendors also provide their own data analytics and reporting platforms which may be sufficient (for example, Microsoft D365 environments can integrate directly to Power BI via the dataverse) - although that does tend to make it harder to disengage if you ever move from that vendor’s ERP platform.

That is another general consideration - in an on-prem environment, even if you move away from the platform, you still retain ownership and access to the database schema and data. In a SaaS environment you may be limited based on the access methods I mentioned above - it might be significantly more difficult to get a full copy of your data, especially if you haven’t already built a method to periodically gather the data.

Do you operate in different parts of the world that have different data access regulations?

If your business is strictly domestic, you may not think much about data residency or access regulations. But once you cross borders, the rules change - and they can change fast.

Government regulations like International Traffic in Arms Regulations (ITAR) in the U.S. or General Data Protection Regulation (GDPR) in the EU aren’t “nice to have” guidelines. They’re hard requirements with real teeth: things like fines, loss of export rights, reputational damage.

For on-prem environments you control where the servers live, how data is accessed, and who can see it. That can make compliance easier if you’ve got the staff and discipline to enforce rules, but it also means you will carry the entire burden of proving compliance.

In cloud ERP environments vendors do often provide compliance certifications (SOC, ISO, GDPR readiness) and region-specific hosting options (e.g., EU data centers). That can reduce some of the burden - but you also need to ask hard questions: Where exactly is my data stored? What region is the backup in? What’s the default access path?

I have also seen situations where a client has a cloud ERP with a custom built on-prem data analytics solution - and they did have to build the logic to address ITAR data access issues into the model of that custom data analytics solution.

If you’re multinational or even just selling into regulated industries, this is not an afterthought. Whether you’re cloud or on-prem, you need to know where your ERP data physically lives and how access is controlled. Otherwise, you could find yourself out of compliance before you even go live.

What level of customization do you expect and want to maintain?

In early ERP implementations (mid 1990s through early 2000s), customization was the name of the game. Vendors often provided base source code that allowed customers to change the fundamental aspects of the system themselves. This led to a lot of heavily customized systems that could not be patched or updated - at least without heavy testing and/or rework of the customizations.

If you’re in that situation - first, an on-prem upgrade isn’t going to be easy either. Also, that level of customization will likely not be possible in a cloud environment. This can lead to a lot of process reengineering to match processes to standard system functionality, building some extensions with the tools and functionality allowed by the vendor, and/or building 3rd party systems that perform your customized functionality and integrate with the cloud ERP.

As I mentioned, an on-prem upgrade in this situation will face similar challenges. Most ERP vendors don’t provide access to their core source code anymore. And functionality has changed enough, that even if you’re staying in the same product line, you will have to revisit every customization.

Here is a great question to ask yourself as you look at customizations - does this provide a real business advantage? Is this a differentiator vs your competitors? If yes, the customization may very well be worthwhile. If no, why are you looking at the customization?

For the not-worst-case - you just have minor customizations, or self-built modules that didn’t involve customizing the core source code - it is a minor version of the above. Check to see if it can be handled in standard functionality. If so, that’s the best path; if not, then validate that the customization is worthwhile and, if so, rebuild using the tools in your target system (on-prem or cloud).

What kind of 3rd party integrations do you have/need to connect to the ERP?

Do you like being on budget?

Not if you don’t have a real plan for your software integrations.

What are those 3rd party integrations you use?

Common integrations I’ve seen:

• EDI/Electronic Commerce
• Shop Floor Automation
• Manufacturing Execution Systems (MES)
• Warehouse Management Systems (WMS)
• Customer Relationship Management (CRM)
• Product Lifecycle Management (PLM)/Engineering systems
• Aftermarket Service
• Financial Consolidation
• Data Warehousing/BI/Analytics

Each of these things that you may use will need to be examined and a path for integration or replacement in the target system determined. And trying to shortcut this step is what will throw your budget and timeline into chaos.

In general, on-prem is going to be more flexible in how you can integrate, because you have full control over the environment, but that can lead to much less structured and disciplined ways to integrate (let’s just write data directly into our general ledger detail - nothing can go wrong there!).

In a cloud environment, integration pathways are much more strictly controlled, which might limit how you can integrate (or at least lead to some very creative solutions), but do provide governance, supportability, logging, etc…

“And trying to shortcut this step is what will throw your budget and timeline into chaos.”

Do you hear your CFO talk about CapEx and OpEx?

This is one of the biggest selling points of the cloud in general - how the costs are accounted for.

Capital expenses are the big expenses that can be depreciated over time (and often are financed).

Operational expenses are the expenses that are part of your daily business – think of things like paying your employees, your utilities, your rent.

In traditional on-prem ERP environments, the costs break down like this:

CapEx

• Hardware/infrastructure - can be millions of dollars, capitalized over the expected life of the hardware
• Upfront licenses - can be hundreds of thousands to millions of dollars, capitalized over the expected useful life of the system
• Some consulting costs - tens of thousands to millions, capitalized over the expected useful life of the system. Not all consulting costs can be capitalized - things like pure implementation tasks, process reengineering, and software development often can. Tasks that are more administrative in nature often can’t.

OpEx

• People to run the system
• Costs to run the system (electricity, facilities, etc)
• Software maintenance fees

For cloud/SaaS environments, almost all of those costs move from being capitalized to being operationalized:

CapEx

• Some consulting costs - tens of thousands to millions, capitalized over the expected useful life of the system. Not all consulting costs can be capitalized - things like pure implementation tasks, process reengineering, and software development often can. Tasks that are more administrative in nature often can’t.

OpEx

• ERP subscription
• The infrastructure costs, software licenses, and software maintenance all fall under this.
• People to run the system

The reasons for preferring CapEx to OpEx are going to vary by company (and, to be honest, are often above my head).

What I do know is this accounting difference can change how leadership sees the project and thinks about approval, even if the costs are ultimately close to the same.

It Depends

Like I said, the question of cloud vs on-prem is “it depends” (if you’ve been reading, that’s my mantra). It’s not about one being better than the other - it’s about what makes sense for the company, given things like philosophy, risk, and available resources (ok, I hate that word - people).

Cloud vs on-prem isn’t a purely technology decision - it’s an operating decision.

What’s next?

Please join us for Part Four - what do you need to think about when planning your ERP upgrade or implementation. And why that needs to be done before you sign any contracts (well, except for that consultative voice you might want in your court for getting those contracts right…).

If you found this valuable give us a like or subscribe, share with your friends, message or call us.