ERP Vendor SLA Template: The Terms Worth Locking In Before You Sign

What Is an ERP SLA?

An ERP service level agreement is a contractual commitment that defines, in measurable terms, how a software vendor or implementation partner will perform after go-live. It converts marketing claims like 'enterprise-grade reliability' into specific promises: a target monthly uptime percentage, how quickly the provider will acknowledge and fix a critical incident, who gets called and in what order when a problem escalates, how often the platform is patched and updated, and what financial remedy you receive when those targets are missed. Without an SLA, every support dispute becomes a negotiation about goodwill; with one, it is a question of arithmetic against a published threshold.

The single most important framing for an SME is that you almost never deal with one SLA — you deal with two. The first is the software vendor SLA: the cloud availability and support guarantee published by the company that builds the platform (Microsoft for Dynamics 365, Odoo S.A. for Odoo Cloud, or the upstream open-source project policy for self-hosted Odoo). The second is the implementation partner SLA: the service contract with the consultancy or system integrator that configures, customizes, and supports your specific build. These cover different failure modes, are owed by different parties, and produce different remedies — and conflating them is the most common reason SMEs discover, mid-outage, that no one is actually on the hook to fix their problem.

This is distinct from hypercare, the time-boxed internal stabilization window in the first weeks after go-live. Hypercare is an operational phase you staff and run; an SLA is the commercial backbone that governs support for the months and years that follow. The two connect — hypercare's severity definitions and response targets should step down cleanly into your steady-state SLA at exit — but they are not the same instrument.

• →A vendor SLA governs the platform itself; a partner SLA governs your configured build.
• →Every commitment must be measurable (a number) and backed by a remedy (usually a service credit).
• →If a promise is not in writing with a threshold and a remedy, treat it as a marketing slogan, not a commitment.

The Two SLAs You Actually Need

Most ERP support disasters trace back to a single gap: the customer assumed the implementation partner's support contract covered cloud outages, or assumed the software vendor would fix their custom workflow. Neither is true. The vendor and the partner each own a distinct slice of the stack, and each publishes a distinct SLA. Your job during procurement is to identify which agreement covers which failure, and to confirm both exist before you sign the master services agreement.

The software vendor SLA (Microsoft Online Services SLA, Odoo Cloud SLA) is a published, largely non-negotiable document. It covers platform-level availability, the vendor's own infrastructure, and genuine product defects. It typically does not cover your configuration, your customizations, your integrations, or your data — and it almost always names the customer as responsible for those. The implementation partner SLA, by contrast, is a negotiated commercial contract. It covers the work product the partner built: configuration defects, report and workflow fixes, integration troubleshooting, and functional support. A managed-services or application-management agreement (AMS) extends this into ongoing proactive monitoring, release management, and continuous improvement.

Some SMEs add a third layer: a hosting or infrastructure SLA when Odoo is self-hosted on a cloud provider or managed server, where the host guarantees VM and network uptime but knows nothing about the Odoo application. In that model, three separate agreements must stack cleanly — host guarantees the VM, Odoo S.A. guarantees the source code and support policy, and the partner guarantees your build.

Uptime and Availability: What 99.9% Really Buys

Uptime is the headline number in every vendor SLA, and it is also the most commonly misunderstood. A 99.9% monthly uptime commitment — the standard for both Microsoft Dynamics 365 Business Central online and Odoo Cloud — sounds near-perfect until you do the arithmetic. 99.9% of a 30-day month allows roughly 43–45 minutes of unplanned downtime; over a year that compounds to about 8.76 hours. 99.5% allows nearly 3.7 hours a month. The number matters because it defines the ceiling of acceptable unplanned outage before the vendor owes you a remedy, and because the gap between 'we aim for' and 'we guarantee' is where most SMEs get burned.

Microsoft publishes a financially backed Service Level Agreement for Online Services that commits to a 99.9% Monthly Uptime Percentage for Business Central online and the other Dynamics 365 applications. Downtime is measured from Microsoft's own health monitoring using a user-minutes formula — (User Minutes − Downtime) ÷ User Minutes × 100 — so an outage that your users feel may not match what the status page records for credit purposes. Odoo Cloud states a 99.9% monthly uptime target (excluding planned maintenance), 14 retained backups for at least three months, and dual disaster-recovery objectives: for a permanent single-server failure, RPO 24 hours and RTO 6 hours; for a full data-center disaster, RPO 24 hours and RTO 24 hours. Odoo's own SLA page states these uptime and recovery figures are operational design objectives, not legally binding guarantees, and may be affected by exceptional events outside Odoo's control — so for self-hosted or partner-hosted Odoo you rely on the host and partner, not Odoo S.A.'s cloud SLA.

