Practical ERP guidance
ERP Integration Cutover: A CIO's Go/No-Go Plan for In-Flight Orders, Retries, and Rollback
Every ERP go-live plan has a slide for data migration. Far fewer have a slide for the orders, payments, shipment confirmations, and webhooks that are halfway through the integration layer when the switch is flipped. That gap is the subject of this article: ERP integration cutover, the controlled transfer of ownership for live business operations from a legacy system to a new ERP without losing, duplicating, or double-posting anything.
This guide is written for the CIO or IT head who owns the integration estate: eCommerce storefronts, CRM, warehouse systems, BI pipelines, supplier portals, and the middleware between them. Master data usually moves cleanly because it can be rehearsed and compared. Live operations are harder because they keep arriving while you move.
Where this article describes a framework, it is a proposed design for you to adapt and test. It is not a proprietary method that ArionERP claims to have already standardized, and it is not a certification of production readiness. Where it describes ArionERP, it relies on the vendor's own published pages and says so.
- Who it is for: CIOs and IT leaders planning or recovering an ERP go-live with live integrations.
- What you get: an ownership model, handling rules for acknowledgments, failures, and unknown outcomes, and a go/no-go control set where every control is required.
- What it complements: our guides on idempotent ERP integration, failure-injection testing before go-live, and incident recovery for unknown outcomes. Those cover steady-state retries, testing, and aftermath. This one covers the switch itself.
Key Takeaways
- Bottom line: A cutover is an ownership transfer, not a connection change. For each class of business operation, exactly one system must be the writer at any moment, and that fact must be recorded, not assumed.
- In-flight work is the real risk. Queued messages, retrying webhooks, half-shipped orders, and unconfirmed postings do not appear in a data migration plan.
- Acknowledge only what is durably recorded. A success response should mean the operation and its scheduled work were saved together, not that processing is finished.
- Never blindly retry an ambiguous timeout on a consequential mutation. Query the authoritative operation state first. An unknown result means completion could not be confirmed. It is not success and it is not verified failure.
- Bind identity to intent and payload. Use a durable, tenant-scoped operation ID tied to an immutable approved payload hash. Reject reuse with a changed payload, and give legitimate later operations new IDs.
- Use all-required go/no-go controls. Do not sum scores. One failed control stops the cutover.
Why In-Flight Transactions Break ERP Integration Cutovers
Key takeaway: Cutover failures rarely come from the new ERP's functions. They come from the minutes when two systems each believe they own the same operation, or neither does.
Most ERP programs treat go-live as a date. Integrations treat it as a stream. Orders keep arriving from storefronts, suppliers keep confirming shipments, and senders keep retrying messages that were never acknowledged. When the new ERP becomes the system of record, every one of those streams has to change its destination, and each one has a different failure mode if the change is mistimed.
The difficulty is that in-flight work hides in places a project plan does not list. The table below maps where it typically lives.
| In-flight work | Where it hides | What goes wrong | Ownership question |
|---|---|---|---|
| Inbound webhooks and API calls | Sender retry schedules, endpoint URLs, DNS or gateway routes | Old and new receivers both accept the same event, or the sender keeps retrying to a retired endpoint | Which receiver is the receiver of record after the switch, and does the other one reject? |
| Queued messages | Brokers, middleware, iPaaS flows | Backlog is replayed into the new ERP and re-creates documents that already exist | Who drains the queue, and who proves it is empty? |
| Outbound postings awaiting a result | Outbox tables, schedulers, timeouts | The result is unknown, so the team guesses success or failure | Who reconciles against the authoritative record? |
| Partially completed documents | Open sales orders, partial receipts, open purchase orders | Remaining quantities are double-counted or dropped | Which system owns the remaining quantity? |
| Scheduled jobs and batch syncs | Cron jobs, nightly exports, ETL tasks | An old job writes to the new system, or the reverse | Has every job been disabled or re-pointed, and who verified it? |
| Dead-letter and manual retry backlogs | Operations queues, support spreadsheets | Stale failures are replayed after the world has changed | Is each item terminal, retryable, or unknown, and who decides? |
An illustrative sizing exercise
Illustrative arithmetic, not customer data: a distributor receiving 1,200 orders a day through several channels will see roughly 200 orders arrive during a four-hour cutover window, assuming a flat arrival rate. If even 2 percent of those land in an ambiguous state (accepted by one system, unconfirmed by the other), that is about four orders that need individual reconciliation before anyone can say the books are right. Scale the rate or the window and the number grows. The point is not the figure. It is that ambiguity scales with window length and arrival rate, so you should size it for your own volumes before choosing a freeze strategy.
What standards do and do not cover
Teams sometimes assume their security stack covers this. It does not. TLS protects data in transit between two endpoints, and OAuth 2.0 controls who may call an API. Neither makes an operation safe to repeat, and neither tells you whether a timed-out request was applied. Message-queue features have their own limits: Amazon SQS FIFO queues, for example, document a bounded deduplication interval for exactly-once processing, which helps within that window but says nothing about a replay that arrives days later from a different system. Treat each mechanism as scoped to its own transport and use case.
Master data is the part you can rehearse and compare. If you have not yet planned that side, start with our zero-disruption data migration playbook and the ArionERP data migration overview, then return here for the live-traffic problem.
How Most Teams Plan Cutover, and Why Those Plans Fail
Key takeaway: The common plans (freeze, dual-run, replay) each solve one problem and quietly create another. The failure is almost never in the plan's logic. It is in an assumption nobody wrote down.
Four approaches account for most cutovers. None is wrong in every context, and the comparison below is meant to show what each one assumes.
| Approach | Cost | Risk | Speed | Scalability | Hidden failure mode |
|---|---|---|---|---|---|
| Freeze and drain: stop writes, let queues empty, switch | Low tooling, high business disruption | Medium | Slow, long window | Poor for always-on channels such as online ordering | One channel is not actually frozen, or a queue is declared empty without evidence |
| Parallel run (dual write): both systems receive everything | High, because two systems must be operated and reconciled | High for consequential actions | Medium | Poor | Both systems act (ship, invoice, pay) on the same event and reconciliation never converges |
| Replay from log: re-send recent events into the new ERP | Medium | High | Fast to start | Medium | Events that already had effects are applied again, or deduplication on business fields drops legitimate repeats |
| Staged ownership by operation class (the ledger design in the next section) | Medium up front | Lower, if controls are enforced | Medium | Good | The ownership record is not treated as authoritative, so it drifts from reality |
Four assumptions that quietly break plans
- "The queue is empty, so we are done." An empty broker says nothing about senders that are still retrying, scheduled jobs that have not fired, or operations whose outcome was never confirmed.
- "We will deduplicate on customer, item, and quantity." A key built from content cannot tell a duplicate from a legitimate repeat order. Intent must come from the originating record, not from field similarity.
- "A new idempotency key on retry is fine." It defeats the purpose. Stripe's idempotent request documentation describes the intended behavior well: the client generates the key, the server compares incoming parameters with the original request, and a mismatch is an error. The same document advises against using sensitive data such as email addresses as keys. Rotating the key on retry turns a caught duplicate into a real second operation.
- "A timeout means it failed." A timeout means you did not hear back. The operation may have committed, may be committing, or may never have arrived.
The AWS Builders' Library article on making retries safe with idempotent APIs covers the underlying reasoning in depth, including why a retry must carry the same request identity. Those ideas are well established. What a cutover adds is that the identity and the ownership have to survive a change of system, which is where most designs have never been tested.
A Proposed Design: The Cutover Ownership Ledger
Key takeaway: Record, per operation class, which system owns writes and in what state. Then give every operation a durable identity bound to its approved payload, and let exactly one worker claim it.
The following is a proposed design, offered as a starting point for your own architecture review. It combines widely used patterns (idempotent operation records, inbox and outbox recording, conditional updates) into a cutover-specific ownership model. It has not been presented here as an established ArionERP method or as a certified standard.
Step 1: Classify operation classes and give each one an owner state
Group integration traffic by business consequence: catalog and price sync, customer updates, sales order intake, inventory movements, shipment confirmations, invoice and payment postings. Each class moves through its own states, so low-consequence classes can cut over earlier than financial ones.
| State | Meaning | Allowed actions | Exit condition |
|---|---|---|---|
legacy_owned | Legacy ERP is the system of record | Legacy applies operations. The new ERP rejects or holds them without applying. | Business owner signs the freeze for this class |
draining | Legacy accepts nothing new for this class | In-progress operations finish, fail terminally, or are marked unknown. New arrivals are recorded but not applied. | Every known operation is applied, terminally failed, or in reconciliation |
unknown_reconcile | Completion could not be confirmed | Read-only queries against the authoritative record. No blind retry. | Evidence shows applied, or not applied and fenced against late arrival |
new_owned | New ERP is the system of record | New ERP applies operations. Legacy rejects or forwards them. | Only a deliberate, rehearsed rollback returns it |
Step 2: Give every operation a durable, tenant-scoped identity
- Create the ID at the point of approved intent, such as when an order is accepted or an invoice is approved, not when a message is sent. Make it opaque and random. Do not build it from an email address, customer name, or other personal data, because identifiers can themselves be sensitive.
- Scope it by tenant or legal entity. A key that is unique only globally can collide across entities in a multi-company setup, and one that is unique only within a tenant must never be compared across tenants.
- Bind it to an immutable hash of the approved payload. Compute the hash over a canonical form of the approved content. If the same ID arrives with a different hash, reject it and raise an alert. Never treat it as an update.
- Distinguish legitimate later operations. A second order from the same customer, an amendment, a partial shipment, and a reorder each get their own operation ID. Amendments reference a parent operation ID so the chain is auditable. The test is whether a person would call it the same intent, not whether the fields look similar.
Step 3: Record receipt and schedule work atomically
Deduplication, durable inbox recording, and work scheduling must happen together, or be explicitly recoverable, before you acknowledge delivery. If you record the receipt and then crash before scheduling work, the sender believes it succeeded and nothing runs. If you schedule work first and crash before recording, you may process without a record. The transactional outbox pattern describes the general solution to this dual-write problem. The sketch below shows the idea as a single statement.
-- Illustrative PostgreSQL sketch. Not an ArionERP API contract. CREATE TABLE integration_operation ( tenant_id text NOT NULL, operation_id text NOT NULL, payload_hash bytea NOT NULL, owner_system text NOT NULL, state text NOT NULL, claimed_by text, claim_expires timestamptz, version bigint NOT NULL DEFAULT 0, PRIMARY KEY (tenant_id, operation_id) ); -- Receipt: record the operation and schedule work in ONE statement. -- $4 comes from the ownership ledger for this operation class. WITH ins AS ( INSERT INTO integration_operation (tenant_id, operation_id, payload_hash, owner_system, state) VALUES ($1, $2, $3, $4, 'received') ON CONFLICT (tenant_id, operation_id) DO NOTHING RETURNING tenant_id, operation_id ) INSERT INTO work_queue (tenant_id, operation_id) SELECT tenant_id, operation_id FROM ins; -- Then read the stored payload_hash for (tenant_id, operation_id). -- If it differs from $3, reject as changed-payload reuse and schedule nothing. -- Send a success response only after this commits.Step 4: Claim work atomically, and mutate the target conditionally
With several workers, two of them can pick up the same operation. The claim must be a single conditional write, not a read followed by a write.
-- Illustrative claim. Exactly one concurrent caller can succeed. UPDATE integration_operation SET state = 'claimed', claimed_by = $3, claim_expires = now() + interval '2 minutes', version = version + 1 WHERE tenant_id = $1 AND operation_id = $2 AND owner_system = 'new' AND (state = 'received' OR (state = 'claimed' AND claim_expires < now())) RETURNING version; -- Zero rows returned: another worker holds it, it is finished, -- or this system does not own it. Do not proceed. -- Pass the returned version to the target as a fencing token.A claim protects your integration store. It does not protect the ERP. If a slow worker's claim expires and a second worker takes over, both could still write to the target. Read-compare-then-write is not compare-and-swap: two callers can both read the same state and both write. You need target-side conditional mutation, for example an update that only succeeds when the document is still in the expected status or version, or a target that honors an idempotency key natively. If the target offers neither, say so in your design review, serialize writes per entity through a single writer, and document the residual conflict risk. The ArionERP API page describes a REST API with OAuth 2.0 authentication, webhooks, and a sandbox, but it does not state idempotency-key or conditional-update semantics, so confirm those in the API documentation for any endpoint you plan to depend on, as you should with any ERP.
Step 5: Treat rollback as a cutover in reverse
Define the point of no return before the window opens. After it, operations applied in the new ERP are not undone. They are reconciled forward. Before it, returning a class to legacy_owned must go through the same states: drain, reconcile, then hand back. A rollback that skips the ledger recreates the dual-owner problem you were avoiding.
Acknowledgments, Terminal Failures, Unknown Outcomes, and Privacy During the Window
Key takeaway: Every message should end in exactly one of four handling classes. If the team cannot say which one, the message stays quarantined until someone can.
The four handling classes
| Class | Definition | Response to the sender | System action |
|---|---|---|---|
| Verified acknowledgment | The operation and its scheduled work were committed together | Success response, and only now | Process asynchronously. An acknowledgment means recorded, not processed. |
| Retryable failure | A transient condition where the target is known not to have committed | Non-success response, or internal retry with the same operation ID and same payload | Bounded backoff with jitter. Never regenerate the ID. |
| Terminal failure | Validation failure, unknown item, closed accounting period, or hash mismatch | Reject with a reason code | Route to a named owner. Not auto-retried. A corrected resubmission is a new, approved operation or an approved replay. |
| Uncertain input | Ambiguous mapping, missing tenant, near-duplicate with different content, or unknown outcome | Quarantine | No mutation. Resolve with evidence by a rule or a person. Do not guess. |
Notice what is missing: a class for "probably fine." Uncertain input is the largest hazard in a cutover because the pressure to keep the window short pushes teams to resolve ambiguity optimistically.
Ambiguous timeouts on consequential mutations
Posting an invoice, releasing a shipment, or capturing a payment is consequential: a duplicate or a miss has financial or customer impact. After a timeout, the first move is never to resend. It is to reconcile against the authoritative operation state, looked up by tenant and operation ID.
| What the lookup shows | Meaning | Action |
|---|---|---|
| Found, applied, payload hash matches | Completed | Mark applied. Do not retry. |
| Found, in progress or claimed | Another worker is acting | Wait and re-check. Do not retry. |
| Found, payload hash differs | Same ID used with changed content | Stop. Open an incident. Never overwrite. |
| Not found, and the target honors the same idempotency key | Safe to resend identical bytes | Retry with the same ID and same payload |
| Not found, and the target has no idempotency support | Absence is not proof. The original request could still land late. | Fence it (cancel token, expiry, or hold) or keep it unknown and escalate |
| The lookup itself fails | Still unknown | Remain unknown. Report neither success nor failure. |
That last row is worth repeating in your runbook. An unknown result means completion could not be confirmed. It is not success, and it is not verified failure. Reporting it as either one corrupts your reconciliation. The aftermath of unresolved cases is covered in our incident recovery runbook.
Privacy ownership belongs in the cutover plan
The inbox, the quarantine area, and any dead-letter store hold full payloads: names, delivery addresses, contact details, order contents. During a cutover those stores grow quickly and attract screenshots, spreadsheet exports, and shared chat threads. Assign a named data owner for each payload store, with defined retention, role-based access, and masking in logs. Time-box access for the cutover team and review it afterward. Opaque operation IDs help because they keep identifiers out of logs, but the payloads still need an owner. Our guide to integration data privacy controls goes deeper.
What vendor assurance does and does not cover
ArionERP's security page states that the platform is SOC 2 Type II compliant and ISO/IEC 27001 certified, that data is encrypted in transit with TLS 1.2 or higher and at rest with AES-256, and that role-based access control, multi-factor authentication, and audit logging are available. It also says the SOC 2 report is available to customers under NDA. Those are vendor statements. The home page uses slightly different wording ("SOC 2 compliant and adheres to ISO 27001 standards"), so a careful buyer should request the current report and certificate and check the scope, audit period, and which systems and locations are covered. The same page describes ArionERP as a data processor and its tools as helping you, as controller, meet your own obligations. In plain terms, platform features support compliance, but your legal obligations, your middleware, and the correctness of your cutover remain yours. A vendor's audit attests to its control environment. It does not prove that your in-flight orders were handled correctly.
Mandatory Go/No-Go Controls for Cutover
Key takeaway: All twelve controls are required. There is no score and no passing threshold. Passing them removes known disqualifiers. It does not certify that production is safe.
A weighted score invites trade-offs that the problem does not allow. You cannot offset a missing atomic claim with a strong rollback plan, because they protect against different failures. Treat the list below as a gate: the cutover proceeds only if every control has recorded evidence, and any single failure is a no-go until it is fixed and re-tested.
| # | Control | Evidence required | No-go if |
|---|---|---|---|
| 1 | Single owner per operation class | Ownership ledger with a state per class, signed by the business owner | Any class has two writers or none |
| 2 | Every sender and receiver verified | Each upstream sender confirmed pointing at the new receiver, and the old receiver confirmed rejecting | Any sender or scheduled job is unverified |
| 3 | Verified acknowledgment | Test that kills the process right after a success response and shows the operation and its work still present | A success response can precede the durable record |
| 4 | Tenant-scoped operation identity bound to payload hash | Tests showing duplicate IDs are absorbed and changed-payload reuse is rejected | Keys are global, or the hash is not enforced |
| 5 | Atomic claim against concurrent workers | Concurrency test where exactly one worker applies | Two workers can both apply |
| 6 | Receipt and work scheduling atomic or recoverable | Crash test between steps, plus a sweep that finds orphaned records | A window exists in which work can be lost silently |
| 7 | Target-side conditional mutation, or disclosed serialization | Evidence of conditional update or native idempotency, or a written disclosure of limits | Read-compare-then-write on a shared target with no disclosure |
| 8 | Unknown-outcome reconciliation | Runbook exercised with injected timeouts, using the lookup table above | The runbook allows blind retry of consequential mutations |
| 9 | Terminal failure and quarantine owners | Named owner and response time for each queue | Any queue has no owner |
| 10 | Privacy ownership for payload stores | Documented retention, access, and masking for inbox, quarantine, and dead-letter stores | Production payloads can be copied to uncontrolled channels |
| 11 | Legitimate later operations pass | Repeat order, amendment, and partial shipment tests succeed without suppression | Deduplication drops a valid operation |
| 12 | Rehearsed rollback with a defined point of no return | Reverse-ledger rehearsal completed in a production-shaped environment | No tested rollback, or no declared point of no return |
Controls 3 through 7 can be proven before go-live using the failure-injection techniques in our integration testing guide. Controls 1, 2, 9, and 12 are about governance and need named people, not just code.
Comparing platform categories on cutover readiness
The table below compares typical patterns by category. It is a buyer's aid for deciding which questions to ask, not a claim about any named product. The ArionERP column reflects statements on ArionERP's published pages, and every row ends in something you should verify during evaluation.
| Dimension | Tier-1 suites (typical pattern) | Lightweight mid-market ERP (typical pattern) | ArionERP (vendor-documented) |
|---|---|---|---|
| Integration surface | Broad, often delivered through vendor middleware and partner-built connectors | Connector-first, with varying depth for custom flows | REST API with JSON, OAuth 2.0, webhooks, and a sandbox per the API page; see also integrations |
| Cutover effort | Usually a partner-led program with formal cutover planning | Often self-directed with fewer rehearsal facilities | Optional implementation and training services; scope set in the quote |
| Deployment choice | Varies by product | Mostly SaaS | Cloud (SaaS) or On-Premises |
| Verify in every case | Idempotency-key support, conditional update behavior, webhook retry and signature behavior, sandbox fidelity to production, report scope for any SOC 2 or ISO 27001 claim | ||
Common Failure Patterns: Why This Fails in the Real World
Key takeaway: Capable teams fail at cutover because ownership was implied, identity was derived from content, or timeouts were read as failures. These are system and governance gaps, not individual mistakes.
The four scenarios below are composite and illustrative. They are patterns that recur in integration work, written to show mechanisms, and they are not reports of specific customer results.
Pattern 1: Two receivers, one webhook
A storefront sends order events to an endpoint. The team re-points the route to the new ERP but leaves the legacy receiver running "just in case." The sender's retry schedule still includes events queued before the change. Some of those reach the legacy system, which accepts them, while a replay job feeds the same orders into the new system. The order exists twice, and two invoices go out.
Why capable teams miss it: the plan assigned the new system the work but never assigned the old system the duty to refuse it. Ownership was implied by the route change. Controls 1 and 2 close this gap.
Pattern 2: Deduplication that silently drops real orders
To stop replay duplicates, the team builds a key from customer, item, quantity, and date. It works in rehearsal. In production, a customer legitimately places the same order twice in an afternoon. The second one is acknowledged, found to match, and discarded. The customer notices days later.
Why capable teams miss it: test data was generated from one pass of historical orders, so the repeat case never appeared. A key derived from content cannot represent intent. Controls 4 and 11 address it.
Pattern 3: The retry that arrives twice
A shipment-release call to the target times out. The worker reads the target, finds no release, and sends it again. The first request had been delayed in a gateway and lands seconds later. Two releases are now on the warehouse floor.
Why capable teams miss it: a read followed by a write felt like a check. It was a race. Without a fence or target-side idempotency, "not found" only means "not found yet." Controls 7 and 8 address it.
Pattern 4: The dead-letter queue nobody owns
The cutover week produces a large backlog of failed messages. A well-meaning analyst exports them to a spreadsheet for triage, including delivery addresses. After go-live, a batch of stale messages is replayed, and old price updates overwrite current ones.
Why capable teams miss it: nobody classified items as terminal, retryable, or unknown, and nobody owned the payload data. Controls 9 and 10 address it.
Risks and trade-offs you should say out loud
- Strictness versus availability. Rejecting a changed-payload reuse protects the books but may delay a legitimate correction. Provide a fast, auditable path for approved replacements as new operations.
- Hold versus freeze. Channels that cannot go dark, such as online ordering, can accept and record orders during the window and apply them after the handover. Customers may then see delayed confirmations. That trade is usually better than duplicates, but the business should choose it knowingly.
- Throughput cost. Atomic claims and conditional writes reduce peak throughput compared with unconstrained parallel workers. Size the window with that in mind.
- Extra build effort. The ledger and reconciliation tooling cost engineering time up front. For low-volume, low-consequence classes, a simpler freeze may be sufficient. Reserve the full design for operations where a duplicate or a loss has real financial or customer impact.
A Lower-Risk Path: Sequencing, Deployment Choice, and a 2027 Update
Key takeaway: Lower risk comes from cutting over by operation class, rehearsing in a production-shaped sandbox, and choosing a deployment model whose network and release controls you can actually exercise.
Sequence by consequence
- Read-only and easily reversible classes first. Catalog, price list, and reporting feeds can move early because an error is visible and cheap to fix.
- Operational classes next. Order intake and inventory movements move under the full ledger once control tests pass.
- Financial postings last. Invoices and payments move after the earlier classes have run cleanly through at least one close cycle.
A modular ERP architecture makes this sequencing practical, because a module such as CRM, sales, or inventory can take ownership of its own operation classes without forcing every integration to switch at once. That is an architectural property to verify, not assume. Ask each vendor, including ArionERP, to show which integrations and operation classes can move independently in a rehearsal.
Choose the deployment model you can operate
| Consideration | Cloud (SaaS) | On-Premises |
|---|---|---|
| Endpoint and network control during cutover | Vendor-hosted endpoints. Coordinate changes with the provider. | You control routing, firewalls, and timing end to end |
| Rehearsal environment | Depends on the sandbox offered. Confirm how closely it matches production behavior. | You can clone production-shaped environments, at your own infrastructure cost |
| Operational burden | Lower for infrastructure, but you still own integration logic and reconciliation | Higher: you own infrastructure, backups, and upgrade scheduling |
| Fit when | Your team wants fewer moving parts to operate during the window | Your data residency, network isolation, or change-control rules require direct control |
Neither model removes the ownership problem. Both need the controls above. For a closer look at how ArionERP positions the two options, see the Cloud page and the On-Premises page.
2027 Update: what to re-check as automation takes on more integration work
Two trends are worth re-testing against these controls. First, more integration traffic is now initiated by automated agents and AI-assisted workflows, not just by fixed system-to-system messages. An automated initiator can repeat, rephrase, or re-submit an action, so each initiated action needs the same tenant-scoped operation ID and approved-payload hash as any other operation. Our guide to AI-initiated ERP transactions covers that boundary. Second, API and webhook behavior changes over time as vendors release new versions. Re-run your duplicate, changed-payload, crash, and timeout tests after any upgrade of an endpoint you depend on. The framing is evergreen: whatever the technology, one owner per operation, one identity per intent, and verified state before any retry.
Planning a cutover with live integrations?
Bring your operation classes, senders, and rollback assumptions. We will walk through where ownership is unclear and which endpoint behaviors need verification.
Talk to ArionERP about cutover readiness for your integration estate.
Request a ConsultationConclusion: Five Actions Before You Schedule the Cutover
A cutover succeeds when every in-flight operation has exactly one owner and a recorded outcome. These five actions turn that principle into work you can assign this week.
- Inventory your operation classes and senders. List every inbound stream, queue, scheduled job, and outbound posting, and assign each a business owner and a consequence level.
- Write the ownership ledger before the runbook. Define the four states per class, who signs each transition, and the point of no return.
- Test the identity rules with real edge cases. Include duplicates, changed-payload reuse, repeat orders, amendments, concurrent workers, and a crash after acknowledgment.
- Verify target behavior in the actual API. Confirm idempotency, conditional updates, and webhook retry semantics for each endpoint, and request the current SOC 2 report and ISO certificate with their scope.
- Hold the gate. Require evidence for all twelve controls. If any one fails, move the date, not the standard.
About the ArionERP expert team
ArionERP is a modular, AI-enhanced ERP platform available as Cloud (SaaS) and On-Premises, developed as a product of Cyber Infrastructure (CIS) and launched in 2016. CIS has provided software development services since 2003. ArionERP's published security page describes its SOC 2 Type II and ISO/IEC 27001 status, which buyers should confirm through the current report and certificate. This article was reviewed by the ArionERP Expert Team.
Frequently Asked Questions
What is an ERP integration cutover?
It is the controlled switch of live integrations, such as storefront orders, supplier messages, and posting feeds, from a legacy system to a new ERP. It differs from data migration because the work is still arriving and changing while you move. The goal is that every in-flight operation ends up applied once, terminally failed with an owner, or in documented reconciliation.
Can we run the old and new ERP in parallel to be safe?
Parallel running is safe for read-only comparison and risky for consequential actions. If both systems can ship, invoice, or pay on the same event, you have created the duplicate you wanted to avoid. If you run in parallel, make one system the writer for each operation class and have the other only observe.
Is an idempotency key enough to prevent duplicates at cutover?
No. A key helps only if it is durable, scoped to the tenant, bound to the approved payload, and honored by the target. You also need atomic claiming, conditional writes on the target, and a rule that rejects the same key with changed content. Keys should also be opaque, since identifiers such as email addresses can be sensitive.
What should we do when a posting times out during the cutover window?
Do not resend immediately. Look up the authoritative operation state by tenant and operation ID. If it is applied with a matching hash, mark it done. If it is not found and the target cannot honor the same key, fence the operation or keep it unknown, because the original could still arrive late.
- Unknown means completion could not be confirmed.
- It is neither success nor verified failure.
When should a webhook receiver send a success response?
Only after the operation record and the scheduled work have been committed together. A success response then means "recorded and will be processed," not "processed." Sending it earlier risks losing work if the process crashes, and sending it later risks the sender retrying while you are still working.
Do SOC 2 or ISO 27001 reports show our cutover is safe?
No. Those attestations concern a vendor's control environment within a defined scope and period. They do not verify your integration logic, your reconciliation process, or your legal obligations as a data controller. Request the report, read its scope, and test your own cutover controls separately.
Who should own the data in dead-letter and quarantine stores?
A named business or IT data owner, not the project team by default. Payload stores often hold personal and commercial data, so they need defined retention, role-based access, and masking in logs. Access granted for the cutover should expire afterward.
How long should the freeze window be?
There is no universal length. Size it from your arrival rate, how long your slowest queue takes to drain with evidence, and how long reconciliation of unknown operations takes in rehearsal. Channels that cannot be frozen can accept and record operations during the window and apply them after handover.