If your cloud ERP system goes down tomorrow, who gets blamed first?
Most cloud ERP conversations sound strangely similar after a while. Someone says the system is “fully managed.” Someone else mentions uptime guarantees. Then everyone quietly assumes stability is now Microsoft’s problem.
That’s usually the moment I start getting nervous.
One of the biggest misconceptions I see in cloud ERP discussions is the assumption that stability is automatically included with the subscription fee. The vendor manages the infrastructure. The implementation partner handles deployment. Internal teams attend training.
Then somehow the organization expects stability to emerge on its own, the same way people expect a budget spreadsheet to stay accurate after six departments start editing it.
That’s not how ERP works.
The reality is that the Cloud ERP responsibility model is shared, layered, and often misunderstood.
Microsoft Dynamics 365 Business Central can provide an incredibly stable foundation, but stability itself is still created through governance, ownership, testing discipline, and operational accountability.
That’s especially important for organizations evaluating what Business Central actually is in practice and how it centralizes control across finance and operations.
In this second article of my three-part series on cloud ERP risk, control, and stability, I’ll explain where responsibility actually sits in a cloud ERP environment, why “fully managed” isn’t the same as “fully stable,” and what leadership teams need to govern internally if they want cloud ERP stability to last beyond go-live.
Many organizations struggle with cloud ERP stability because ownership becomes blurred the moment leaders assume responsibility has shifted entirely to the vendor. That’s usually when governance gaps start forming inside the business itself.
One of the most common executive assumptions I hear is that the vendor owns ERP stability because the system lives in the cloud.
On the surface, that sounds reasonable. Microsoft manages the infrastructure. Updates are automated. Security protections are built into the platform. Uptime is contractually supported.
But there’s a major difference between infrastructure availability and operational stability.
A cloud ERP system can be technically operational while the business itself is struggling:
From the vendor’s perspective, the environment may be functioning exactly as intended.
But from the business perspective, stability has already broken down.
This misunderstanding creates real operational risk because it removes accountability from the organization itself. Once leadership assumes stability is externally owned, governance tends to weaken internally.
That’s also why Service Level Agreements are frequently misunderstood. An SLA may guarantee uptime and availability. It does not guarantee reporting accuracy, process consistency, operational discipline, or business continuity.
Those still belong to the organization.
That’s the part many organizations miss when evaluating the Cloud ERP responsibility model.
The short answer is all three.
The longer answer is that each party owns very different parts of stability, and confusion between those responsibilities is where most instability begins.
The Cloud ERP responsibility model only works when accountability is clearly defined across all layers.
Clear ERP roles and responsibilities in implementation are critical because poorly defined Cloud ERP implementation responsibilities almost always create instability later.
Stability in a cloud ERP environment depends on clearly defined ownership across the vendor, implementation partner, and client organization. Each layer plays a different role in maintaining long-term operational stability.
Microsoft is responsible for the infrastructure layer of Microsoft Dynamics 365 Business Central:
Microsoft itself describes cloud operations as a shared responsibility model, where infrastructure responsibilities shift to the provider while operational and configuration responsibilities remain with the customer:
That’s an important distinction because infrastructure reliability does not automatically create operational reliability.
Implementation partners occupy the middle layer.
Their responsibility includes:
This is where long-term stability often starts taking shape long before go-live.
I’ve seen stable organizations struggle because the implementation design introduced unnecessary complexity early. I’ve also seen organizations with messy operations become remarkably stable because the implementation focused on governance, simplicity, and process clarity from the beginning.
This is the layer executives most often underestimate.
Clients still own:
In other words, the client owns the business outcomes.
That’s why the Cloud ERP shared responsibility model is operationally important, not just technically important.
“Fully managed” is one of those phrases that sounds reassuring until you realize how differently people define it.
To the vendor, “fully managed” usually means:
To many executives, it sounds like:
Those are very different assumptions. The Cloud ERP responsibility model breaks down quickly when those assumptions are never clarified internally.
A cloud ERP environment can remain fully operational while the organization itself experiences instability through:
This is one of the biggest reasons why ERP implementations fail after organizations move to the cloud: The technology is often functioning correctly; it’s the operating model around it that’s not.
I’ve seen companies blame Business Central for problems that were ultimately rooted in:
That distinction matters because organizations tend to solve those problems differently.
Governance problems aren’t solved through infrastructure upgrades.
They’re solved through operational discipline.
Most instability doesn’t appear dramatically on day one. It usually starts quietly with small workarounds that somehow become permanent six months later.
At first, it looks manageable:
Then six months later, leadership realizes nobody fully trusts the system.
That’s where instability actually becomes expensive. And in most cases, the root cause isn’t the software itself. It’s the breakdown of ownership around it.
This is probably the single biggest issue I encounter.
When nobody clearly owns:
then instability spreads quietly across the organization.
ERP stability isn’t created by software alone. It’s maintained through accountability structures. A strong Cloud ERP responsibility model depends just as much on operational ownership as platform reliability.
Cloud ERP environments evolve continuously.
Updates happen regularly.
Processes change.
Integrations expand.
Reporting requirements evolve.
Organizations that don’t validate changes prior to release eventually create instability themselves.
One of the most common cloud ERP implementation mistakes is assuming testing becomes less important because the platform is SaaS-based. In reality, continuous updates make disciplined testing more important than ever.
This is where things get precarious.
Many organizations try to recreate every legacy workflow inside the new ERP system instead of improving the process itself.
The result?
Customization isn’t automatically bad. But unnecessary customization often introduces fragility into environments that were supposed to become more stable.
This is the issue that ties all the others together.
Without centralized governance:
Cloud ERP instability is rarely caused by technology failure.
It’s caused by governance erosion.
The organizations that maintain long-term ERP stability approach cloud ERP differently from the beginning.
They don’t treat cloud as outsourced accountability.
They treat it as an operating model that requires stronger internal discipline.
The organizations that handle the Cloud ERP responsibility model well usually govern ERP long after implementation ends.
Every critical process should have a named owner.
Not a department...
Not a committee...
An actual accountable person.
This includes ownership for:
When nobody owns the outcome, the outcome deteriorates over time.
One of the biggest operational mistakes I see organizations make is allowing uncontrolled process changes after go-live.
Small changes accumulate quickly:
Without governance, complexity grows faster than stability.
That’s why organizations need:
According to Deloitte, cloud ERP environments require stronger internal controls and governance maturity because operational risk shifts into configuration, access, and process management layers.
This is where many cloud ERP conversations become overly technical.
ERP stability is not primarily an infrastructure discussion... it’s an operating discipline discussion.
McKinsey has written extensively about how cloud transformation requires changes to organizational operating models, governance structures, and accountability systems.
The organizations that navigate that transition successfully tend to approach governance very differently from the start. They:
The software matters.
But discipline matters more.
This is the part executives sometimes don’t want to hear because governance is rarely the exciting part of ERP transformation. (Nobody ever schedules a kickoff meeting to celebrate stronger approval workflows.)
But governance is what prevents instability from spreading. The organizations that achieve long-term ERP stability usually have:
The organizations that struggle usually don’t.
That’s why I often tell leadership teams this:
Cloud ERP doesn’t remove operational responsibility.
In many cases, the Cloud ERP responsibility model simply exposes governance weaknesses that already existed inside the organization.
And honestly, cloud environments tend to expose those weaknesses faster because everything becomes more connected, more visible, and more dependent on consistent execution.
From a CFO perspective, instability becomes expensive fast.
And not just because of downtime, but also:
Those costs compound quietly.
Instability rarely stays isolated inside IT. Eventually it affects forecasting accuracy, operational predictability, and margin control.
That’s also why ERP system ownership responsibilities matter far beyond IT.
If finance doesn’t trust reporting, leadership slows down decisions.
If operations doesn’t trust inventory, manual workarounds expand.
If users don’t trust workflows, spreadsheets return almost immediately.
At that point, the organization may still technically have cloud ERP.
But operationally, stability is already eroding.
If no one owns stability, instability is guaranteed.
Cloud ERP stability isn’t delivered automatically by Microsoft, the implementation partner, or the software itself.
The Cloud ERP responsibility model only works when accountability remains active across the organization over time.
It’s created through:
Microsoft Dynamics 365 Business Central can provide an incredibly stable foundation. But the organizations that achieve long-term stability are usually the ones that treat ERP as an operational control system, not just a technology platform.
That mindset changes everything.
Before assuming your ERP environment is “stable,” ask:
If those answers are unclear, instability is probably already forming somewhere inside the organization.
Coming up in the final article of this series, I’ll take a closer look at why cloud ERP failures still happen despite modern platforms, and why many of those failures are visible long before the system itself gets blamed. And if you missed it, here’s my earlier article on how cloud ERP changes risk and responsibility.