How a Mid-Market Manufacturer Dropped SAP — and Vibecoded the Gap with Claude Code

A 200-person Czech auto-parts manufacturer was paying €380K per year for SAP ECC. With the 2027 end-of-support deadline approaching and S/4HANA quotes exceeding €1.2M, they migrated to Odoo in 14 weeks. The 23 custom SAP transactions that had no Odoo equivalent were vibecoded using Claude Code on Odoo.sh — guided by a Neo4j knowledge graph that mapped every dependency before a single line of code was written. Annual ERP cost dropped 84%.

The Client

A mid-market auto-parts manufacturer headquartered near Mladá Boleslav, Czech Republic — three production plants, two warehouses, 200 employees. They produce stamped and machined metal components for Tier 1 automotive suppliers across Central Europe. Annual revenue around €45M.

The company had been running SAP ECC 6.0 since 2012, implemented by a regional SAP partner over 14 months. Over the years, the internal IT team (two people) and external consultants had built 23 custom ABAP transactions covering quality gate workflows, supplier scorecards, intercompany billing between the three plants, and a custom MRP extension for surface-treatment scheduling.

Finance, sales, procurement, manufacturing, warehouse, and HR all lived inside SAP. Every business process touched it. The idea of leaving felt impossible — until the invoices made staying impossible too.

The Problem: The 2027 Cliff

SAP announced the end of mainstream support for ECC 6.0 in December 2027. Extended maintenance is available — at a 22% premium — but with limited scope: security patches only, no functional updates, no support for new integrations. The message from SAP was clear: migrate to S/4HANA or find your own way.

The client requested S/4HANA migration quotes from two SAP partners. The numbers:

• €1.2M migration cost (greenfield reimplementation recommended due to custom code volume)
• 18 months estimated timeline — and industry data shows 60% of S/4HANA projects exceed their schedule
• €420K/year projected post-migration TCO (RISE with SAP subscription + partner support)
• All 23 custom ABAP transactions would need rewriting for S/4HANA’s new data model — at €800–1,200/day ABAP developer rates

Meanwhile, the current SAP bill was already painful: €380K per year across licenses (€3,400/user for 120 named users), annual maintenance (22% of license fees), one part-time Basis administrator, and two ABAP developers on retainer for break-fix on the custom transactions.

There was also a hidden risk. The company’s WMS and a Salesforce-based CRM both accessed SAP data via RFC interfaces. Under SAP’s indirect access rules, this exposure could trigger additional licensing claims. Diageo learned this lesson the hard way — £54.5M — and AB InBev faced a $600M dispute over similar integrations.

The CFO’s summary: “We’re paying nearly half a million a year for a system that’s about to go dark, and the upgrade costs more than we spent on the original implementation.”

Step 1: Mapping Every Dependency Before Writing a Line of Code

The most dangerous part of any ERP migration isn’t the data — it’s the invisible web of custom logic that nobody fully understands. SAP’s own internal knowledge graph spans 452,000 ABAP tables and 7.3 million fields for S/4HANA alone. Our client’s 23 custom transactions were woven into this fabric in ways that no single person could map from memory.

Before touching Odoo, we built an enterprise knowledge graph in Neo4j. We extracted metadata from every custom ABAP program: which SAP tables it reads, which it writes, what RFC interfaces it exposes, which other custom transactions call it, and which user roles depend on it.

The result: 452 nodes (tables, transactions, interfaces, roles) connected by 1,800 edges (reads, writes, calls, depends-on). The graph immediately revealed three categories:

• Dead code (7 transactions) — no upstream callers, no recent execution logs. Legacy programs that had been superseded but never deleted. Safe to drop.
• Native Odoo match (4 transactions) — quotation workflows, reorder point calculation, leave management, bank reconciliation. Standard Odoo modules cover these 1:1. No custom code needed.
• Needs vibecoding (12 transactions) — quality gate workflows, supplier scorecards, intercompany billing, surface-treatment MRP, EDI import, pick-route optimization. These had no Odoo equivalent and required custom modules.

The graph also revealed dependency chains that dictated build order. The intercompany billing module (ZFI_INTER) depended on the interplant transfer module (ZPP_INTER), which depended on the surface-treatment MRP extension (ZPP_SURF). Build them in the wrong order and you can’t test anything. The graph gave us the exact topological sort.

Step 2: Core Migration — Weeks 1 through 8

With the knowledge graph showing us exactly what standard Odoo could handle, the core migration followed a proven path. We deployed Odoo 18 Enterprise on Odoo.sh and configured modules in order of business criticality:

1. Weeks 1–2: Finance — Chart of accounts mapped from SAP FI/CO, opening balances loaded, bank feeds connected. Czech localization (VAT, Intrastat, control reports) configured via Odoo’s l10n_cz module.
2. Weeks 3–4: Procurement + Inventory — 4,200 material master records migrated from SAP MARA/MARC. Vendor records from LFA1. Purchase order history (3 years) loaded for supplier analytics. Multi-warehouse setup matching the three-plant structure.
3. Weeks 5–6: Manufacturing (MRP) — Bills of materials from SAP CS, routings from PP. Work centers mapped to Odoo work centers. Production order history for costing baselines.
4. Weeks 7–8: Sales + CRM + HR — Customer master from KNA1, open sales orders migrated. HR employee records and leave balances transferred. The old Salesforce CRM was retired — its data merged into Odoo CRM, eliminating the indirect access risk entirely.

