Idempotent ERP Integration: A CIO's Guide to Safe Retries, Duplicates and Timeouts

Every ERP integration eventually meets the same ugly moment. A storefront, CRM, WMS or supplier portal sends an order to the ERP. The network stalls. The sender sees a timeout. Nobody knows whether the ERP created the order, partly created it, or never saw it. The sender retries. If the integration was designed only for the happy path, you now have two sales orders, two pick tickets, or a stock movement posted twice.

This guide is written for the CIO or IT head who owns that risk. It explains how to design and evaluate idempotent ERP integration: how to make retries, redeliveries and timeouts safe for consequential mutations such as orders, goods receipts, invoices and stock adjustments. It also explains where teams commonly go wrong and how to decide, flow by flow, whether an integration is safe to automate.

• Scope: mutating integrations between an ERP and CRM, eCommerce, WMS, MES, BI write-backs or partner systems. Read-only reporting feeds carry far lower risk.
• Code: every code sample here is illustrative. It is not a documented ArionERP API contract. Always build against the exact API documentation of the system you are integrating.
• Not legal advice: privacy, retention and audit obligations depend on your jurisdiction and contracts. Treat vendor compliance features as support for your obligations, not a substitute for them.

Key Takeaways

• Assume at-least-once delivery. Retries and redeliveries are normal. Safety comes from how the receiver processes a message, not from hoping it arrives once.
• Bind identity to payload. Use a durable, tenant-scoped operation identity tied to a hash of the approved payload. Reuse of the same key with a changed payload must be rejected, not silently accepted.
• Claim atomically. Deduplication, the durable inbox or outbox record and work scheduling must happen together, or be explicitly recoverable, before you acknowledge delivery.
• Never blindly retry an ambiguous timeout. For consequential mutations, check the authoritative operation state first. An unknown result means completion could not be confirmed. It is neither success nor verified failure.
• Give every failure an owner. Terminal failures and uncertain inputs need a visible queue and a named team. Identifiers and payload hashes can themselves be sensitive data.
• Use go/no-go controls, not a score. The six-gate review in this article is a proposed design. Every gate must pass for a flow to run unattended.

Why ERP Integrations Duplicate, Drop and Misreport Success

Key takeaway: Networks cannot tell a sender whether a request that timed out was applied. Any integration that retries without a way to find out will eventually duplicate or lose a transaction.

ERP data is not like marketing data. A duplicated lead is an annoyance. A duplicated goods receipt inflates inventory value, a duplicated invoice triggers a customer dispute, and a duplicated stock transfer sends a warehouse looking for units that never moved. Integrations are also where responsibility is least clear: the sender team, the middleware team, the ERP vendor and the business owner each see only one hop.

The root cause is structural. In a distributed system, a request can fail at several points: before the receiver sees it, after the receiver commits but before the response returns, or during a partially completed asynchronous workflow. AWS documents this plainly for its own APIs: operations might time out or encounter other server issues even though the request has already returned a result, which makes it hard to tell whether the request succeeded and can lead to the same action completing multiple times. The same physics applies to every ERP integration, whatever the vendor.

Delivery guarantees in plain terms

Guarantee	What it means	Typical ERP risk	Control required
At-most-once	Sender never retries	Lost orders, silent gaps	Reconciliation reports and a verified acknowledgment
At-least-once	Sender retries until acknowledged	Duplicates, out-of-order updates	Idempotent receiver with durable operation identity
"Exactly-once" effect	Business outcome applied once, even though messages may repeat	False confidence if any layer is not idempotent	Receiver-side deduplication plus conditional mutation on the target

The practical conclusion: design for at-least-once delivery and make the effect happen once. Transport-level promises rarely extend across your whole chain, from storefront to middleware to ERP database to downstream WMS.

Where the standards help, and where they stop

HTTP semantics define which methods are idempotent. RFC 9110 treats methods such as PUT and DELETE as idempotent, but POST, the usual method for creating an order, is not. There is also an IETF Idempotency-Key header draft that proposes making POST and PATCH fault-tolerant. Two scoping cautions apply. First, that document is an Internet-Draft, not a published standard, and its datatracker page lists it as expired. Second, it addresses HTTP requests only. It says nothing about message queues, file drops, EDI batches or database-level integrations, and no header can make a server safe unless the server implements the contract. Use it as a vocabulary, not as a guarantee.

