Repair, integrate or replace the software at a broken handoff
Compare three ways to fix a known record handoff. Test ownership, corrections, duplicate events and recovery before selecting an integration or replacement.
Before replacing software or commissioning an integration, locate the exact point where a valid business record becomes missing, wrong or unusable. Then compare three responses to that same failure: repair the current setup, connect the systems or replace part of the flow.
This decision comes after the team can reproduce the problem. “The systems do not talk” is not specific enough to design a connection. The failure might be a missing approval, an unused existing feature or two systems assigning different meanings to “complete.”
Start with a handoff that failed
Use an invented example: a service office retypes completed work from a job system into accounting. Some approved extras are missed and some incomplete visits are billed. The tempting request is “sync completed jobs.” But neither problem is solved if the source completion flag carries unreliable information.
Write the required handoff in a sentence: “When the office accepts the completed scope and approved extras, create a draft invoice with the job reference and leave unresolved items visible.” Identify the authoritative record for scope, customer identity, quantities and billing approval.
That sentence gives each option the same job to do.
| Option | Evidence that favors it | Evidence against it |
|---|---|---|
| Repair the current setup | Existing fields and permissions can express the required decision; staff can use them | The product cannot represent the needed distinction without unreliable workarounds |
| Connect the systems | Both systems fit their jobs; one controlled transfer can preserve meaning and identity | Neither system owns the decision, or corrections cannot be reconciled |
| Replace part of the flow | The required operating model repeatedly conflicts with a product's limits | Replacement merely moves the same unclear process into a new screen |
This is a decision aid, not a rule that integration is cheaper or replacement is better. Estimate the actual work for each option, including maintenance and the transition period.
Compare the correction path, not just the first transfer
Ask whoever proposes an option to demonstrate the following record history:
- A completed job creates the intended draft invoice.
- The same event arrives again.
- An approved quantity changes after the first transfer.
- The customer mapping is wrong and needs correction.
- The receiving system is unavailable, then recovers.
For each step, record the expected result, who sees an exception and how the operator returns the records to agreement. A “search, then create” design should not be accepted without a concurrency test: two simultaneous runs could both search before either creates. The implementation needs a deliberate duplicate-prevention design.
AWS's engineering guidance on retries describes the role of caller-provided request identifiers in distinguishing repeated requests from new intent. That is a useful principle to test in a proposed integration, not evidence that a particular connector implements it. AWS: Making retries safe.
For an Odoo option, verify the exact plan and endpoint. Odoo 19.0's external API documentation states that external API access is available on Custom plans and not on One App Free or Standard. A product name or integration listing does not settle the subscription or implementation requirements. Odoo 19.0 external API.
Write down what would change your choice
Use a one-page option record with these fields: failure being fixed, record owner, configuration work, integration work, data conversion, operating owner, recurring maintenance, fallback and evidence still needed.
Make uncertainty visible. For example: “Repair remains viable if the existing job system can restrict billing approval to the office and preserve an approved version.” A demonstration that fails that condition changes the decision. It is more useful than assigning a speculative score to every feature.
Choose the smallest change that passes the complete record history and has an owner for daily exceptions. If none passes, return to the meaning of the handoff before buying more software. The one-job tracing worksheet supplies the record trail for that discussion.