SaaS ERP misconceptions: the “on-premises thinking trap”

I think that probably for many of you January is the crazy month of the ERP go-lives (and probably not only restricted to the ERP).

During every go-live of Dynamics 365 Business Central SaaS, I often see the same situation: lack of mentality of cloud applications from the IT department of many companies. This post was born as a bit of a vent from the usual things I see or hear people say.

The most pervasive misconception is that SaaS is simply “on-premises software deployed elsewhere“. This fundamentally misses what makes SaaS architecturally and operationally distinct.

When IT teams migrate from an on-premises to a SaaS ERP (like Dynamics 365 Business Central), they often:

• Attempt to recreate their exact on-premises customization patterns in the cloud.
• Maintain separate infrastructure management practices (backup strategies, patch management, capacity planning).
• Continue building integrations with brittle, point-to-point logic designed for stable, infrequently-changing systems.
• Preserve organizational structures designed around managing physical infrastructure.
• Apply the same change management and testing rigor intended for monolithic, quarterly release cycles.

The Result: a SaaS deployment that costs like SaaS but performs and benefits like on-premises, without the control advantages of either.

“We’ll customize Business Central exactly like we customized our legacy ERP. We’ll modify tables, extend fields, and hard-code business logic into the platform. We don’t want to touch existing systems running inside the company from a long time.”.

SaaS ERP like Business Central uses upgrade-safe layering architecture and this means:

• Extensions are layered on top of the core system, not embedded within it.
• You gain agility instead of stability through controlled change.
• Customizations survive periodic updates without manual rework.

The misconception many people have is: constraints equal limitations. The reality instead is: constraints equal automatic compatibility and continuous innovation delivery.

The Paradox.

Organizations often choose SaaS to reduce IT complexity and cost. Yet by applying on-premises operational thinking, they recreate that complexity within the SaaS environment (paying SaaS subscription costs while maintaining on-premises operational expenses).

The solution is not choosing on-premises or SaaS. It’s choosing a governance and operational model that matches the platform architecture.

SaaS platforms like Business Central deliver maximum value when treated as continuous, managed services. Applying on-premises rigor creates the worst of both worlds: SaaS pricing with on-premises cost and complexity.

What organizations should do instead?

When adopting a cloud-based ERP, I think that a bit of shift in mindset is required. I always propose the following “best practices” to customers:

1. Always start with “accept as-is” as the default approach

Start with out-of-the-box Business Central functionality. Resist customization urges. Document deviations and evaluate whether the business process should adapt instead. This does not mean that you don’t need to customize (Business Central is fully customizable!) but simply that probably before planning a customization you should evaluate if a change (alias modernization) in your workflow is possible.

2. Shift IT roles from infrastructure to value

You’ve decided to adopt a cloud-based ERP solution, so from an IT perspective you should relax the focus on tasks like database administration, infrastructure and capacity planning and enrich your staff with power users, adoption specialists, business analysts.

3. Redesign integrations for the cloud

The adoption of a cloud-based ERP should have an impact also on the integrations with other systems you have in your corporate. Don’t pretend that systems will remain as is forever.

• Use APIs and events, not database connections.
• Avoid point-to-point connections when you have high-volume traffic.
• Implement idempotent, asynchronous patterns.
• Use cloud-native middleware (Azure Functions, Logic Apps).
• Build loosely-coupled integrations that survive updates.

The top common “errors” I see on every go-live.

Here is a list of the common “errors” or bad habits I see on quite every go-live:

• Bad or missing usage of cloud services.
• Job Queue tasks centralization: running all integrations inside Business Central (simply because “it’s easy”), with no horizontal scaling.🤮
• No event-driven architecture: polling instead of event-driven patterns, leading to infrastructure overhead.
• Ad-hoc integrations with no standards (integrations built ad-hoc by different teams; no clear architecture; no review process; each integration follows different patterns) leading to expensive maintenance ((different patterns require different expertise).
• Test data bloat: too much test companies active in the real production environment, simply because “we probably need them“.🤮
• No cloud governance: missing formal cloud ownership and policies for data retention

My two cents…

The solution is not choosing on-premises or SaaS. It’s choosing a governance and operational model that matches the platform architecture.

SaaS platforms like Business Central deliver maximum value when treated as continuous, managed services. Applying on-premises rigor creates the worst of both worlds.

The question isn’t “How do we customize SaaS to work like our on-premises ERP?” The question should be: “How do we change our operations to take advantage of what SaaS inherently provides?“

This is a leadership challenge, not a technical one. Your technical team will default to what they know. Your architects will try to recreate the patterns they’ve mastered. Your IT operations will manage the cloud like they managed the datacenter. This is human nature.

Your job as a leader is to say: “Not this time. This time we’re doing it differently. We’re building cloud-native. We’re thinking distributed. We’re optimizing for the platform, not for our legacy comfort.“. Your team will thank you in three years when they’re maintaining elegant systems instead of brittle ones. When they’re building features instead of fighting architecture. When they’re explaining cloud-native patterns instead of database query optimization.

Don’t be the architect of yesterday building yesterday’s solutions on today’s platform. Be the architect of tomorrow, building tomorrow’s systems right now. 🚀 The choice you make today determines the organization you become.