Three measurement choices quietly change what the uptime number means in practice. First, scheduled maintenance is almost always excluded from the uptime calculation — Odoo notes planned windows typically less than one hour every couple of months, announced by email or @OdooStatus; Microsoft carves out planned maintenance and factors outside its reasonable control. If you ignore that exclusion, your '99.9%' is not the real guaranteed operating window. Second, business-hours-only uptime is far weaker than 24/7 because overnight and weekend outages do not count. Third, monthly measurement smooths over a bad week, and the percentage is computed from the vendor's monitoring — not your users' experience — so regional degradations can fail to register. Practitioner commentary after major Microsoft 365 outages repeatedly notes the same pattern: the public status page can stay green while customers are down, because that page is the document the credit calculation runs off. Read the definition of downtime, what is excluded, and who measures it before you treat the headline as meaningful.

Service Credits: The Only Remedy That Matters

When a vendor misses an uptime target, the remedy in nearly every software SLA is a service credit — a percentage credit applied to your next invoice — rather than a cash refund or damages. This is by design: the SLA almost always states that service credits are the customer's 'sole and exclusive remedy' for a breach, which caps the vendor's financial exposure no matter how much the outage cost your business. Understanding the tier structure, the cap, and the claim process is therefore the single most commercially important part of reading an SLA.

Microsoft's Online Services SLA for Dynamics 365 uses explicit credit bands: monthly uptime below 99.9% yields a 25% service credit on the monthly fee for the affected service; below 99% yields 50%; below 95% yields 100%. Those bands appear in the Service Level Agreement for Microsoft Online Services (Dynamics 365 section) and are widely documented by practitioners reviewing Business Central commitments. Credits are not automatic — you (or your CSP partner) must claim them. For Microsoft Online Services other than Azure, the claim must generally be received by the end of the calendar month following the month in which the incident occurred (for example, a February 15 outage must be claimed by March 31); Azure claims follow a separate 60-day-from-billing-month rule. Partner channels often require you to raise the request within about 30 days of the invoice covering the outage month. Put a calendar reminder on finance and IT every month-end.

Worked example: a four-hour unplanned Dynamics 365 outage in a 30-day month is about 0.56% downtime (user-minutes basis), which drops monthly uptime to roughly 99.44% — enough to clear the <99.9% band and earn a 25% credit on that month's fee for the affected service, not cash damages for lost shipments or a delayed close. On a $4,000/month BC tenant that is a $1,000 credit; the operational cost is usually far larger. That asymmetry is why experienced negotiators treat the credit clause as a safety net and spend negotiating capital on a termination-for-cause right that triggers on a count of material availability failures in a rolling twelve months (for example, three qualifying incidents), not only on a monthly percentage that can hide short, frequent outages.

Odoo Cloud's published SLA emphasizes uptime and recovery objectives rather than a Microsoft-style public credit ladder; treat Odoo's figures as operational targets and push your partner or hosting contract for explicit credit tiers if money-backed remedies matter. Industry benchmarking of broader SaaS SLAs finds many deals still cap credits around 25% of the monthly fee and require catastrophic downtime to reach the top tier — cold comfort after a multi-day outage. For mission-critical partner SLAs where you have leverage, negotiate multi-tier credits escalating toward at least 50% for severe breach, plus termination for repeated breach rather than credits-only remedies indefinitely.

Response and Resolution Times by Severity

Uptime credits cover outages; response and resolution targets cover everything else — the day-to-day incidents, defects, and requests that make up the bulk of post-go-live support demand. A good SLA defines two distinct clocks for each severity level: a response time (how quickly the provider acknowledges the issue, assigns an owner, and begins work) and a resolution time (the target to deliver a fix or an approved, verified workaround). Confusing the two is a classic pitfall — a vendor that 'responds within one hour' but takes five days to resolve a critical defect has technically met a weak SLA while your finance close stalls.

