A multi-million-euro Salesforce stack rebuilt on Odoo 16 for METRO's restaurant-tech arm — the commercial backend that powers DISH for tens of thousands of independent restaurants across Europe. We led the feature recreation: FastAPI gateway, RabbitMQ event bus, Vonage telephony, sales flow and product catalogue.
DISH is METRO's restaurant-tech arm — the SaaS platform tens of thousands of independent restaurants across Europe use to take reservations, build websites, run their menus and accept orders. BSS — Business Support Software — is the commercial backend behind it: subscriptions, billing, sales pipeline, customer support, telephony, the partner platform.
The brief was a Salesforce-to-Odoo migration: lift the entire commercial stack off a multi-million-euro-a-year subscription and rebuild it on top of Odoo 16. The savings argument was simple. The execution was not — over ninety custom Odoo modules, a parallel data-migration team, and a client engineering team spread across several vendors.
We led feature recreation from inside that team. Data migration was handled by a separate group; we did not own accounting. Everywhere else — the FastAPI gateway that other DISH tools call into, the RabbitMQ bus that keeps Odoo synchronised with its sibling systems, the Vonage telephony integration ported from Salesforce, the sales flow and signature consents, the product catalogue and subscription lifecycle — we wrote, maintained, or were the senior voice in the room.
We also pushed for engineering practices we'd brought from elsewhere: a unit-testing protocol that new modules had to clear before merge, sharper code-review workflow, and architecture decisions written into the repo where future teammates would actually find them.
FastAPI REST gateway — the Odoo-outside contract every sibling system talks to. Maintained.
RabbitMQ publish / subscribe; keeps Odoo and its sibling services in sync. Maintained.
Vonage telephony, ported from a Salesforce integration: dialler, recording, presence.
Queue presence, routing and channel-closure webhooks for the helpdesk team.
Sales order flow end-to-end on Odoo: quoting, signature consents, project handover, referral attribution.
Cross-module sales configuration surface.
Product master and the catalogue exposed to sales and the API.
Subscription lifecycle: billing cycle, renewal, cancellation.
Plan changes that respect billing periods, with prorated charges where they belong.
CRM extensions shaped for the marketplace. Maintained.
Cross-system partner identity reconciliation. Maintained.
Outbound messaging surfaces. Maintained.
Unit-testing gate every new module had to clear before merge, with coverage thresholds enforced in CI.
Recreated the live Salesforce experience inside Odoo, module by module — sales, products, CRM, helpdesk, telephony — while a parallel team moved the data. The goal wasn't 'Odoo's idea of a sales flow' but DISH's, with the keystrokes and shortcuts the agents already knew.
dish_api is the FastAPI REST gateway: JWT auth, dependency injection, services and controllers cleanly split, an OpenAPI contract the calling teams wire against without touching Odoo. dish_rabbit_mq is the event side — Odoo publishes domain events, sibling services consume them, with a mass-publishing path so backfills do not tail-load the broker.
Salesforce had handed Vonage a tidy integration; we put it back together on Odoo. Two modules — dish_vonage for the core (dialler, recording, presence) and dish_vonage_user_helpdesk for the routing, queue presence and channel-closure webhooks the helpdesk team relies on. The webhooks are under test so a Vonage-side rename doesn't break the dialler silently.
With a dozen vendors in the same codebase, the work survives only if the rules are written down. We brought a unit-testing protocol new modules had to clear before merge, a code-review template with the questions reviewers should actually ask, and architecture decisions kept in the repo rather than buried in a Confluence search.
dish_api is the FastAPI surface every other DISH service calls when it needs Odoo state. Built on the OCA fastapi module with our own dispatcher, services and controllers cleanly split; auth, caching, hooks and i18n in their own places; JWT auth gated by a fastapi_group. The OpenAPI spec is the contract — sibling teams wire against it without ever touching Odoo's ORM.
Odoo is the system of record for partners, contacts and subscriptions, but sibling services need to know when those change. dish_rabbit_mq publishes the events and subscribes to inbound ones. Edge cases learnt by iteration: archival actions that fired on every record (tightened by automated-action domains), establishment-and-contact deletes that selected the wrong records (fixed), and a mass-publishing path so a backfill doesn't tail-load the broker one event at a time.
Salesforce had handed Vonage a tidy integration; we had to put it back together on Odoo. Two modules — dish_vonage for the core (dialler, recording, presence) and dish_vonage_user_helpdesk for routing, queue presence and channel-closure webhooks. Webhooks come under test so a Vonage-side rename doesn't break the dialler silently.
DISH's sales agents had a particular shape to their day in Salesforce — quoting, signature consents, downstream project handover, referral attribution. dish_sale and its siblings reproduce that flow inside Odoo's sale.order with the same shortcuts and the same downstream consequences. The handover into dish_sale_project closes the loop.
A B2B SaaS lives by its subscriptions. dish_product_subscription owns the lifecycle; dish_product_upgrade_downgrade owns plan changes that respect billing periods — no surprise mid-cycle charges, prorated where it makes sense — with a test suite that pins the billing maths.
Unit-testing protocol imported from prior work: new modules need a real test suite before merge; coverage thresholds enforced in CI. Code-review template with the questions we wished reviewers were asking. Architecture decisions kept in the repo so they could be evolved rather than lost.