Common Failure Patterns: Why This Fails in the Real World

Key takeaway: Capable teams still ship unsafe integrations because each component passes its own tests. The failure lives in the seams, where ownership is split.

Most organizations approach integration reliability with a retry library, a timeout setting and a hope. Unit tests pass, the demo works and the first load test succeeds. The problems appear months later, under partial failure, which almost nobody rehearses. The scenarios below are illustrative composites of patterns commonly seen in integration work. They are not reports of specific customers or measured results.

Pattern 1: The gateway timeout that created two orders

A storefront posts an order. The ERP commits it, but a gateway times out before the response returns. The storefront retries. The ERP assigns its own order number at creation, so it has nothing to match the second request against, and a second order is created. Each system behaved reasonably in isolation. The gap was that no caller-supplied operation identity existed, and no one owned the question of what a retry means.

Pattern 2: The edit that was silently ignored

A CRM sends an order with key K and quantity 10. A timeout occurs, the sales rep edits the quantity to 12, and the system retries with the same key K. The receiver sees a known key and returns the original success. The CRM shows 12. The ERP holds 10. Nobody sees an error. The control that was missing: the receiver must compare the payload hash and reject the same key with a changed payload.

Pattern 3: The acknowledgment that came too early

A webhook receiver returns success the moment it parses the message, then writes to its database in a background thread. A deployment restarts the process in between. The sender believes the message was delivered. The message is gone. Inventory drifts until a cycle count exposes it.

Pattern 4: The dead-letter queue nobody reads

Messages that fail validation land in a dead-letter queue. There is no alert, no named owner and no path back to the source system. Weeks later, a finance close reveals unposted receipts. The failure was not technical. It was the absence of a terminal-failure process.

Why intelligent teams still miss these

• Happy-path demos. Vendor and internal demos rarely inject a timeout after commit.
• Split ownership. The sender team owns retries, the middleware team owns queues, the ERP team owns data. Nobody owns the end-to-end promise.
• Plausible defaults. Retry-on-error is a library default, so the unsafe behavior is invisible in code review.
• Low base rate. The failure is rare enough to escape testing and common enough to hurt at scale.

Pattern-to-gate map

Pattern	System-level root cause	Preventing gate (next section)
Duplicate orders	No caller-supplied, durable operation identity	Gate 1
Ignored edit	Key not bound to payload	Gate 2
Lost message	Acknowledged before durable, atomic receipt	Gate 3
Concurrent double-apply	Read-compare-then-write on the target	Gate 4
Unread dead letters	No terminal-failure owner or uncertain-input path	Gate 5
Blind retry after timeout	No reconciliation of authoritative state	Gate 6

For broader integration risk context, see ArionERP's earlier piece on ERP integration risks that can lead to a data disaster, and the integration sprawl recovery plan for the architecture side of the same problem.

A Proposed Design: The Six-Gate Integration Safety Review

Key takeaway: Review each mutating integration flow against six mandatory controls. One failed gate means the flow does not run unattended. There is no score to average away a weakness.

The following is a proposed design for a review you can adopt or adapt. It is not an industry standard and not a certification. Its purpose is to make a go/no-go decision explicit for each flow, with evidence a reviewer can inspect.

Apply it per flow, not per project. A product catalog push to a BI warehouse and a payment posting from a storefront do not deserve the same scrutiny. Classify each flow first: read-only, reversible mutation, or consequential mutation (money, inventory, regulatory records, customer commitments). The six gates are mandatory for consequential mutations.

The six gates

Gate	Mandatory control	Evidence to request	If it fails
1. Operation identity	Durable, tenant-scoped operation ID supplied by the originating intent, not generated by the receiver	Schema or contract showing tenant plus operation ID uniqueness	No-go for automation. Use human-approved entry.
2. Payload binding	ID bound to an immutable hash of the approved payload. Changed-payload reuse is rejected.	Test showing a conflict response on key reuse with different content	No-go
3. Atomic receipt and verified acknowledgment	Dedup check, durable inbox or outbox record and work scheduling are atomic, or explicitly recoverable, before the acknowledgment is sent	Crash test between receipt and processing with no lost or duplicated work	No-go
4. Target-side conditional mutation	Concurrent workers cannot both apply. The target enforces the condition.	Concurrency test with two workers claiming the same operation	No-go, or disclose and accept a single-writer serialization limit
5. Terminal failure and uncertain input	Non-retryable errors and ambiguous inputs go to a visible queue with a named owner and a path back to the source	Runbook, alert route, owner name	No-go
6. Reconciliation and privacy ownership	Unknown outcomes are resolved against authoritative state. Identifiers, hashes and logs have a data owner and retention rule.	Reconciliation job, lookup by operation ID, retention policy	No-go