The severity matrix should be defined by business impact, not technical complexity. A P1/Critical is a complete outage or a critical end-to-end process fully blocked with no workaround (cannot post financials, generate invoices, confirm shipments, run payroll). A P2/High is major functionality impaired across multiple users with a difficult workaround. A P3/Medium is a partial or single-user issue with an acceptable workaround. A P4/Low is a cosmetic issue, a how-to question, or an enhancement request. These definitions belong in your partner SLA before go-live, agreed in the same workshop that defines hypercare severity — because the steady-state SLA is the destination the hypercare targets step down into at exit.

The benchmarks below are representative practitioner guidance grounded in standard ITSM/ITIL tiering, not binding standards. Your actual contract — particularly the implementation partner SLA — defines the binding numbers, and for an SME these are negotiable in ways the vendor cloud SLA is not. Pay attention to the definition of 'business day' (some SLAs define a 12-hour or 8-hour business day, which quietly halves effective coverage) and to whether resolution targets are measured in business hours or calendar hours for P1 incidents. Also state who can declare severity (customer can raise; vendor may reclassify with written justification within a short window) so the partner cannot unilaterally downgrade a P1 to avoid the war-room clock.

Copy-ready severity matrix language for a mid-market partner SLA: 'P1: Production ERP unavailable or a critical end-to-end process (financial close, order-to-cash, procure-to-pay, payroll) fully blocked with no acceptable workaround; Response: 30 minutes, 24×7; Continuous effort until workaround or fix; Target restoration: 4 clock hours. P2: Major multi-user impairment with difficult workaround; Response: 2 business hours; Target: 1 business day. P3: Limited impact with workaround; Response: 1 business day; Target: 5 business days. P4: Cosmetic, how-to, or enhancement; Response: 2 business days; Scheduled into next release window.' Adjust hours to your industry (retail peak seasons, month-end close windows) and name the primary customer contact who can escalate a reclassification dispute.

Escalation Paths and Named Contacts

A response-time target is only useful if there is a defined path to escalate when it is missed. Every ERP SLA — vendor and partner — should include an explicit escalation matrix that names, by tier and timeframe, who gets contacted and in what order when a ticket is not progressing. The matrix has two dimensions: functional/technical escalation (moving up the support layers from L1 desk to L2 internal leads to L3 partner to L4 software vendor) and management escalation (moving up the org chart from the assigned engineer to a service delivery manager to an executive sponsor when a deadline slips or a relationship is strained).

Standard ITSM tiering gives the functional ladder. L1 is your internal help desk, super users, and floor walkers handling coaching, quick fixes, and logging. L2 is your internal functional and technical leads. L3 is the implementation partner or system integrator for defects, configuration, and complex fixes. L4 is the software vendor — Microsoft Support or Odoo Enterprise — for genuine product defects that require a source-code fix. Your partner SLA should state explicitly how an issue is handed from L3 to L4: who opens the vendor ticket, who owns the relationship with Microsoft or Odoo, and how the clock on your SLA pauses or continues while the vendor investigates. A common gap is an SLA that stops the clock the moment a ticket is 'escalated to the vendor,' leaving you with no leverage while a P1 waits weeks for a Microsoft hotfix.

The management escalation ladder is where you protect the commercial relationship. Insist on named contacts at each rung — a named service delivery manager for day-to-day issues, a named practice lead or director for repeated SLA breaches, and a named executive sponsor for disputes or relationship-threatening problems. Tie escalation timeframes to the severity matrix: if a P1 is not resolved within its target window, it should auto-escalate to the next management tier within a stated number of hours, not wait for someone to notice. For SMEs, where a single account manager often wears several of these hats, the minimum is one named primary contact, one named escalation contact, and a documented after-hours pathway for genuine emergencies.

1. 01
   Agree the functional ladder before go-live

   Write L1 through L4 into the partner SLA with named owners. State who opens the vendor ticket at L4 and whether your SLA clock pauses while the vendor investigates — a clock that stops at 'escalated to vendor' can strand a P1 for weeks with no leverage.

2. 02
   Set auto-escalation triggers tied to severity

   Define what happens when a target is missed: a P1 unresolved past its resolution window auto-escalates to the service delivery manager within a stated number of hours, then to the executive sponsor if still unresolved. The trigger should be automatic, not reliant on someone noticing.

