Quick answer: SaaS ERP generally puts infrastructure maintenance and standard service updates with the vendor. On-premises ERP leaves the operating stack with your organization unless you contract those tasks out. Hosted ERP falls between them: renting servers does not automatically include ERP patching, backups or recovery. In every model, your organization must retain oversight of access, configuration and business recovery requirements. Confirm the division in writing—not from the word “cloud.” (learn.microsoft.com)
1. Start with the service boundary, not the server location
For an ERP selection team, the useful question is not simply “Where does it run?” It is “Which operational tasks are included, who performs them, and who proves they work?”
Distinguish three arrangements:
- SaaS ERP: You subscribe to a managed application. The provider operates the underlying service, while your team manages the customer-controlled settings and use of that application.
- Hosted ERP: Your ERP runs on infrastructure supplied by another organization. With infrastructure-only hosting, the operating system and application remain your responsibility. A managed-service agreement may transfer additional tasks.
- On-premises ERP: Your organization operates the stack, although contractors can perform specified duties. (learn.microsoft.com)
Ask each supplier to mark the boundary around infrastructure, database, ERP application, extensions and integrations. Then request a task schedule naming the responsible party for each layer.
Do not accept “our cloud team handles it” as an assignment. Record the organization, support route, coverage hours and evidence you will receive.
2. Build a responsibility matrix before comparing proposals
Use this as a starting template, not as a substitute for the service agreement. It applies shared-responsibility principles to ERP operations; actual backup and recovery obligations must come from the specific product policy and contract. (ncsc.gov.uk)
| Operational task | SaaS ERP | Hosted ERP | On-premises ERP |
|---|---|---|---|
| Physical servers and data-center facilities | SaaS provider | Infrastructure provider | Your organization or contracted operator |
| Operating-system maintenance | SaaS provider | Your team unless included in managed service | Your team or contracted operator |
| Standard ERP application updates | Provider operates its update process | Explicitly assign to your team or application manager | Your team or implementation/support partner |
| Database backup execution | Verify provider policy and included scope | Explicitly assign; do not infer from hosting | Your team or contracted backup operator |
| Restore request and authorization | Name customer approver and authorized administrator | Name customer approver and restore operator | Name customer approver and restore operator |
| Business validation after recovery | Assign finance and process owners | Assign finance and process owners | Assign finance and process owners |
| Roles, approvals and customer configuration | Customer oversight | Customer oversight | Customer oversight |
| Integration recovery and transaction reconciliation | Assign separately for each connection | Assign separately for each connection | Assign separately for each connection |
| Office connectivity and user-device readiness | Assign customer-side owners | Assign customer-side owners | Assign local and remote-access owners |
For each row, add four fields: performs the work, approves the action, verifies the result, and provides escalation.
For example, a hosting company might restore a database while your ERP partner repairs application services and finance decides whether posting can resume. Write those handoffs explicitly. Otherwise, each supplier can complete its own task without anyone accepting the end-to-end business outcome.
3. Separate availability from recoverability
Availability concerns whether a workload remains usable through failures. Disaster recovery concerns restoring it after a major disruption. Neither is fully described by a backup schedule. Microsoft’s reliability guidance distinguishes these disciplines and calls for recovery requirements at the business-flow level. (learn.microsoft.com)
Use three separate questions:
| Question | What to document |
|---|---|
| How is service availability measured? | Covered service, measurement period, exclusions and contractual remedy |
| How much recent data could we accept losing? | Recovery point objective, or RPO |
| How long could the process remain unavailable? | Recovery time objective, or RTO |
RPO expresses acceptable data loss as a period of time. RTO expresses acceptable downtime, with “downtime” defined for your workload. Both are objectives to establish and validate—not evidence that a particular subscription achieves them. (learn.microsoft.com)
For a concrete SaaS example, Microsoft’s Dynamics 365 Business Central online service overview states a financially backed 99.9% uptime commitment for paid production environments and points readers to the applicable SLA terms. Do not interpret that percentage as your restore deadline or allowable data-loss window. (learn.microsoft.com)
Define your own recovery acceptance point: perhaps “authorized staff can release shipments, post invoices and reconcile queued orders,” rather than merely “the login page responds.”
4. Check what the backup actually restores
Product-policy example, verified October 26, 2026: Microsoft documents automatic backups with 28-day retention for Business Central online production and sandbox environments. Its service overview also describes geo-redundant backups and provider-managed recovery following a full regional outage. These are online-service statements, not promises for a separately hosted or on-premises installation. (learn.microsoft.com)
Customer-requested recovery has its own boundaries. Business Central’s restore documentation says that restoring creates a new environment, restricts self-service restores to the original Azure region and localization, and does not restore a linked Power Platform environment. It also documents integration cleanup during restoration. (learn.microsoft.com)
That distinction matters: provider disaster recovery and a customer restoring an earlier database state are different procedures.
Ask these questions for every deployment proposal:
- Coverage: Are attachments, extensions, configuration and external document stores included?
- Retention: How far back can you recover, and what happens after a record or environment is deleted?
- Granularity: Can you recover one record, one company or only an entire environment?
- Authority: Who may request, approve and perform a restore?
- Protection: Who can alter or delete backups, and how is access controlled?
- Dependencies: What must happen to identity services, interfaces and scheduled jobs?
- Evidence: Can the supplier demonstrate the supported recovery process in an authorized test environment?
Treat long-term record retention as a separate requirement. Ask how required historical records remain accessible when operational backup retention expires.
5. Provider-managed updates still need business testing
In Business Central online, Microsoft manages application and platform updates. Administrators or partners use the administration center to control supported scheduling options and notification recipients. That is a division of work—not a transfer of every update-related decision to Microsoft. (learn.microsoft.com)
Microsoft also documents preview sandbox environments for reviewing functionality and validating extensions before a major update. (learn.microsoft.com)
Build an update checklist around your actual processes:
- Assign a release owner. Someone must receive notices and coordinate suppliers.
- Select representative transactions. Include order entry, receipts, shipments, invoicing and financial reporting where relevant.
- Test dependencies. Include extensions, interfaces, printing and scheduled processing.
- Record acceptance criteria. Define what must work before business owners accept the release.
- Prepare the incident route. Identify who handles a failed test or post-update disruption.
Ask hosted and on-premises providers the same questions, but also establish who obtains, tests and installs each layer’s updates.
Avoid promising a rollback that the service does not support. Business Central’s restore policy, for example, contains version restrictions and automatically applies the latest available hotfix to restored Marketplace and Business Central apps. A restore is therefore not necessarily an exact reversal of an update. (learn.microsoft.com)
6. Work through a distributor outage before signing
Hypothetical example—not a vendor performance claim: A distributor loses ERP access at 10:00 a.m. Its planning targets are an RPO of 15 minutes and an RTO of two hours for order processing.
Suppose the proposed recovery point is 9:45 a.m. and the service becomes available at noon:
- The recovery point is 15 minutes before the incident, matching the assumed data-loss window.
- Noon is the technical restoration deadline under the assumed two-hour target.
- If business validation requires another 30 minutes, usable operations resume at 12:30 p.m.—outside that target.
This illustrates why the definition of “recovered” must include the business activities you intend the RTO to cover. Recovery guidance calls for testing both technical recovery and the associated human processes. (learn.microsoft.com)
Before approving any restore, give each party specific questions.
IT: What failed?
Determine whether the problem is the ERP service, office connection, user identity or an integration. Remote applications can experience network interruptions and timeouts; a connectivity symptom does not by itself establish database damage. (azure.microsoft.com)
Provider or hosting operator: What action is justified?
Request the incident scope, supported recovery options, proposed recovery point, affected dependencies and next update time. Ask whether this is provider failover, application repair or a customer-authorized restore.
Finance: What needs reconciliation?
Identify orders, invoices, payments and other transactions potentially affected by the selected recovery point. Decide who approves re-entry or correction after comparison with approved source records.
Operations: What happened outside ERP?
Check physical shipments, warehouse activity and orders accepted through other channels. Assign ownership of queued transactions before interfaces restart.
Run the same scenario against each proposal. A SaaS supplier, hosting operator and internal IT team may divide the work differently; your acceptance criteria should remain explicit.
7. Avoid these mistakes—and require a practical handover
Use the following checks before selecting a deployment model or accepting operational handover.
Mistake: treating hosting as complete management.
Require separate ownership for operating-system maintenance, database care, ERP updates, backups and restoration.
Mistake: accepting “backup successful” as recovery evidence.
Request an authorized recovery exercise with recorded results, exceptions and business-owner acceptance. Microsoft’s recovery guidance explicitly recommends testing restoration integrity and duration. (learn.microsoft.com)
Mistake: assuming the provider controls customer settings.
Review privileged accounts, approvals and integration credentials. NCSC guidance emphasizes that customers retain responsibility for securely configuring their chosen services and determining whether those services meet their needs. (ncsc.gov.uk)
Mistake: recovering the database but ignoring connected systems.
Require an interface restart and reconciliation checklist. Business Central’s documented restore boundaries demonstrate why restoring one environment does not automatically restore every linked service. (learn.microsoft.com)
Before approval, collect:
- A signed responsibility matrix.
- The applicable service description, backup policy and SLA.
- Business-approved RPO and RTO requirements.
- A tested recovery runbook and escalation route.
- An update-testing owner and representative transaction checklist.
- A plan for customer-side connectivity and identity failures.
- A reconciliation and business-release checklist.
Choose the arrangement whose documented responsibilities your organization and suppliers can actually perform. The strongest proposal is not the one that says “fully managed” most often; it is the one that leaves the fewest unresolved operational handoffs.
Read next: After ERP Go-Live: Build a 90-Day Stabilization and Improvement Backlog