Data extraction used SAP IDocs and RFC pulls, transformed through Python ETL scripts, and loaded via Odoo’s base_import module. We migrated 5 years of transactional history — enough for trend analysis without carrying 14 years of dead weight.

Throughout this phase, Odoo.sh’s staging branches were critical. Every data load was tested first on a staging environment cloned from the production database. When the Czech VAT mapping had edge cases with reverse-charge invoices, we caught it in staging — not after go-live.

Step 3: Vibecoding the Gap — Weeks 9 through 14

This is where the project diverged from a traditional Odoo implementation. We had 12 custom SAP transactions with no Odoo equivalent. In a conventional project, each would require a functional specification, a developer quote, code review, and weeks of back-and-forth. At €150–200/hour for senior Odoo developers, the client was looking at another €200K+ and 4–6 months.

Instead, we vibecoded them using Claude Code running against Odoo.sh.

The workflow for each custom module:

1. Query the knowledge graph — extract the exact inputs, outputs, business rules, and downstream dependencies for the SAP transaction being replaced
2. Compose a Claude Code prompt — include the dependency context, Odoo model conventions, and the expected behavior described in business terms
3. Claude Code generates the module — models, views, security rules, and manifest in a single pass. Because Odoo is open source, Claude has already “studied” 40,000+ community modules and understands the framework’s inheritance patterns natively
4. Push to an Odoo.sh feature branch — automated deployment creates a live dev environment in minutes
5. Test with real data on staging — Odoo.sh staging branches clone the production database, so testing happens against actual purchase orders, BOMs, and accounting entries
6. Iterate or ship — most modules needed 2–3 prompt refinements before passing acceptance

Example: Supplier Scorecard Module

The SAP version (ZQM_SCORE) was an 1,800-line ABAP program reading from EKKO, EKPO, QALS, and MARA to compute a weighted score across four dimensions: delivery reliability, quality pass rate, price variance, and responsiveness. It generated a monthly PDF report and flagged suppliers below threshold for re-evaluation.

The knowledge graph told us: ZQM_SCORE reads from purchase orders and quality inspection lots, is called by ZQM_CERT (certificate tracking), and feeds into the quarterly supplier review workflow. No other custom transaction depends on its output format — meaning we had freedom to improve the UX.

Claude Code produced a complete Odoo module in a single session: supplier_scorecard with computed fields on res.partner, a scoring engine triggered by incoming shipment validation, a dashboard with drill-down by supplier and dimension, and automated email alerts replacing the static PDF.

Time: 4 hours from first prompt to deployed staging — versus the 3-week estimate from a traditional Odoo partner.

The contrast in development velocity was stark. SAP’s transport request system — SE80, SE09, STMS, change board approval, weekend deployment windows — meant a 3–6 week cycle for any custom change. With Odoo.sh, a git push triggers deployment in minutes. Claude Code plus Odoo.sh compressed the entire custom development phase from an estimated 6 months to 6 weeks.

Step 4: The Knowledge Graph as Test Oracle

The dependency graph didn’t just guide development — it became the acceptance test framework. For every node in the graph that was tagged “needs vibecoding,” we defined a test contract: given the same inputs the SAP transaction consumed, does the Odoo replacement produce equivalent outputs?

We exported sample input/output pairs from SAP for each custom transaction during the extraction phase. These became golden test fixtures. The knowledge graph’s edges told us the test execution order: you can’t test intercompany billing (ZFI_INTER) until interplant transfers (ZPP_INTER) pass, and that requires surface-treatment MRP (ZPP_SURF) to be green first.

Traversing the graph in reverse topological order gave us a systematic acceptance checklist:

1. Test leaf nodes first (no downstream dependencies) — pallet label printing, EDI import, pick-route optimization
2. Test mid-chain modules once their dependencies are green — supplier scorecards, commission calculation
3. Test the deeply coupled chain last — surface treatment → interplant transfer → intercompany billing → product costing

Four of the 12 modules failed their first acceptance run. In each case, the failure was a business rule edge case — not a structural problem. The supplier scorecard didn’t handle partial deliveries the same way SAP did. The intercompany billing module needed a rounding rule specific to Czech tax regulations. Claude Code fixed each within one prompt iteration, and Odoo.sh redeployed the fix in under three minutes.

By the end of week 14, all 12 custom modules passed acceptance against their SAP-derived test contracts. The knowledge graph had zero red nodes.

Results

Over five years, staying on SAP ECC with extended maintenance would cost €1.9M. The S/4HANA migration path totals €3.3M. The Odoo route — including the full migration, all vibecoded custom modules, and five years of Odoo Enterprise subscriptions — comes in at €312K. That’s an 84% reduction versus the status quo and a 91% reduction versus S/4HANA.

The client used the first year’s savings (€318K) to fund a demand forecasting project on top of Odoo — something that was never economically viable while SAP consumed the entire IT budget.