3. 03
   Name management contacts at every rung

   A named service delivery manager, a named practice lead for repeated breaches, and a named executive sponsor for disputes. For an SME this may compress to two people, but the accountabilities and contact routes must be explicit and documented.

Patch, Update, and Release Cadence

Patch and update cadence is the SLA dimension most SMEs overlook until a mandatory update breaks a customization or a security patch lands mid-month-end-close. Modern cloud ERP is continuously updated by the vendor — there is no 'stay on this version forever' option — so your SLA and support contract must address three questions: how often the vendor releases updates, who applies them and on what schedule, and how long any given version stays supported before you are forced to upgrade. The answers differ sharply between Microsoft and Odoo, and they drive your regression-testing burden and your upgrade budget.

Microsoft Dynamics 365 operates a continuous 'One Version' update model. Finance and Operations apps receive roughly seven service updates per year on a monthly cadence (with scheduled skip months), while the broader Dynamics 365 and Power Platform release wave system ships major new feature sets twice yearly, in April and October, with early-access features available roughly four to six weeks before general availability. These updates are mandatory and auto-applied by Microsoft, but customers get options to pause or reschedule a single update within a defined window and to validate in a test environment first. Business Central online similarly receives regular platform and application updates. The implication for your SLA: you need a partner contract that covers regression testing on each update cycle, a defined change-management window, and a clear position on who owns break-fix when a Microsoft update conflicts with a customization.

Odoo's cadence is annual rather than continuous. Odoo S.A. ships a new major version each year (typically in October), and each major version receives approximately three years of standard support including helpdesk support, bug fixes, and security updates. Active development concentrates on the latest two versions, meaning older-but-supported versions get slower fixes. A significant change to Odoo's policy means that beyond the three-year standard window, extended support is now subject to a mandatory paid arrangement — reported as roughly a 25% additional fee on the annual subscription, applying to versions older than three major releases. For Odoo, then, the SLA question is less about update frequency and more about lifecycle: when does your current version lose free security patches, and what is the cost and timeline to upgrade to a supported version before that cliff.

Exclusions: What Quietly Voids the SLA

The exclusions clause is where uptime percentages go to die. Every ERP SLA — vendor and partner — lists circumstances under which downtime or a missed target does not count toward the calculation, and the breadth of these exclusions determines how much real availability the headline number actually guarantees. A 99.9% commitment riddled with exclusions for planned maintenance, internet problems, and 'any third-party dependency' can deliver materially worse real-world uptime than a cleaner 99.5% agreement. Read the exclusions before you read the uptime number.

The standard exclusions fall into four categories. Planned and scheduled maintenance is the largest — vendors carve out defined maintenance windows (often a few hours per month, sometimes weekly overnight slots) during which downtime does not count, and many also exclude any outage that customers were notified about in advance. Force majeure and events outside the vendor's control — natural disasters, regional network failures, government action — are broadly excluded. Customer-caused issues are excluded: misconfiguration, failed customizations, incorrect data loads, credential mishandling, or unsupported client environments. Finally, dependencies are excluded: problems caused by third-party services the customer integrated (a payment gateway, a shipping API, a third-party SaaS connector) sit outside the vendor's commitment.

Two exclusion patterns deserve particular scrutiny in negotiation. The first is the maintenance-window math: if a vendor excludes, say, eight hours of planned maintenance per month, the effective guaranteed window is closer to 99.0% than 99.9% for any business that operates outside those hours — and a global SME with users across time zones may find no window is truly 'off-hours.' Push for maintenance windows that are bounded, published in advance, and minimized, and for a target that is calculated against total calendar time minus only a tightly defined maintenance allowance. The second is the cascading-dependency exclusion: in a modern ERP that integrates with a dozen SaaS tools, an exclusion for 'any third-party service' can swallow a large share of real outages. Where a dependency is mission-critical, ask the vendor to commit to a defined MTTR for restoring the integration even if the root cause is third-party, or to publish the dependency's own SLA as part of the chain.

• →Planned/scheduled maintenance windows are usually excluded — calculate the effective guaranteed uptime, not the headline.
• →Customer-caused issues (misconfiguration, bad data, failed customization) are excluded — own these internally.
• →Third-party dependencies are excluded — for mission-critical integrations, negotiate a restoration commitment, not just an exclusion.
• →Force majeure is broadly excluded and rarely negotiable; budget continuity and disaster recovery separately.