Why not a weighted score? Because averages hide single points of failure. A flow that scores well on five gates and has no atomic claim will still double-post under concurrency. Treat the table as a checklist where each row is a hard requirement.

What the gates do not cover

• They do not replace business validation such as credit checks or tax rules.
• They do not certify security or compliance. See your own control framework for that.
• They do not remove the need for monitoring. They define what to monitor.

Operation Identity, Payload Hashes and Atomic Claims

Key takeaway: The identity of an operation comes from the business intent, is scoped by tenant, and is locked to the payload. Content similarity alone must never decide that two operations are the same.

Amazon describes its preferred approach as a unique caller-provided client request identifier in the API contract, so that requests with the same identifier from the same caller can be treated as duplicates. In its Builders' Library article on idempotent APIs, it also describes storing the parameters of the first request alongside the identifier, and returning a validation error when the same token arrives with a different parameter combination. The reasoning is sound for ERP work: assume the caller intended a different outcome, and say so loudly.

Designing the identity

• Tenant-scoped. In multi-company or multi-tenant deployments, uniqueness must be on (tenant, operation ID). A global key lets one tenant's identifier collide with, or reveal the existence of, another's.
• Originated at the source of intent. The storefront order, the CRM approval or the WMS pick confirmation creates the ID once. Retries reuse it. The receiver should not invent it on arrival.
• Durable. Stored in the receiver's database with the outcome, not in a cache that can be evicted mid-retry window.
• Bound to an approved payload hash. Canonicalize the payload, hash it, and store the hash with the ID. Same ID, same hash: return the recorded outcome. Same ID, different hash: reject with a conflict.

Legitimate later operations are not duplicates

The opposite error is just as costly: suppressing real business. A customer who places the same order twice in a week is not a retry. Deduplicating on content, such as customer plus items plus amount within a time window, will eventually discard a legitimate sale.

Scenario	Same operation?	Rule
Timed-out request retried unchanged	Yes	Same ID, same hash: return recorded outcome
Same ID, quantity edited	No, conflict	Reject. The caller must issue a new operation that references the prior one.
Customer re-orders identical basket	No	New ID from a new intent. Never dedupe on content alone.
Amendment to an existing order	No	New ID plus expected version of the target record
Replay after the retention window	Unknown	Do not assume new. Apply a secondary check, such as a source event sequence or a uniqueness rule on the business reference.

Retention deserves explicit design. As the AWS article notes, retaining request knowledge forever is impractical and can create collisions with much later identifiers. Define the window, make it longer than your longest retry and replay horizon, and decide what happens to late arrivals.

Atomic claim and conditional mutation

If two workers pick up the same operation, only one may proceed. The claim must be a single atomic statement on the store, not a read followed by a write. Likewise, the final change to the ERP record needs a condition enforced by the target. A check that reads a version and then writes is not compare-and-swap. Two workers can both pass the read. The condition must live inside the write itself, or you must disclose that the flow relies on single-writer serialization and accept the throughput limit.

The following sketch is illustrative only, in generic SQL. It is not an ArionERP API or schema.

