Sample Artefact · Architecture Decision Record

ADR-001 — Strangler-Fig Cutover for Legacy ERP → Odoo

• Status: Accepted
• Date: 2024-Q2 (anonymised — original engagement dates redacted)
• Engagement type: EUDR-driven ERP modernisation for a commodity importer
• Decision owner: Brainstack solution architect (engagement lead)
• Stakeholders: Client CFO, Client Head of Sourcing, Compliance Lead, Brainstack engineering lead

This is a redacted decision record published as a sample artefact. The client name, exact engagement dates, transaction volumes, and supplier counts have been removed. Architectural reasoning is unchanged. Republished as part of Brainstack's CXO sweep follow-up to give buyers a transparent view of how we document architectural decisions on production engagements.

Context

The client operates as a mid-market commodity importer sourcing from cooperative networks across multiple origin countries. The EU Deforestation Regulation (Regulation 2023/1115, "EUDR") imposed obligations on covered commodity operators that come into effect for large operators on 30 December 2026. Compliance requires, among other things, that every consignment placed on the EU market is accompanied by a Due Diligence Statement linking the commodity to one or more geolocation-identified production plots, with a documented chain of evidence demonstrating that the commodity is deforestation-free against a baseline of 31 December 2020.

The client's existing ERP — a legacy installation with bolt-on supplier and procurement modules — could not produce this evidence chain. Specific deficits:

• Supplier master data quality. An assessment surfaced an average of roughly three duplicate vendor records per supplier across the existing records, plus inconsistent country-of-origin coding.
• No geolocation capture. Supplier records had textual addresses only; there was no facility to associate one or more production plots (geometry) with a supplier or a consignment.
• No EUDR-shaped audit trail. Existing reporting was sufficient for internal accounting but did not produce a defensible due-diligence submission per Article 8 of the Regulation.
• Tight cutover window. The 30 December 2026 deadline placed a hard upper bound on rollout. Replacing the legacy ERP wholesale via a big-bang cutover was not an acceptable risk.

The client also had operational dependencies on the legacy ERP that ruled out "retire and replace" as a single-shot operation: open purchase orders, partial shipments mid-flight, and accounting reconciliations that span the fiscal-year boundary the cutover would otherwise cross.

Decision

We adopted the strangler-fig pattern to migrate the supplier, procurement, and consignment domains from the legacy ERP to Odoo over a phased rollout, with Odoo standing up as the new system of record one domain at a time. The legacy ERP continued to operate during the strangling period; both systems co-existed for a defined window.

Specifically:

1. Phase 1 — Supplier domain extraction. Odoo became the system of record for supplier master data. The legacy ERP was put behind a read-through proxy (a thin service that fetched supplier data from Odoo for any legacy code path that required it). New supplier records and updates were captured only in Odoo.
2. Phase 2 — Procurement & purchase orders. New POs originated in Odoo. The legacy ERP retained existing open POs through their lifecycle. A reconciliation service mirrored PO-status changes from Odoo back to the legacy ERP so the accounting bolt-on continued to function until its own cutover.
3. Phase 3 — Consignment & EUDR due diligence. Odoo became the source of truth for consignment records, linked to supplier-plot geometry collected via the offline-first PWA on the same engagement. EUDR Due Diligence Statements were generated from Odoo records.
4. Phase 4 — Accounting cutover. The legacy ERP was decommissioned at the next fiscal-year boundary, when both AR/AP states were quiescent.

Alternatives Considered

Alternative A — Big-bang cutover

Replace the legacy ERP entirely on a single date, freeze operations for the cutover window, run reconciliation against the new system.

Rejected. The acceptable freeze window was effectively zero given live shipment activity. The risk of a missed EUDR deadline driven by a failed cutover (and the resulting penalty exposure under Article 25 of the Regulation) was too high. A big-bang cutover also concentrates all risk on a single date with no rollback path.

Alternative B — Bolt-on EUDR module to legacy ERP

Add an EUDR-specific module to the existing ERP, retain supplier master data in the legacy system, add geolocation capture as a new field set.