Security Incident Notification Timelines

Uptime and severity clocks cover availability and functional defects. Security incidents need their own SLA clocks — and many ERP MSAs either omit them or bury vague 'prompt notice' language that is useless under regulatory pressure. A security incident SLA defines what counts as an incident (confirmed unauthorized access, ransomware, credential dump, data exfiltration, or a vulnerability under active exploitation), who notifies whom, in what channel, and how fast. Without those numbers, you discover a partner or SaaS breach from a journalist, not from the party holding your data.

Regulatory floors set the outer bound, not the commercial target. Under the GDPR, controllers must notify the supervisory authority of a personal-data breach without undue delay and, where feasible, within 72 hours of becoming aware of it — so if your ERP vendor or implementer is a processor, your contract must force them to notify you early enough that you can still meet the 72-hour window (commonly within 24–48 hours of their awareness, with initial notice followed by a fuller report). Sector rules (HIPAA breach notification, NIS2 for essential/important entities in the EU, state breach laws in the US and Canada) can impose shorter or additional clocks. Your DPA and SLA should cross-reference each other: the DPA owns legal roles and personal-data duties; the SLA owns measurable notice and cooperation targets.

Template language mid-market buyers should demand: initial notice to named security contacts within 24 hours of confirmed or reasonably suspected material incident affecting customer data or production access; severity classification within 4 hours of notice; written updates on a defined cadence (for example every 4 hours for P1 security until containment, then daily); a post-incident report within 10 business days covering root cause, systems affected, data categories, remediation, and residual risk; and cooperation with customer forensics, regulators, and insurers at no premium rate during the incident window. Require the vendor to maintain an incident response plan, named 24/7 security contact path, and evidence of tabletop or IR testing at least annually. Pair this with the severity matrix so a security P1 is never treated as a P3 ticket because 'the system is still up.'

Exit, Data Portability, and Source Code Escrow

The day you sign an ERP contract is the day you should begin planning your exit from it. ERP relationships run for years, and the most expensive moment to negotiate data ownership, export rights, and transition assistance is the moment you actually need them — when you are unhappy, when the partner has changed hands, or when you are migrating to a new platform. Lock these terms into the agreement up front, alongside the SLA, because they are the ultimate commercial protection: the credible right to leave is what keeps a vendor and partner responsive for the life of the contract.

Data portability is the floor — and most buyers still under-negotiate it. Enterprise SaaS contract benchmarking of hundreds of mid-market and enterprise deals signed in 2025–2026 found only about 23% of contracts carried an explicit data portability clause, only about 18% specified a machine-readable format, and only about 11% included vendor-assisted migration support. The contract should state that you own your data; that you can export at any time (not only at termination) in open, machine-readable formats such as CSV, JSON, or XML without proprietary converters; that API access continues during transition; and that export covers transactional records, configuration, customizations, metadata, and — increasingly — AI-derived outputs built solely from your data. Watch for clauses that grant the vendor a broad license to your data or that limit export to 'customers in good standing.'

Windows matter as much as formats. Market standard export delivery is often 30 days after request; enterprise and complex ERP migrations routinely push for 90 days (sometimes 120–180 for large regulated datasets). Post-termination read-only access for 30–90 days prevents the nightmare where the contract ends before the new system is ready. Termination assistance should obligate the vendor or partner to a defined transition period — commonly at least 90 days of continued support, documentation, and cooperation with your new provider at a pre-agreed rate. Require written certification of data destruction from production and backups within 30–60 days after the transition window closes.

Regulatory tailwinds strengthen the mid-market hand. The EU Data Act (Regulation 2023/2854) became fully applicable on 12 September 2025; Chapter VI requires data-processing service providers (including many SaaS/ERP hosts serving EU customers) to support switching, maintain continuity during migration, move toward elimination of switching charges (full elimination targeted by January 2027), and support open, interoperable export formats. Even if you are a non-EU buyer, use those obligations as a negotiation benchmark in the MSA. Source code or technology escrow remains the complement for vendor failure: place source (or, for SaaS, schemas and critical configuration) with a neutral third party, releasable on bankruptcy, product EOL, or uncured material breach. Data export and transition assistance handle planned departures; escrow protects against the vendor disappearing entirely.