-- Illustrative only: generic SQL, not a documented ArionERP schema. CREATE TABLE integration_operation (   tenant_id        TEXT NOT NULL,   operation_id     TEXT NOT NULL,   payload_hash     TEXT NOT NULL,   -- keyed hash of canonical approved payload   state            TEXT NOT NULL,   -- RECEIVED, CLAIMED, APPLIED, REJECTED_TERMINAL, UNKNOWN, QUARANTINED   claimed_by       TEXT,   claim_expires_at TIMESTAMP,   target_ref       TEXT,            -- id of the ERP record once applied   PRIMARY KEY (tenant_id, operation_id) );  -- 1) Record receipt. Existing row means retry or conflict, never a second insert. INSERT INTO integration_operation (tenant_id, operation_id, payload_hash, state) VALUES (:tenant, :op, :hash, 'RECEIVED') ON CONFLICT (tenant_id, operation_id) DO NOTHING; -- Then read the row: if payload_hash differs from :hash, return a conflict.  -- 2) Atomic claim: exactly one worker gets rows_affected = 1. UPDATE integration_operation    SET state = 'CLAIMED', claimed_by = :worker,        claim_expires_at = :lease_end  WHERE tenant_id = :tenant AND operation_id = :op    AND (state = 'RECEIVED' OR (state = 'CLAIMED' AND claim_expires_at < :now));  -- 3) Conditional mutation on the target, enforced inside the write. UPDATE sales_order    SET status = 'APPROVED', version = version + 1  WHERE tenant_id = :tenant AND order_id = :order    AND version = :expected_version; -- rows_affected = 0 means a conflict: do not assume success.

Note that a lease can expire while the first worker is still alive. That is why step 3 must carry its own condition rather than trusting the claim alone.

Verified Acknowledgment, Inbox and Outbox, and Terminal Failure

Key takeaway: Acknowledge only what you have durably recorded. Every message must end in a known state, and every failure state must have a human owner.

What a verified acknowledgment means

A sender should treat a message as delivered only when it receives an explicit acknowledgment tied to the operation ID, and the receiver should send that acknowledgment only after the receipt is durable. A generic HTTP 200 from a proxy or load balancer proves little. A 202 typically means accepted for later processing, not completed. Document which statuses mean what, and make the sender store the acknowledgment against the operation.

Deduplication, inbox record and scheduling must be atomic

The classic gap sits between three steps: check whether the message was seen, record it, and schedule the work. If they are separate commits, a crash between them either loses the work (recorded but never scheduled) or duplicates it (scheduled but not recorded). Close the gap in one of two ways:

1. One transaction. Insert the inbox row and the work item in the same database transaction, commit, then acknowledge.
2. Explicitly recoverable. If a single transaction is impossible, order the steps so that a crash always leaves a detectable, repairable state, and run a sweeper that finds received-but-unscheduled records. Acknowledge only after the recoverable state is durable.

On the sending side, the transactional outbox pattern, described at microservices.io, applies the same idea: write the business change and the outgoing message in one local transaction so they cannot diverge, then publish from the outbox. Publication is still at-least-once, so the receiver's idempotency remains mandatory.

Operation states you should be able to query

State	Meaning	Next action
RECEIVED	Durably recorded, not yet claimed	Scheduler claims atomically
CLAIMED	A worker holds a lease	Complete, or lease expires and another worker may reclaim
APPLIED	Confirmed on the target, with a target reference	Return recorded outcome to any retry
REJECTED_TERMINAL	Verified failure that retrying cannot fix	Notify source, assign owner, never retry blindly
QUARANTINED	Input too ambiguous to apply safely	Human review, then a new or corrected operation
UNKNOWN	Completion could not be confirmed	Reconcile against authoritative state before any retry

Notice that UNKNOWN is its own state. It does not mean success and it does not mean verified failure. Collapsing it into either one is the most common modeling error in integration code.

Terminal failure

Distinguish transient faults, which merit retries with backoff, from terminal ones, such as a closed accounting period, a discontinued item or a failed validation. AWS's own guidance for idempotent requests shows the same split: client errors generally should not be retried, while server-side errors may be retried with an appropriate backoff strategy. For terminal failures, require three things: a reason code, a notification back to the originating system, and a named owning team with a service-level expectation for review.

Handling uncertain input

Uncertain input is data that is syntactically valid but semantically ambiguous: an SKU that matches two items after a rename, a unit of measure that could be cases or each, a customer record that fuzzy-matches three accounts. For consequential mutations, do not guess. Quarantine the record. If your platform uses AI-enabled matching or classification, treat its output as a proposal that a deterministic rule or an authorized person confirms before money or stock moves. Confidence from a model is not an authorization.

For governance structure around these interfaces, see the API governance model for modular ERP.

Ambiguous Timeouts: Reconcile Before You Retry

Key takeaway: After an ambiguous timeout on a consequential mutation, the first action is a state lookup, not a second attempt. A retry is safe only when the target provably enforces the same-key, same-payload contract.

A timeout tells you only that you did not receive an answer. The decision tree below keeps the logic explicit.