Rejected. The supplier-data quality issue would not have been fixed by bolting a new module onto the same dirty data. The duplicate-vendor problem specifically would have produced inconsistent due-diligence submissions where the same supplier appeared multiple times with conflicting geolocation data. Additionally, the legacy ERP's reporting layer could not have produced an Article 8 submission without substantial custom development that would have approached the cost of replacement without delivering the long-term benefits of moving to Odoo.

Alternative C — Parallel run without strangling

Stand up Odoo alongside the legacy ERP, dual-write everything, switch over once Odoo is "ready."

Rejected. Dual-write across two systems with different data models is a known failure mode — drift accumulates faster than the team can reconcile it. This pattern works when the two systems are equivalents (e.g., two database instances of the same schema). Odoo and the legacy ERP did not have equivalent data models. The strangling approach instead designates a single source of truth at each phase, eliminating the dual-write reconciliation burden.

Consequences

Positive

• Reversibility at each phase. If Phase 1 had failed, the read-through proxy could be reversed in a single config change. This was actually exercised during shadow-mode validation — see Operational notes.
• EUDR deadline made. The Article 8 submission capability shipped well ahead of the 30 December 2026 deadline.
• Master-data quality fixed at the point of extraction. Duplicate supplier records were collapsed during Phase 1 migration via a fuzzy-match + human-confirmation review queue. Production data quality improved as a byproduct of the migration, not as a separate clean-up programme.
• No operational freeze. Procurement, shipping, and accounting continued to operate throughout the strangling period.

Negative / Acceptable trade-offs

• Operational complexity during the strangling period. Engineers had to reason about two systems with a thin reconciliation layer between them. Mitigation: the reconciliation service was the single most-tested component on the programme (contract tests, shadow-mode validation, observability dashboards in production).
• Longer total elapsed time than a big-bang cutover would have taken on paper. Each phase took longer than a parallel-cutover step would have done because each phase had to deliver a stable steady-state. Accepted trade-off given the risk profile.
• Bolt-on accounting module retained longer than ideal. The Phase 4 fiscal-year boundary was chosen for safety; in retrospect the team could have moved on AR/AP at the half-year boundary with slightly more reconciliation cost. Documented as a learning for the next similar engagement.

Operational Notes

• The read-through proxy was deployed under a LaunchDarkly-style feature flag with a percentage-rollout control. Shadow mode (proxy fetches from Odoo but legacy ERP also computes the result locally; both are logged and compared) ran for two weeks before the proxy was switched to primary.
• A material discrepancy surfaced during shadow mode — country-of-origin fields were normalised differently between the two systems for one multi-country supplier. The discrepancy was caught before any downstream EUDR submission relied on the data. The proxy did not go primary until this was resolved.
• Phase 1 (supplier extraction) included an automated migration script with a manually-reviewed exception queue. Approximately a single-digit percentage of supplier records required human review. The exception queue itself was retained as a feature in Odoo for ongoing supplier intake, where the same fuzzy-match logic now catches duplicates at creation.
• Geolocation data captured via the offline-first PWA used WGS-84 (EPSG:4326) coordinates to six decimal places — the precision called for by the EUDR technical guidance. Out-of-spec capture (e.g., GPS readings with HDOP above a configurable threshold) was flagged at capture time and routed to a re-survey queue rather than persisted as-is.

Compliance & Governance

• The decision was reviewed and accepted by the client's Compliance Lead prior to Phase 1 commencement.
• Audit trails for all phase-boundary cutovers were retained as part of the EUDR evidence package.
• Australian buyers reading this artefact: equivalent patterns apply for EUDR-impacted Australian commodity exporters. We default Australian workloads to AWS Sydney (ap-southeast-2) and design for Privacy Act 1988 compliance.

References

• EU Regulation 2023/1115 — Deforestation Regulation. eur-lex.europa.eu
• EU Regulation 2025/2650 — EUDR Amendment (deadline confirmation).
• Brainstack engagement context: see /case-study/odoo and /eudr-compliance for the public-facing summary.
• Brainstack methodology framing: see /software-development/application-modernization for the AWS 6Rs framework this engagement was scoped against.

This ADR is published as part of Brainstack Technologies' sample-artefact programme. It is shared under a Creative Commons CC BY-NC-SA 4.0 licence — free to reuse with attribution for non-commercial purposes. For a deeper discussion of how we'd approach a similar programme in your environment, get in touch.