Negotiating Your SLA: The Red Lines

Vendor cloud SLAs (Microsoft's, Odoo's) are take-it-or-leave-it documents you rarely get to redline, but the implementation partner SLA and the master services agreement wrapping both are negotiable — and that is where an SME earns most of its commercial protection. The clauses below are the ones experienced buyers treat as red lines: the difference between a support relationship that holds up under stress and one that collapses into finger-pointing at the first serious incident. Push hardest on these during procurement, when you still have leverage, rather than at renewal when switching costs have already mounted.

First, get the SLA in writing before you sign — never accept a verbal 'we'll take care of you.' ERP contract checklists for CIOs and CFOs consistently list the SLA, data portability, price caps, and escrow among the clauses to demand before signing, because an ERP contract is not a standard procurement and the default terms favor the vendor. Second, cap price escalation: maintenance and support fees are routinely subject to annual increases, so negotiate a fixed cap (commonly tied to a published index like CPI, or a hard percentage ceiling such as 3–5% per year) so your five-year support cost is predictable. Third, secure audit rights: the right to request, periodically, the vendor's actual uptime and SLA-compliance records rather than relying solely on the vendor's self-reported credits.

Fourth, watch the interaction between the SLA's 'sole and exclusive remedy' clause and the agreement's liability cap. A well-drafted vendor agreement makes service credits your only recourse for an uptime breach while separately capping total liability — sometimes at a single month's fees — for everything else. Together these can mean that a catastrophic, business-threatening outage yields a credit of a few hundred dollars. Where you have leverage, push for the liability cap to exclude certain categories (data loss, breach of confidentiality, gross negligence) and for the right to terminate for cause — repeated or sustained SLA breach — without penalty. Prefer an incident-count trigger (for example, three material availability failures in any rolling twelve months) over a pure monthly-percentage trigger, which can hide frequent short outages. Finally, ban auto-renewal surprises: require explicit notice windows for renewal and non-renewal, and the right to terminate for convenience on defined terms, so you are never locked in by silence.

Sample mid-market redline snippets to paste into the partner MSA negotiation (adapt with counsel; not legal advice): (1) Severity ownership — 'Customer may designate Severity; Provider may reclassify only with written justification within two business hours; disputes escalate to named executives within four hours for P1.' (2) Clock pause — 'SLA clocks pause only while Customer fails to provide reasonably requested access or information; clocks do not pause solely because a ticket is escalated to the software vendor.' (3) Exit package — 'Upon termination for any reason, Provider shall for ninety (90) days maintain read-only production access, deliver complete exports in CSV or JSON within thirty (30) days of each request, and provide transition assistance at rates no higher than the then-current support rates.' (4) Security notice — 'Provider shall notify Customer's security contacts within twenty-four (24) hours of becoming aware of a material security incident affecting Customer data or production access.' (5) Credits claim — 'Provider shall document Monthly Uptime and notify Customer of any credit-eligible month within fifteen (15) days of month-end; Customer retains the right to claim credits under the software vendor SLA through its CSP or licensing channel.'

Dynamics 365 vs Odoo: How the SLAs Differ

The two platforms an SME is most likely to buy take fundamentally different approaches to the SLA, and the difference shapes what you negotiate. Dynamics 365 is a mature, vendor-controlled cloud with a published, financially backed SLA and a continuous update model — strong on guaranteed uptime, weaker on customization-driven downtime because Microsoft will not cover work your partner built. Odoo splits into two worlds: Odoo Cloud (SaaS), where Odoo S.A. publishes a 99.9% uptime SLA with backups and recovery targets, and self-hosted Odoo, where uptime depends entirely on your hosting provider and the application support depends on your partner and the open-source project's lifecycle policy.

On Microsoft's side, the Service Level Agreement for Online Services is the authoritative document, committing to 99.9% monthly uptime for Business Central and the broader Dynamics 365 family with financially backed service credits. The update model — One Version service updates and the twice-yearly release wave — means your SLA must be paired with a partner contract that covers per-update regression testing and change management, because Microsoft's updates are mandatory and can interact with customizations. Microsoft's own implementation guidance places support and hypercare planning in the Operate phase, which is a useful framing: the vendor SLA governs the platform, your partner SLA governs the build, and the two must be designed together at go-live readiness rather than bolted on later. For Flectic-managed Dynamics 365 implementations, this is the support model our services are built around.