Situation	Safe action	Unsafe action
Timeout, target supports lookup by operation ID	Query authoritative state. Applied: record the outcome. Absent: retry with the same ID and hash.	Retry without looking
Timeout, target supports same-key dedupe with payload binding, documented	Retry with the same ID and hash, then verify the outcome	Retry with a fresh ID
Timeout, target has neither lookup nor dedupe	Mark UNKNOWN, freeze the flow, reconcile by a business key or manual check	Auto-retry and hope
Lookup itself fails	Stay UNKNOWN. Back off the lookup.	Treat as failed and re-send
Client error response (validation)	Move to terminal failure with a reason	Retry unchanged

Row three is the uncomfortable one. If a target cannot answer "did operation X happen?", then fully automated consequential mutation against it is a no-go under Gate 6. That is a finding worth surfacing before purchase, not after go-live.

Illustrative sizing of the reconciliation load

The following arithmetic is hypothetical and illustrative, to show how to size the work with your own measurements. Suppose a flow carries 1,200 order messages per day and 0.5 percent end in an ambiguous timeout. That is 6 per day, or about 180 per month. If each needs 15 minutes of investigation without a lookup capability, that is roughly 45 hours monthly. With lookup by operation ID, most can resolve automatically. Replace these numbers with your own message volumes, timeout rates and handling times before using them in a business case.

Identifiers can be sensitive data

Privacy ownership is part of the design, not an afterthought:

• Do not derive keys from personal data. An operation ID built from an email address or national ID spreads that data into logs, dashboards and vendor support tickets.
• Hashes are not automatically anonymous. A plain hash of a low-entropy payload, such as a short order with a small set of products, can be guessed by brute force. Use a keyed hash, and keep the key under your control.
• Name the data owner. Someone must own retention, access and deletion rules for operation records, dead-letter payloads and integration logs. Quarantine queues often hold the most sensitive, least-reviewed data.
• Tenant isolation applies to logs. Make sure support tooling cannot cross-search operation IDs across tenants.

Whether any of this is legally required depends on your jurisdiction and your contracts. Ask your counsel, and confirm what your ERP vendor's compliance features cover and where your own obligations begin. ArionERP publishes its security and certification information on its security and compliance page and certifications page. Read the scope statements there and request current evidence for anything your auditors will rely on.

A Lower-Risk Path: Deployment Choice, Vendor Evidence and Rollout

Key takeaway: Ask every ERP vendor, including ArionERP, to demonstrate the six gates against the real API in your proof of concept. Deployment model changes who owns the evidence, not whether you need it.

How deployment model shifts responsibility

ArionERP is offered as both a cloud (SaaS) and an on-premises platform, so the same flow design must be reviewed in either model. The ownership questions differ:

Question	SaaS	On-premises
Who controls the operation records and logs?	Shared. Confirm what you can export and for how long.	You do, including backup and retention
Who can run reconciliation queries?	Limited to what the API exposes	Potentially direct, subject to your governance
Who patches the integration layer?	Mostly the vendor, on its schedule	You, on yours
Who must prove privacy controls to auditors?	You, supported by vendor evidence	You, with your own evidence

Vendor evidence checklist

Ask for demonstrations, not assurances. We apply this list to our own platform as well, and you should hold any vendor to it, whether Tier-1 suite, mid-market ERP or ArionERP. Documentation on the API page and the integrations page is a starting point. Capabilities should be confirmed against current documentation and a test in your environment. For side-by-side positioning, the comparison page is available, but verify any capability claim in a hands-on test.

1. Show the contract for caller-supplied operation identity on create and update calls, and its tenant scope.
2. Replay the same key with a changed payload. What is returned?
3. Kill the receiver between receipt and processing. Is work lost or duplicated?
4. Run two workers against one operation. Who wins, and where is the condition enforced?
5. Time out a call after commit. Can you look up the outcome by operation ID?
6. Send an invalid and an ambiguous record. Where do they land and who is notified?
7. Show the retention period, export options and access controls for operation records and logs.

A phased rollout

1. Classify flows as read-only, reversible or consequential. Start with the last group.
2. Run in shadow mode. Process messages alongside the current path and compare outcomes without applying them.
3. Inject faults on purpose: timeouts after commit, duplicate delivery, worker crash, changed-payload reuse.
4. Launch with a narrow scope, one channel or one warehouse, and keep a manual fallback.
5. Measure with your own data: duplicate rate, UNKNOWN count and age, quarantine backlog age, reconciliation time. Do not rely on vendor averages.
6. Re-run the gates whenever an interface, schema or vendor release changes.