On Odoo's side, the calculus depends on deployment model. Odoo Cloud gives you Odoo S.A.'s 99.9% monthly uptime target (excluding planned maintenance), 14 full backups retained for at least three months, and dual DR objectives: RPO 24h / RTO 6h for permanent single-server failure, and RPO 24h / RTO 24h for full data-center loss — plus near real-time replication within region for hardware failover. Odoo's own SLA page states these are design and operational objectives, not legally binding guarantees. The bigger Odoo-specific risk is lifecycle, not uptime: the three-year standard support window and the paid extended-support fee for older versions mean your SLA and support contract must include an explicit version strategy and upgrade plan, or you will face a forced, expensive migration on the vendor's timeline. Self-hosted Odoo removes the vendor cloud SLA entirely and places all uptime responsibility on your host and your partner — a model that can be cost-effective but demands a stronger partner SLA and internal operational maturity.

On Microsoft Business Central online specifically, treat platform backups as a base layer, not a full DR plan: automatic Azure SQL backups with a 28-day point-in-time restore window, environment-wide restores only (not single-company), and a documented limit of about 10 restores per environment per calendar month under a paid subscription. Performance, customizations, ISV apps, and partner response times remain outside Microsoft's Online Services SLA — they belong in your partner contract. That split is why a Dynamics buyer who only reads the Microsoft SLA still has a support gap on day one of production.

Your ERP SLA Checklist

Pull the threads above into a single procurement checklist. Work through it during contract negotiation, not after the first outage. The goal is to leave signing day with two clean agreements — vendor and partner — each with measurable targets, real remedies, bounded exclusions, and a credible exit. The items below extend standard ERP contract checklists with the uptime, credit, cadence, and exit specifics from this guide.

Two agreements: confirm you have both a software vendor SLA (Microsoft's or Odoo Cloud's published document) and a negotiated implementation partner SLA, and that you know which failures each one covers. Uptime and credits: read the actual uptime definition, scheduled-maintenance exclusions, and measurement method (for Microsoft, user-minutes from vendor monitoring); confirm credit tiers (Dynamics 365: 25% / 50% / 100% below 99.9% / 99% / 95%); diary the claim deadline (typically by end of the month following the incident month for Online Services); and negotiate termination for repeated material failures — preferably by incident count in a rolling twelve months. Severity and response: get a P1–P4 matrix with separate response and resolution targets, customer rights on severity designation, defined business hours, and named owners, agreed in the same workshop that sets hypercare severity. Escalation: a functional ladder (L1–L4) and a management ladder, with named contacts and auto-escalation triggers tied to severity; clocks must not stop solely because a ticket was 'escalated to the vendor.'

Security: initial material-incident notice within 24 hours, update cadence, post-incident report timeline, and DPA/SLA alignment with GDPR 72-hour (or other) regulatory floors. Cadence and lifecycle: document the vendor's release model (Microsoft One Version and April/October waves; Odoo annual major version plus three-year support) and confirm partner coverage for per-update regression testing and version strategy. Exclusions: calculate effective guaranteed uptime after maintenance windows and dependency exclusions; push for bounded, published maintenance and restoration commitments on critical integrations. Exit and red lines: open-format export (CSV/JSON/XML), 90-day transition assistance, post-termination read-only access, data-destruction certification, escrow, EU Data Act switching benchmarks where relevant, price-escalation cap, audit rights, and no auto-renewal by silence. For the broader go-live picture this SLA steps down into — hypercare and the implementation engagement that precedes it — see our hypercare and ERP implementation guides.

• →Confirm two agreements exist: a vendor cloud SLA and a negotiated partner SLA, each covering distinct failures.
• →Read uptime definition, maintenance exclusions, and measurement method; diary credit-claim deadlines.
• →Negotiate service-credit tiers plus termination for repeated material failures (prefer incident-count triggers).
• →Agree a P1–P4 severity matrix with response/resolution targets, severity ownership rules, and auto-escalation.
• →Add security-incident notice (24h), update cadence, post-incident report, and DPA alignment.
• →Document release cadence and version/lifecycle strategy; cover regression testing in the partner contract.
• →Lock in open-format export, 90-day transition, destruction cert, escrow, price caps, audit rights, and no silent auto-renewal.

Frequently asked questions