2026 Update, and what stays true

As of this writing in 2026, the Idempotency-Key header for HTTP remains an Internet-Draft that the IETF datatracker lists as expired, so the safe assumption is that behavior is defined by each vendor's own documentation, not by a ratified standard. Teams are also adding AI-assisted matching and automation into integration paths. The evergreen rule does not change: models may propose, but deterministic, auditable controls decide whether a consequential mutation is applied. Check standards status again before you cite it in an architecture decision record.

Not sure your order and receipt flows survive a timeout?

Bring one real integration flow. We will walk through the six gates with you.

Book an integration safety walkthrough with ArionERP specialists.

Talk to an ArionERP Expert

Conclusion: Five Actions for the Next 30 Days

Safe retries are a design property you can test. These steps convert this article into decisions:

1. Inventory your mutating flows. Tag each as read-only, reversible or consequential, and name a business owner and a technical owner for each consequential flow.
2. Run the six-gate review on the highest-value flow first, usually order creation or goods receipt. Record pass or fail for each gate with evidence. Any failed gate means human-approved entry until it is fixed.
3. Add the missing state. Make UNKNOWN, QUARANTINED and REJECTED_TERMINAL queryable, alert on their age, and assign a named owner.
4. Rehearse failure. Inject a post-commit timeout, a duplicate delivery and a changed-payload retry in a test environment before every major release.
5. Assign privacy ownership. Decide who owns retention and access for operation records, hashes and dead-letter payloads, and verify vendor evidence against your own obligations.

About the authors and review

ArionERP is a modular, AI-enhanced ERP platform offered as cloud (SaaS) and on-premises deployments. It was launched in 2016 as a product of Cyber Infrastructure (CIS), a software engineering company operating since 2003. This article draws on ERP implementation and integration practice and on the primary sources linked above. Product and compliance information is described as published by ArionERP, so confirm current scope and evidence on the security and certifications pages before relying on it. Reviewed by ArionERP Expert Team.

Frequently Asked Questions

What does idempotent mean in an ERP integration?

An idempotent operation can be received or retried several times and still produce the same business effect once. For an ERP, that means a repeated sales order message does not create a second order. It is achieved by the receiver recognizing the operation identity, not by the network delivering exactly once.

Is it safe to retry a request after a timeout?

Not blindly, when the request changes money, stock or customer commitments. A timeout means no answer arrived, not that nothing happened. Check the authoritative operation state first. Retry with the same operation ID and payload hash only if the target documents and enforces that contract. If completion cannot be confirmed, keep the operation as UNKNOWN and reconcile.

Can I deduplicate by order content instead of using an operation ID?

Content matching is risky. Two legitimate orders can have identical content, and it may suppress real business. Use a source-generated operation identity, scoped by tenant and bound to the payload hash. Content comparison is useful only as a secondary review signal.

Is the Idempotency-Key header an official standard?

As reviewed for this article, it is an IETF Internet-Draft that the datatracker lists as expired, not a published RFC. It also covers HTTP requests only, not queues, files or EDI. A server must implement the behavior, so rely on the vendor's documented contract and test it.

What is the difference between a terminal failure and an unknown result?

A terminal failure is a verified failure that retrying will not fix, such as a validation error or closed period. An unknown result means completion could not be confirmed. The first goes to an owner for correction. The second goes through reconciliation against authoritative state.

Why must acknowledgment come after the durable record?

If you acknowledge first and crash before recording, the sender believes the message was delivered and will not resend it, so the transaction is lost. Record the inbox entry and schedule the work atomically, or in an explicitly recoverable way, then acknowledge.

Do operation IDs and payload hashes count as personal data?

They can. IDs derived from emails or account numbers expose that data, and hashes of low-entropy content can be guessed. Whether they are regulated depends on your jurisdiction and context, so assign a data owner, use random IDs and keyed hashes, and set retention rules with your legal team.

Does choosing SaaS or on-premises ERP change idempotency requirements?

No, the requirements are the same. What changes is who controls operation records, logs, patching and reconciliation access. Confirm those boundaries and the evidence available for each deployment model before go-live.