# ProjoMania — full content corpus for LLMs This file is the machine-readable companion to https://projomania.com/llms.txt — it contains the full English-language content of every service page, blog post, and case study, in markdown, for grounding LLM responses about ProjoMania. Updated on every deploy. Site: https://projomania.com Generated: 2026-10-06T03:59:44.624Z --- # Services ## Analytics & Reporting Source: https://projomania.com/en/services/business-solutions/analytics/ Summary: BI dashboards, reporting layers, executive scorecards, and the pipelines underneath them. Built so a finance or ops team can own them. ## Dashboards are the easy part. The model underneath is the work. Most BI engagements produce a handful of dashboards and leave the data model tangled. Six months later the dashboards disagree, the queries are slow, and nobody owns the logic. We build the model first and the dashboards on top — so the team that inherits it can actually maintain it. ## What we deliver - **Semantic layer** — in dbt, LookML, or the BI tool's modeling language, depending on the tool. One place where a metric is defined, used by every dashboard. - **Dashboards** — built on the semantic layer, not duplicated. - **Tests** — dbt tests or equivalent on every metric that matters. Broken data gets caught, not silently displayed. - **Access & governance** — row-level security where needed, audit logs, rotation. - **Training** — a handful of people from your team, so the tool doesn't silently die. ## Tools we reach for - **Metabase** — self-hosted, pragmatic, fast to deliver value. Our default for mid-size. - **Superset** — when the SQL freedom matters. - **Power BI** — Microsoft shops. - **Tableau / Looker** — enterprise. - **Odoo BI** — for reports that live natively inside Odoo. --- ## Data Migration & Integration Source: https://projomania.com/en/services/business-solutions/data-integration/ Summary: Move data between any systems, not just Odoo. Legacy migrations, M&A consolidation, cross-system pipelines. Audit trails included. ## Data migration beyond Odoo We built our migration discipline on Odoo, and we use the same discipline everywhere else. Moving data is structurally the same problem whether the source is Odoo, SAP, a 20-year-old on-prem application, or a stack of CSVs. ## What "properly" looks like for a data migration - **Audit first** — row counts, foreign-key integrity, duplicate rate, PII inventory. - **Target schema** — designed for the system you are moving to, not copy-pasted from the source. - **Mapping in code** — every transformation lives in a version-controlled pipeline. No hand-run scripts on cutover day. - **Validation** — row counts match, aggregates tie out, critical business constraints verified. - **Reconciliation report** — the delta between source and target, explained. - **Rollback** — a reversible cutover by default. ## Stacks we reach for - **Airbyte** (self-hosted or cloud) — off-the-shelf source connectors. - **Fivetran** — managed alternative when the finance model fits. - **dbt** — transformations, tests, docs. - **PostgreSQL + partitions** — the workhorse target for operational data. - **ClickHouse / BigQuery / Snowflake** — analytical targets. - **Custom Python / Go** — when the source has no connector and needs bespoke extraction. --- ## Digital Transformation Source: https://projomania.com/en/services/business-solutions/digital-transformation/ Summary: A roadmap, not a slide deck. Assessment, priorities, execution, and a partner who will also build the pieces the strategy calls for. ## A roadmap that ends with shipped software Digital transformation engagements fail when the strategy and the build are done by different people. We do both, and the strategy is shaped by what we know we can actually ship. ## The engagement 1. **Assessment** — systems you run, data you hold, processes that work, processes that don't, team capability. 2. **Target state** — the operating model you want, described in enough detail that a new team member could recognize it. 3. **Gap analysis** — the delta between current and target, categorized. 4. **Roadmap** — sequenced phases with costs, durations, dependencies, and the outcomes each phase unlocks. 5. **Phase zero** — the quick wins. We start here. Something visible inside the first few weeks. 6. **Execution** — phases one onward, delivered by us or with you, with governance and KPIs. ## How we avoid transformation theater - No 200-page strategy decks nobody reads. - Every phase has a measurable outcome, not just a deliverable. - Quick wins go first. If the first three months produce nothing, the project loses momentum. - Honest sequencing — we will not front-load the work that makes us look busy at the expense of the work that moves the business. --- ## ERP Strategy & Selection Source: https://projomania.com/en/services/business-solutions/erp-strategy/ Summary: Vendor-neutral advisory on what ERP to pick, what it actually costs, and whether to extend, migrate, or stay put. ## ERP selection that survives contact with reality Most ERP selection processes produce a spreadsheet of features and a winner that hits the most checkboxes. Six months in, the gaps show. We run selection as a structured engagement that checks the things spreadsheets cannot. ## Our process 1. **Current-state** — what you actually use, what you have paid for but don't use, where processes are manual, where spreadsheets have replaced the ERP. 2. **Requirements** — prioritized with your functional leads, weighted by business impact, not vendor capabilities. 3. **Longlist** — the set of candidates that could fit. Usually 5–8 systems, including "stay and extend." 4. **Shortlist** — the 2–3 that actually fit, scored against your weighted requirements. 5. **TCO model** — 3-year and 5-year costs with license, implementation, data migration, training, support, and realistic change-request load. Not the vendor's quote, our estimate. 6. **Recommendation** — including the recommendation against replacing, where that is right. ## Where our recommendation has gone - **Odoo**: manufacturing mid-market, cost-sensitive scaling, EU / MENA regional coverage. - **Microsoft Dynamics 365 Business Central**: deep Microsoft ecosystem, specific industry fits. - **NetSuite**: US-focused, finance-heavy, subscription revenue. - **SAP Business One**: certain manufacturing and distribution verticals, compliance-sensitive. - **Stay and extend**: more often than vendors like to hear. Sometimes the honest answer is to fix the process and keep the system. --- ## Process Automation Source: https://projomania.com/en/services/business-solutions/process-automation/ Summary: Automate manual workflows — inside Odoo, across tools, or as standalone scripts. Using whatever automation stack actually fits. ## Automation that pays for itself Automation projects fail for two reasons: automating the wrong thing, and building tools that nobody maintains. We pick automations that pay for themselves inside a year, and we ship them in tooling your team can own after we leave. ## Our toolkit - **Odoo automated actions & server actions** — where the process lives inside Odoo. - **n8n** — self-hosted, open source, the default for cross-system flows we expect to keep running. - **Zapier / Make** — for quick wins and prototypes. Reconsidered when volume justifies a self-hosted alternative. - **Custom Python / Node** — when the logic is too specific or too sensitive for an off-the-shelf workflow. - **RPA** — where a system has no API and a screen scraper is the only option. Used sparingly because these age badly. ## How we decide what to automate 1. **Measure** — how long does the manual version take, how often, who does it? 2. **Estimate** — cost to build and maintain versus cost to leave manual. 3. **Rank** — highest payback first. Ship quick wins inside the first few weeks. 4. **Instrument** — every automation has monitoring from day one. 5. **Review** — quarterly, retire the ones that no longer earn their maintenance cost. --- ## APIs & Integrations Source: https://projomania.com/en/services/development/apis-integrations/ Summary: REST, GraphQL, and event-driven integrations that connect your systems to each other and to the third parties you depend on. ## APIs & integrations — where systems actually meet Integration work is where projects often go quiet and bills go up. We have built enough of them to know which shortcuts cost you later and which abstractions pay for themselves. ## What we do - **Public APIs** — spec-first (OpenAPI or GraphQL SDL), versioned, authenticated properly, rate-limited, observable. Documentation is a deliverable, not an afterthought. - **Private / internal APIs** — for your mobile app, your web app, your partner channel. - **Third-party integrations** — payments, auth, email, CRM, shipping, tax, identity, messaging, commerce. - **Webhooks** — subscribers that are idempotent, retry sensibly, and do not lose events when the downstream is down. - **Event-driven architectures** — queues and streams where the workload actually benefits. Not as a status symbol. ## How we build things that keep working - **Contract first** — OpenAPI or SDL reviewed before code is written. - **Auth, auth, auth** — the most common production failure mode. OAuth2, JWT with rotation, API keys with clear scoping. No shortcuts. - **Rate limiting and idempotency** — every write endpoint idempotent; every consumer rate-limited. - **Observability** — request IDs, structured logs, dashboards, alerts. You should know something is wrong before a customer tells you. - **Tests** — contract tests, integration tests against real third-party sandboxes, synthetic probes in production. --- ## Cloud & DevOps Source: https://projomania.com/en/services/development/cloud-devops/ Summary: Cloud architecture, containerization, CI/CD, infrastructure as code, and the observability you need to operate it. ## Cloud & DevOps — the kind that quietly keeps things running Good infrastructure is invisible. It deploys when you merge, it tells you if something is wrong, it recovers from a failure without drama. We build for that state, not for a demo. ## What we do - **Cloud architecture** — the service map, the data flow, the deployment model, the security model. Reviewable before anything is built. - **Infrastructure as code** — Terraform or Pulumi. Nothing you depend on is clicked in a console and forgotten. - **Containers and runtime** — Docker, plus the right runtime (ECS, Cloud Run, Fly, Kubernetes, Nomad). We pick the lightest thing that fits. - **CI / CD** — GitHub Actions, GitLab CI, or Buildkite. Branch deploys, staged rollouts, deploy gates. - **Observability** — metrics, logs, traces, and alerts that page the right person. Grafana, Datadog, Honeycomb, Sentry. - **Security** — IAM hygiene, secrets management, network segmentation, audit logs, SSO. ## Where we save you money - Right-sizing instances against real observed load, not worst-case. - Reserved / savings plans where usage supports them. - Consolidating overlapping vendors. - Dropping orchestrators you do not need. - Caching and CDN strategy that actually bites. ## The handover we prefer Every engagement ends with your team owning the platform — accounts, repos, runbooks, on-call rotation. We hang around on retainer where useful. We do not build things we cannot hand over. --- ## Mobile Applications Source: https://projomania.com/en/services/development/mobile/ Summary: Cross-platform and native mobile apps — designed, built, submitted, and iterated after launch. ## Mobile apps built to ship, and to age well Cross-platform is our default: React Native or Flutter, with a shared codebase that covers iOS and Android and keeps maintenance sane. We go native when the app genuinely needs it — performance-critical graphics, deep platform integrations, hardware that cross-platform wraps awkwardly. ## What a mobile engagement includes - **UX and UI** — Figma designs, reviewed with you, built to the platform conventions. - **Build** — typed codebase, tests on business logic, reviewed PRs. - **Services layer** — auth, push, analytics, crash reporting, feature flags, remote config. - **Store submission** — screenshots, listing copy, review answers, publishing under your developer accounts. - **Post-launch** — crash and analytics review, iteration plan. ## Stacks we use **Cross-platform** — React Native (Expo-first when suitable), Flutter. **Native iOS** — Swift, SwiftUI, UIKit where warranted. **Native Android** — Kotlin, Jetpack Compose. **Backend** — Node, Python, or Go with a typed API. REST or GraphQL. **Infra** — OTA updates (Expo / CodePush), feature flags (LaunchDarkly, Unleash, or self-hosted), analytics (PostHog, Amplitude, or similar). --- ## Web Applications Source: https://projomania.com/en/services/development/web/ Summary: Custom web applications, internal tools, dashboards, and SaaS MVPs — built on modern stacks and deployed to cloud or on-prem. ## Web applications — whatever the project actually needs We build the kind of software that does not come out of a box. Custom internal tools, customer-facing products, SaaS MVPs, dashboards, admin consoles, portals — in whichever stack the project justifies. ## Our default stack, and why - **Next.js or Astro + React** — Next for dynamic apps with auth and server-side data; Astro for content-first sites. - **TypeScript strict** — the tax you pay for a year of not getting paged. - **PostgreSQL + Prisma or Drizzle** — boring, reliable, queries you can read. - **Cloud-native deploys** — Vercel, Cloudflare, Fly, or self-hosted on AWS / GCP. - **Tailwind for styling** — fast iteration, no style bloat. ## Where we deviate from defaults We go to Go or Python when the workload is backend-heavy. We pick Vue or Svelte when a team is already committed to them. We self-host when the budget or the compliance story demands it. The stack follows the project, not the other way around. ## How we actually run a build 1. **Kickoff** — outcomes, constraints, success criteria, and the smallest thing we could ship next. 2. **Sprints** (1–2 weeks) — working software every sprint, reviewed with you. 3. **Integration early** — the third-party pieces go in as soon as they can, not at the end. 4. **Staging + prod** — separate, real-data-shaped, CI-deployed. 5. **Handover** — code review, runbook, architecture doc, and optional support plan. --- ## Odoo Customization Source: https://projomania.com/en/services/odoo/customization/ Summary: Studio configurations, custom modules, QWeb reports, OWL components, and API integrations. Clean code, upgrade-safe, tested. ## Customization, done well Odoo customization ranges from a Studio-added field to a multi-module suite with tests and a CI pipeline. The discipline matters as much as the code — customizations that do not survive an upgrade are just technical debt with an invoice. ## What we do **Studio customizations** — fields, views, automated actions, server actions, reports, approvals. Fast, low-ceremony, upgrade-conscious. **Custom modules in Python / XML / OWL** — when the logic is non-trivial. Clean ORM code, QWeb and PDF reports, OWL front-end components, ACLs and record rules, module tests, migration scripts. **Integrations** — external APIs (Stripe, PayPal, Shopify, QuickBooks, Salesforce, HubSpot, Slack, Twilio, and the rest). XML-RPC and JSON-RPC clients. Webhook subscribers. Event-driven sync with queues where appropriate. **Code audits** — someone else wrote the module and you inherited it. We review it, report on upgrade risk, test coverage, and security, and rewrite what should be rewritten. ## How we write code we stand behind - Version-controlled in a repo you own, Conventional Commits, PRs reviewed before merge. - Pinned to your Odoo version; migration scripts when we ship across versions. - Tests where they catch things that matter (critical workflows, money-affecting logic, integration boundaries). Not tests for the sake of coverage numbers. - Documentation that says _why_ the customization exists, because "what" is already in the code. - Security: no SQL concatenation, parameterized `env.cr.execute`, proper ACLs, sensible record rules. --- ## Odoo Implementation Source: https://projomania.com/en/services/odoo/implementation/ Summary: From greenfield rollout to legacy-ERP replacement. Discovery, configuration, data loading, training, and go-live — one team from first workshop to warranty. ## Implementation, from first workshop to go-live An Odoo implementation is not a software install. It is a business-change project where the software happens to be Odoo. We run it like one. ## What's in a typical implementation 1. **Discovery** — workshops per functional area. We model your process on Odoo's primitives and show you the shape of it before you commit to a scope. 2. **Scope sign-off** — in writing, with the configuration backlog, the customization backlog, and the data-migration plan all on the table. 3. **Configuration and customization** — in sprints. You see working software after each sprint. 4. **Data migration** — we load your legacy data into the new system. At least two full rehearsals before go-live. 5. **Training** — end users, admins, and power users. Delivered on the real system, with your data. 6. **Go-live** — a scheduled cutover, parallel running if your risk tolerance requires it, hypercare after. 7. **Warranty** — typically 30 days after go-live of priority response for defects. Everything after is on a support plan. ## Modules we cover **Operations** — Inventory, Manufacturing, Maintenance, Quality, Repair, Field Service. **Finance** — Accounting, Invoicing, Expenses, Documents, Sign. **Sales** — CRM, Sales, Subscriptions, Rental, Point of Sale, eCommerce, Website. **People** — Employees, Recruitment, Attendances, Time Off, Payroll, Appraisal, Skills. **Productivity** — Project, Timesheet, Helpdesk, Planning, Calendar, Discuss. ## What we bring that a generic consultancy does not - We have shipped every migration shape Odoo supports. When discovery surfaces something awkward, we have seen it before. - We are multi-stack. When your process actually needs a custom app around Odoo rather than a custom module inside it, we can build both. - We say no to bad ideas. Most implementations fail because nobody stopped the wrong scope from being built. --- ## Odoo Migration Source: https://projomania.com/en/services/odoo/migration/ Summary: Every kind of Odoo database migration — forward, backward, split, merge, currency. Including the rare capabilities most partners won't touch. ## Five kinds of Odoo migration, one specialist team Most Odoo partners do upgrades. A few do downgrades. Fewer still can split a multi-company database into pieces, merge acquisitions into one, or migrate every monetary field to a new currency with an auditable conversion trail. We do all five. Every migration is different, but the ingredients are the same: understand the data, build a test migration, stress it under realistic conditions, run UAT with your people, cut over with a rollback plan, and stay on-site during hypercare. We do not improvise on go-live day. ## What's covered Database migration — the records themselves: customers, vendors, products, accounting, inventory, manufacturing orders, subscriptions, every custom model you have. We map source to target schema, transform where the data model has changed, and validate row counts and field coverage against the source. Code migration — your custom modules, Studio customizations, automated actions, server actions, QWeb reports, OWL components. We modernize what the new version has evolved and keep the behavior your users already know. Configuration migration — companies, users and groups, chart of accounts, fiscal positions, taxes, payment terms, pricelists, warehouses, routes, BoMs, workcenters. Integration migration — third-party connectors, XML-RPC / JSON-RPC bindings, payment acquirers, shipping providers, webhooks, ETL pipelines pointing at the old DB. ## The process we trust 1. **Discovery** — we inventory the source, measure record counts per model, catalogue every custom module, and flag dependencies. A go/no-go conversation with you happens here, not later. 2. **Test migration** — we replicate your production into an isolated environment and run the full migration end to end. You get a working replica of the target system with your data in it. 3. **UAT gates** — your functional leads sign off per area: accounting, sales, purchase, inventory, manufacturing, HR. We fix issues as they surface, then re-run. 4. **Production cutover** — a scheduled window with a time-boxed checklist, a final delta migration of data changed since UAT, validation, and a single go/no-go call. Rollback path documented and rehearsed. 5. **Hypercare** — two weeks on-site (or remote equivalent) with daily syncs and priority response. Your users will find things during real use — this window exists to catch them. ## Why clients choose us for migrations - We take on the cases most partners refuse: downgrades, currency migrations, splits, merges, legacy versions. - Every migration is test-driven. We run your migration on a replica before we touch production. - Every engagement has a rehearsed rollback. - We work in your language — all 10 of them. --- ## Currency Migration Source: https://projomania.com/en/services/odoo/migration/currency-migration/ Summary: Archive a legacy company on its old currency, create a new company in the target currency, and migrate every monetary field with a documented FX conversion. Full audit trail included. ## A rare capability. The reason clients come to us. Odoo does not support changing the functional currency of an existing company. The supported path is a **new company in the new currency**, a full migration of opening balances and reference data, and an archive of the old entity. That migration is invasive, error-prone if done manually, and has no room for "close enough" on audit-sensitive figures. We built a repeatable process for it. ## The methodology 1. **Archive the legacy company** — no new transactions, but full historical read-access preserved. 2. **Create the new company** — same chart, policies, and reference data as the legacy, but denominated in the target currency. 3. **Migrate reference data** — customers, vendors, products, accounts, fiscal positions, pricelists. 4. **Publish the FX rate table** — before any monetary field is converted, the rate table is signed off by your finance team. Rates are auditable and reproducible. 5. **Convert monetary fields** — every monetary field in every model we have identified gets converted with documented rules for rounding, precision, and carry. 6. **Audit report** — a line-by-line ledger of every converted figure: old value, rate applied, new value, source record. 7. **UAT and cutover** — standard migration discipline applies. ## Where currency migrations get interesting - Multi-company groups where one company moves and the others stay — consolidations need to handle both. - Ongoing contracts, subscriptions, and pricelists with multi-currency terms. - Open invoices, uninvoiced manufacturing costs, WIP balances. - Statutory reporting that needs historical continuity. We have handled each of these. The deliverable you care about is the audit report — the one your auditors will ask for, and that we produce by default. --- ## Odoo Database Merge Source: https://projomania.com/en/services/odoo/migration/database-merge/ Summary: Merge multiple Odoo databases into one multi-company database — after an acquisition, a reorganization, or a deliberate consolidation. ## Consolidating databases is messy. It doesn't have to be risky. Merging Odoo databases is where the hard problems live: ID conflicts, master-data duplication, chart-of-accounts misalignment, different customization stacks, different module versions, different integrations. We handle it as a structured engagement, not a single migration script. ## What the merge actually includes - **ID conflict resolution** — two source databases can both have an `res.partner` with ID 42. We rewrite IDs on one or both sides so the target database has a single clean namespace, and preserve every foreign-key reference across the rewrite. - **Master data reconciliation** — customers, vendors, products, employees, chart of accounts, fiscal positions, taxes. Duplicates go through a match-and-confirm step before the target load. - **Chart of accounts unification** — a common CoA that covers all sources, with a per-source mapping you sign off on. - **Module consolidation** — where source databases have different customizations, we decide together which behavior wins in the target, or we port both behaviors as configurable. ## Two shapes for a merge 1. **Full historical** — all records from every source become records in the target. Reporting continues to work against the unified history. 2. **Forward-only** — the new multi-company database starts from the merge date, and the sources are archived for audit but not actively used. Faster and cleaner where historical reporting against legacy entities isn't required. --- ## Odoo Database Split Source: https://projomania.com/en/services/odoo/migration/database-split/ Summary: Split a multi-company Odoo database into multiple single-company databases — or extract one company while keeping the rest intact. ## One database, many companies — sometimes that needs to change A multi-company Odoo database is convenient until it isn't. Divestitures, subsidiary independence, data-isolation requirements, and pure performance have all driven clients to ask us to split. ## What we actually do - Map every record to its owning company. - Decide with you how **shared** records are handled (contacts used everywhere, products shared across the group, account templates). - Provision one target database per company being extracted. - Migrate records preserving referential integrity on each target. - Reconcile inter-company transactions so your finance team can close them out cleanly. - Run UAT per target and cut over on a schedule. ## Shared-record strategies we support | Strategy | When it fits | | -------------------------- | --------------------------------------------------------------------------- | | Duplicate into each target | Contacts and products your teams edit independently going forward | | Keep a shared source | A central product catalog maintained by the group, with downstream syncs | | Curate per target | Sensitive contacts or product lines that shouldn't cross company boundaries | ## Why a split without us is painful The hard part isn't the split — it's the edge cases. Accounting periods straddling the split date, manufacturing orders with components from one company and a customer from another, subscriptions billed centrally, stock transfers in flight. We inventory every edge case and resolve it before production migration. --- ## Odoo Downgrade Source: https://projomania.com/en/services/odoo/migration/downgrade/ Summary: Most Odoo partners refuse downgrades. We don't. Move a database and its code to an older Odoo version — safely, with a rehearsed rollback. ## A rare capability. Most partners refuse downgrades. We don't. Odoo upgrade guides always assume you are going forward. When you need to go back — after a problem release, a licensing shift, a dependency that has not kept pace — most partners will tell you it is impossible. It is not. It is harder than an upgrade, but it has a process, and we have the process. ## Why downgrades happen - **Regression risk** — a major version introduced behavior your business cannot absorb, and patching is slower than moving back. - **Third-party lag** — a module or integration you rely on has not yet shipped support for the newer Odoo release. - **Licensing / cost** — moving from Enterprise back to Community to rebuild on your terms. - **Fleet standardization** — mergers and acquisitions frequently land multiple Odoo versions in the same group, and the common denominator is older than the newest. ## What makes downgrades hard On an upgrade you can add new fields with defaults. On a downgrade, newer fields may have no place to go. Our deliverable on the first pass is the **data-loss report** — a full mapping of what carries over, what gets archived, and what is dropped, with your functional leads signing off per area before we touch anything. ## What you get 1. A **source audit** that identifies every newer-only field and relation, model by model. 2. A **data-loss report** — the mapping, in human-readable form, and the archive strategy for everything that does not fit the target schema. 3. A **test migration** against a replica. You see the result before we commit. 4. A **UAT gate** with your people signing off per functional area. 5. A **production cutover** with a rehearsed rollback path. 6. **Hypercare** after go-live. ## What we will tell you up front If a downgrade is the wrong answer, we will say so. Sometimes the cleaner path is to patch forward, or to keep the newer version and replace a dependency. Our job is to help you ship the right decision, not to sell you a downgrade. --- ## Odoo Upgrade Source: https://projomania.com/en/services/odoo/migration/upgrade/ Summary: Move your Odoo database and its customizations to a newer major version, with code migration, test runs, UAT gates, and a rehearsed cutover. ## From any version. To the one you need. An Odoo upgrade is rarely "just the database." It is the code you have added, the Studio fields your team depends on, the integrations that connect to the rest of your business. We handle all of it. ## What we migrate - The full production database, records and configuration included. - Every custom module you have installed, updated for the target version's APIs, ORM, and view conventions. - Studio customizations (new fields, automated actions, reports, views). - QWeb and PDF reports. - OWL / JS components, web extensions, ACLs and record rules. - All integrations that touch the database (XML-RPC, JSON-RPC, webhook subscribers). ## How an upgrade runs 1. **Audit** — we take stock of what you have. Data volume, custom code, Studio, integrations, licensing. 2. **Target environment** — we stand up the new version in an isolated environment. 3. **Test migration** — the first full run. You get a working replica of the target version with your data. Expect issues; this is the point. 4. **Iterate** — we fix, re-run, re-validate, until the test migration is clean. 5. **UAT** — your people use the test system against real scenarios. Sign-off per functional area. 6. **Cutover** — scheduled downtime, final delta migration, validation, go/no-go, hypercare begins. ## Upgrade paths we handle most | From | To | Complexity | | ------------ | ---------- | ---------------------------------- | | v15 / v16 | v17 / v18 | Routine | | v13 / v14 | v17 / v18 | Complex (intermediate hop usually) | | v12 or older | v17 / v18 | Multi-step | | Community | Enterprise | Handled as part of the upgrade | Use the [version compatibility matrix](/en/version-compatibility/) to explore specific pairs. --- ## Odoo Support & Maintenance Source: https://projomania.com/en/services/odoo/support/ Summary: Ongoing partnership after go-live — bug fixes, performance tuning, security patches, upgrade planning, and a predictable SLA. ## After go-live, the work changes. We don't. An Odoo implementation that nobody tends becomes an Odoo liability. Support isn't glamorous — it's the difference between a system that keeps earning and one that slowly stops working. ## What's covered in support - **Incident response** — tickets triaged, reproduced, fixed, released. SLA tiers you can choose. - **Performance tuning** — slow queries, inefficient ORM, long-running crons, storage growth. - **Security patches** — Odoo Security Advisories applied on schedule; critical patches out of band. - **Version-upgrade planning** — we watch your version's end-of-life and tell you when to schedule the next migration. - **Backups & DR** — documented, tested, restorable. Quarterly restore rehearsals on request. - **User helpdesk** — optional tier where end-user how-do-I questions come to us rather than your IT team. ## What's _not_ covered Greenfield features. Those go through a normal customization engagement — no surprise charges on a support bill for work that is clearly a project. ## SLA tiers | Tier | Coverage | P1 response | P2 response | P3 response | | -------- | ----------------------- | ----------- | ----------- | ----------- | | Bronze | Business hours Mon–Fri | 4h | 1 day | 3 days | | Silver | Extended business hours | 2h | 8h | 2 days | | Gold | 24/5 | 1h | 4h | 1 day | | Platinum | 24/7 | 30m | 2h | 1 day | Full definitions and exclusions on the [SLA page](/en/legal/sla/). --- ## Odoo Training Source: https://projomania.com/en/services/odoo/training/ Summary: End-user, admin, and developer training — on-site, remote, or self-paced. On your real data, not a demo tenant. ## Training that sticks End users learn faster on their own data than on a sample database. Admins learn faster when the exercises reflect their actual configuration. Developers learn faster when the project they are shown is the one they will maintain. We build training around that principle. ## Programs we run **End-user training** — for the people who use Odoo every day. Per functional area. Typically 4 to 16 hours per area depending on depth. **Admin training** — for your internal Odoo admin. User and group management, Studio, automated actions, reports, imports, common support workflows. **Developer training** — the Odoo framework, ORM, views, QWeb, OWL, tests, modules, and the hard-won conventions we have picked up shipping real projects. **Train-the-trainer** — we train a small group from your organization who then run rollouts internally. Best for large fleets. ## Format - **On-site** — in MENA, and further on request. - **Remote live** — synchronous, small cohorts, interactive. - **Self-paced** — recorded sessions, exercises, and a contact for questions. - **Hybrid** — a live intensive up front, self-paced follow-through after. --- # Insights (blog) ## Choosing a stack in 2026: React, Next.js, or Astro for your next project Source: https://projomania.com/en/blog/choosing-stack-2026/ Summary: We pick a stack based on three criteria: project fit, total cost of ownership, and your team's long-term ability to maintain it. Here's how that plays out in practice. Published: 2026-02-14 Author: Mohamed Magdy Stack choice is a bet on the next five years. The hot stack today is often the legacy cost tomorrow. We pick by three criteria: project fit, total cost of ownership, and your team's ability to maintain what we ship. Here is how that plays out for the three stacks we reach for most often. ## Astro **Picks for:** content-heavy marketing sites, docs, blogs, sites where SEO and Core Web Vitals matter more than client-side interactivity. **Why:** near-zero JS by default. Partial hydration only where interactivity earns its cost. First-class MDX. Built-in image optimization, sitemap, i18n. Static by default; server routes where needed. **Avoid when:** the site is actually an app with stateful UI on every page. Use Next for that. ## Next.js **Picks for:** dynamic apps. Auth, per-request server-side data, middleware, ISR, streaming SSR. SaaS products. Internal tools that pretend to be marketing sites. **Why:** the most mature full-stack React framework. Vercel's performance infra is genuine. App Router is powerful once you accept its mental model. **Avoid when:** the project is content-first. You pay for flexibility you don't need. ## Plain React + a backend **Picks for:** dashboards, back-office tools, embedded apps, anything where SEO is a non-goal. **Why:** less magic, explicit routing, smallest vendor surface. Easier to hand over to a team that wants to own the deploy pipeline. **Avoid when:** content matters for SEO. Static site generation is not what you're optimizing for. ## The question we actually ask What does the next team member — who you haven't hired yet — need to be able to do? If the answer is "edit a page of content," Astro. If it is "add a feature to a dashboard," Next or plain React. The stack should favor the work you expect to do most. --- ## Ten ways Odoo migrations fail (and how to avoid each one) Source: https://projomania.com/en/blog/common-odoo-migration-failures/ Summary: Every rescue engagement we take on traces back to a handful of avoidable mistakes. Here are the ten we see most, and the specific guardrail that prevents each. Published: 2026-06-03 Author: Mohamed Magdy We get called in to rescue migrations that went wrong, and the post-mortems rhyme. The same ten mistakes account for nearly all of them. None are exotic. All are avoidable with one specific discipline each. ## 1. No test migration The team ran the upgrade straight on production. **Guardrail:** every migration runs end-to-end on a replica first, as many times as it takes to come out clean. ## 2. Custom modules never audited Nobody read the manifest or model files before kickoff, so surprises landed at UAT. **Guardrail:** inventory every custom module with last-modified dates before quoting the work. Dead modules get deleted, not migrated. ## 3. Studio customizations assumed safe Studio configurations carry over differently between versions and silently change behavior. **Guardrail:** catalogue every Studio change and re-validate it on the target version. ## 4. Integrations tested last XML-RPC/JSON-RPC callers assumed a field or method that moved, and broke after cutover. **Guardrail:** re-run every integration against the test database before go-live, not after. ## 5. No data-loss report on downgrades Newer-version fields have no home on an older version, and the team discovered the losses during UAT. **Guardrail:** produce an explicit field-by-field data-loss report before any [downgrade](/en/services/odoo/migration/downgrade/). ## 6. Skipping too many majors at once A heavily customized database jumped four majors in one step and every transformation compounded. **Guardrail:** for customized databases, do not skip more than two majors per hop. Plan intermediate, testable stages. ## 7. Accounting close not validated Finance found discrepancies after the books were already on the new version. **Guardrail:** run a full accounting close on the test database with the finance lead signing off before cutover. ## 8. No rehearsed rollback Cutover went sideways and there was no tested way back. **Guardrail:** the rollback path is documented and rehearsed, with explicit go/no-go criteria. ## 9. Cutover window underestimated The migration ran long and collided with a billing run or shipment. **Guardrail:** time the full rehearsal, then schedule the real cutover with margin and a clear validation checklist. ## 10. No hypercare after go-live The team moved on the day after cutover and small issues festered. **Guardrail:** a hypercare window is on the calendar before launch, with someone owning it. ## The pattern Nine of the ten share a root cause: **assuming instead of testing.** A rehearsed migration on a replica, an audited module list, and a signed-off rollback plan prevent most of this list outright. We packaged the full version of this into a [migration readiness checklist](/en/resources/) you can download — it is the same one we run at the start of every [Odoo migration](/en/services/odoo/migration/) engagement. --- ## Currency migration in Odoo: step by step Source: https://projomania.com/en/blog/currency-migration-step-by-step/ Summary: Why Odoo does not let you change a company's functional currency, what the supported path looks like, and the deliverables that make the migration audit-safe. Published: 2026-03-05 Author: Mohamed Magdy Odoo does not support changing the functional currency of an existing company once transactions exist. The supported path is a new company denominated in the target currency, with a documented migration of balances and reference data, and an archive of the legacy company for audit. ## The methodology 1. **Archive the legacy company.** No new transactions, but full historical read access preserved. 2. **Create the new company** in the target currency, with the same chart of accounts, policies, and reference data structure. 3. **Publish the FX rate table.** Before any monetary field is converted, the rate table is signed off by finance. 4. **Convert monetary fields** — balances, open items, pricelists, subscriptions — with documented rounding and precision rules. 5. **Reconcile.** Totals match the archive, to the cent. 6. **Cutover** with a rollback path. ## The audit report The most important deliverable. A line-by-line ledger of every converted figure: record, source currency, source value, rate applied, target value. Your auditors will ask for it; we produce it by default. ## Where currency migrations get interesting - Multi-company groups where one company moves and the others do not — consolidations must handle the mixed-currency period. - Open invoices, uninvoiced WIP, manufacturing costs still being amortized. - Ongoing contracts and subscriptions with multi-currency terms. - Statutory reporting that needs historical continuity in the new base. Each of these has a pattern. We have shipped every one. --- ## Odoo, Dynamics, or SAP: a vendor-neutral ERP selection framework Source: https://projomania.com/en/blog/erp-selection-framework/ Summary: The framework we run ERP selection engagements on. Weighted requirements, TCO modeling across 5 years, and the honest conversation about staying put. Published: 2026-02-02 Author: Mohamed Magdy ERP selection goes wrong in a predictable way: a committee scores feature checklists, the "winner" wins on breadth rather than fit, and two years later the shortlist runner-up would have been the better call. Here is the framework we run engagements on to avoid that. ## Requirements before candidates Most selection processes start with candidates and retrofit requirements. We invert it. Two weeks of functional workshops, per business area, with the question: what has to work, what should work, what would be nice. Weighted 3/2/1. Scored against business impact, not vendor capabilities. ## TCO over 5 years Licensing is the smallest line in real ERP TCO. Implementation, data migration, change requests, training, integration, and support dwarf it. Our TCO model covers five years because three is optimistic on how long implementations take to settle. ## The four candidates most shortlists end up with - **Odoo** — manufacturing mid-market, cost-sensitive scaling, regional coverage, internal team that can handle maintenance. - **Microsoft Dynamics 365 Business Central** — deep Microsoft ecosystem, strong distribution / commerce. - **NetSuite** — US-focused, finance-heavy, subscription revenue, multi-entity. - **SAP Business One** — manufacturing and distribution verticals, compliance-sensitive. The fifth candidate is "stay and extend" — and it is the right answer more often than vendors like to hear. ## What the output looks like A 1-2 page memo and a scoring workbook. Not a 200-slide deck. Enough to take to a board, specific enough to act on, short enough to be read. ## Our selection commitment We recommend based on requirements. We do not take referral commissions from ERP vendors. If the right answer is Odoo, we implement it. If it is anything else, we help you run the implementation PMO regardless of whom you pick. --- ## Mobile app or mobile web? How to choose for your next build Source: https://projomania.com/en/blog/mobile-app-vs-mobile-web/ Summary: A native app is not automatically the answer — and a responsive web page is not automatically cheaper in the long run. Here is the decision framework we use to pick the right mobile approach for a project. Published: 2026-05-15 Author: Mohamed Magdy "We need a mobile app" is a conclusion, not a requirement. Sometimes it is the right one. Often a responsive web app or a PWA does the job for a fraction of the cost and none of the app-store overhead. Here is how we decide. ## The three options - **Responsive / mobile web** — one codebase, served in the browser, works everywhere with a URL. No install, no app store. - **Progressive web app (PWA)** — a web app with offline support, an install prompt, and push on supported platforms. Most of the "app feel," still shipped as web. - **Native / cross-platform app** — React Native or similar, distributed through the app stores, with full access to device capabilities. ## When mobile web is enough - The core use is content, forms, dashboards, or transactions that work fine online. - Users reach you occasionally and a URL is more convenient than an install. - You want one codebase and the fastest path to every device. - SEO and shareable links matter — web wins here outright. For a large share of business tools, this is the honest answer, and it is what our [web development practice](/en/services/development/web/) ships most often. ## When a PWA is the sweet spot - You need light offline support and an icon on the home screen. - Push notifications would help, but app-store distribution is not essential. - You want app-like ergonomics without maintaining two native codebases. ## When you genuinely need native - **Deep device integration** — Bluetooth, advanced camera control, background location, secure hardware. - **Offline-first field work** — long stretches with no connectivity and on-device data that syncs later. - **Performance-critical interactions** — heavy animation, real-time media, or large local datasets. - **App-store presence is a requirement** — your buyers expect to find you there. When the case is real, cross-platform native (React Native + Expo) gives you one codebase for both platforms. Our [mobile development service](/en/services/development/mobile/) covers that path, including the offline-sync engines that field apps live or die on. ## The questions that decide it 1. Do users need the product offline? How offline — minutes or days? 2. Is app-store distribution a genuine requirement, or a habit? 3. What device capabilities does the core experience actually touch? 4. How many platforms must you support, and what is your maintenance budget? 5. Do shareable links and search visibility matter to acquisition? Answer those honestly and the choice usually makes itself. When two paths stay close, we prototype the riskiest interaction first and let it decide. The [project estimator](/en/estimator/) walks through these same trade-offs if you want a complexity read before committing. --- ## Odoo 17 to 18: what changed and what breaks Source: https://projomania.com/en/blog/odoo-17-to-18-migration/ Summary: The 17-to-18 jump is one of the smoother recent upgrades, but it is not free. Here are the changes that matter for custom modules, the accounting shifts to watch, and the pre-flight checks we run before touching production. Published: 2026-05-08 Author: Mohamed Magdy Moving from Odoo 17 to 18 is one of the gentler single-major upgrades of the last few years — but "gentler" is not "free." The work lives in your customizations and integrations, not the standard app. Here is what we check before we start. ## The headline changes - **OWL and the web client.** The front-end framework keeps maturing. If you have custom JavaScript widgets, QWeb-heavy views, or backend client actions, budget time to port and re-test them. Standard views usually carry over; custom ones rarely do without adjustment. - **Accounting and localizations.** Each release reshapes parts of the accounting engine and the country localization modules. If you depend on a specific localization or have customized journals, taxes, or reports, treat these as high-risk areas and test them first. - **View and ORM deprecations.** Attributes and helpers deprecated in 17 are removed or changed in 18. Code that threw warnings before will now break. Read the warnings you have been ignoring. ## Where custom modules actually break In practice, breakage clusters in a few places: 1. **JavaScript/OWL components** — the most common source of post-upgrade defects. 2. **Reports** — QWeb templates referencing changed fields or removed helpers. 3. **Integrations** — XML-RPC/JSON-RPC callers that assume a field or method that moved. 4. **Studio customizations** — these carry over differently between versions and often need a pass. ## The pre-flight checks we run - Inventory every custom module and note last-modified dates — dead code does not need migrating, it needs deleting. - Run the upgrade on a replica first. Never on production. Ever. - Diff the standard models you have extended against 18 to find renamed or removed fields. - Re-run every integration against the test database before cutover. - UAT the accounting close end-to-end with your finance lead signing off. ## How big is the jump for you? A clean, lightly customized 17 database can be a short engagement. A heavily customized one with bespoke OWL components and a tricky localization is a different conversation. The [version compatibility matrix](/en/version-compatibility/) shows the complexity read for your exact source and target, and our [Odoo upgrade service](/en/services/odoo/migration/upgrade/) covers the code, not just the data. If you are more than one major behind 18, read our [complete guide to Odoo migration](/en/blog/odoo-migration-guide-2026/) first — multi-hop paths have their own rules. --- ## The complete guide to Odoo database migration (2026 edition) Source: https://projomania.com/en/blog/odoo-migration-guide-2026/ Summary: What an Odoo migration actually takes — the five migration shapes, how to pick a target version, the risks that blow up projects, and the checklist we use on every engagement. Published: 2026-04-10 Author: Mohamed Magdy An Odoo migration is rarely "just the database." It is the records themselves, the code you have added, the Studio customizations your team depends on, the integrations that connect to the rest of your business. This guide covers what a real migration takes — in the shapes we run most often — and the checklist we apply before we touch production. ## The five shapes of Odoo migration Most conversations about migration assume **upgrade** — moving forward to a newer version. But there are five distinct shapes, and picking the right one changes the whole engagement. 1. **Upgrade** — move a production database (and its code) to a newer major version. The default case. 2. **Downgrade** — move back to an older version. Rare but not impossible; specific patterns apply. 3. **Database split** — turn one multi-company database into several, or extract one company. 4. **Database merge** — consolidate two or more databases, usually after an acquisition. 5. **Currency migration** — change the functional currency of a company, which Odoo does not support natively and which requires a new company with migrated monetary fields. We have written separate deep-dives on each — see the related services under [Odoo migration](/en/services/odoo/migration/). ## Picking a target version Three heuristics cover most cases: - **Jump to the latest LTS when you are more than two majors behind.** The support envelope is the main driver. - **Jump to the version your biggest third-party dependency supports.** If a key module has not shipped support for the newest Odoo, that becomes the ceiling. - **For heavily customized databases, do not skip more than two majors in one step.** Plan intermediate hops — each transformation is bounded and testable. ## The risks that blow up migrations Every migration-gone-wrong we have seen on a rescue engagement came from one of these: 1. **No test migration.** The team jumped straight to production. Always test first. 2. **Custom modules not audited.** Nobody read the `odoo.py` / `__manifest__.py` before kicking off. Surprises at UAT. 3. **Silent assumptions about Studio.** Studio configurations carry over differently between versions and frequently need adjustment on the new version. 4. **No data-loss report on downgrades.** Newer fields have no home on the older version; the team found out during UAT. 5. **No rehearsed rollback.** Cutover went sideways and there was no tested way back. ## The checklist we run on every engagement - Source inventory: record counts per model, list of all custom modules with last-modified date, Studio customizations catalogued, integrations mapped. - Target environment provisioned. - First test migration run end-to-end on a replica. - Issues triaged and fixed; re-run until clean. - UAT per functional area with your leads signing off. - Cutover plan documented: timing, checklist, validation, go/no-go criteria, rollback path. - Hypercare window on the calendar. ## What good looks like after go-live - No unplanned rollback. - No invoice, shipment, or payroll missed in the cutover window. - No data reconciliation issues in week 1. - Your team confident enough to use the new version from day one. We have built a [migration readiness checklist](/en/resources/) you can download — it is the same one we walk through at the start of every engagement. --- ## How to split a multi-company Odoo database Source: https://projomania.com/en/blog/split-multi-company-odoo-database/ Summary: Divestitures, carve-outs, and over-grown multi-company setups all eventually need one company pulled cleanly out of a shared database. Here is how the split actually works — and the shared records that trip teams up. Published: 2026-05-21 Author: Mohamed Magdy Splitting a multi-company Odoo database is one of the migration shapes most partners will not touch. It is fiddly, the edge cases are unforgiving, and a sloppy job leaves you with broken accounting on both sides. Done properly, it is methodical and safe. Here is the shape of the work. ## Why businesses need a split - **Divestiture** — you are selling a company and the buyer needs its data, cleanly separated from yours. - **Carve-out** — a division is becoming its own legal entity with its own systems. - **Untangling** — a multi-company setup grew organically and now one company needs to stand alone for performance, governance, or audit reasons. ## What makes it hard: shared records In a multi-company database, plenty of records are shared across companies, and the database does not always make the boundaries obvious. The split has to make a clean decision about each: 1. **Partners (customers/vendors)** — often shared. Which move, which are copied, which stay? 2. **Products and pricelists** — frequently global. The extracted company needs its own copy. 3. **Chart of accounts and journals** — company-specific, but inter-company entries link them. 4. **Users and access rights** — who follows the company, who keeps access to what remains. 5. **Inter-company transactions** — the hardest part. Open balances between the two companies have to be settled or represented correctly on both sides after the split. ## How we run it - **Inventory and decision matrix.** Every shared model gets an explicit rule: move, copy, or leave. No record is split on a guess. - **Extract to a fresh database.** The departing company is rebuilt in its own clean database with only its data and a copy of what it shares. - **Reconcile both sides.** Accounting on the remaining database and the new one must both balance. Inter-company open items get settled or carried as opening balances. - **Validate before anyone goes live.** Trial balances, AR/AP aging, and stock valuation are checked on both databases against the pre-split state. ## The non-negotiables - A documented decision for every shared model — never improvise. - A full rehearsal on replicas of both outcomes before the real cutover. - A data-loss and reconciliation report signed off by finance on both sides. - A tested rollback path. This is precision work. Our [database split service](/en/services/odoo/migration/database-split/) covers the full path, and the inverse — consolidating after an acquisition — is its sibling, the [database merge](/en/services/odoo/migration/database-merge/). If you are weighing a split, the [project estimator](/en/estimator/) captures the variables that drive complexity. --- ## Upgrade or migrate? A decision framework for moving Odoo versions Source: https://projomania.com/en/blog/upgrade-vs-migrate-decision-framework/ Summary: "Upgrade" and "migrate" are not the same project. One carries everything forward; the other is a fresh build that brings your data along. Here is how we decide which one a business actually needs. Published: 2026-04-25 Author: Mohamed Magdy Teams use "upgrade" and "migrate" interchangeably, but they describe two very different engagements. Choosing the wrong one is how a six-week project turns into a six-month one — or how a clean opportunity to shed years of accumulated mess gets thrown away. ## The two paths, defined - **Upgrade** — carry the existing database and its customizations forward to a newer major version. Same data, same modules, same configuration, adjusted to run on the new release. The goal is continuity. - **Migrate (re-implement)** — stand up a fresh database on the target version, rebuild the configuration deliberately, and bring across only the data that still earns its place. The goal is a clean start with history preserved where it matters. Both end with you on a newer version. What differs is how much of your past comes with you. ## When an upgrade is the right call - Your configuration is sound and your team is happy with how Odoo is set up today. - Customizations are documented, maintained, and still needed. - You are one to three majors behind and the data is healthy. - You need to minimize change-management — the business cannot absorb a re-training cycle right now. In this case, an in-place [Odoo upgrade](/en/services/odoo/migration/upgrade/) is faster, cheaper, and lower-risk than rebuilding. ## When a re-implementation wins - The current setup is the problem: workarounds on workarounds, abandoned modules, fields nobody can explain. - You have dozens of custom modules and only a handful are still used. - You are five or more majors behind — the cumulative breaking changes make a straight upgrade nearly as much work as a rebuild. - The business has changed shape (new entities, new processes) and the old model no longer fits. Here, dragging the mess forward costs you twice. A re-implementation lets you keep the data and drop the debt. ## The questions we ask first 1. How many custom modules exist, and how many are actually used this quarter? 2. When did anyone last read the manifest files? 3. How many majors behind are you, and is anything in the path a known breaking jump? 4. Can the business absorb re-training now, or is continuity the priority? 5. What history is legally or operationally required — and what can be archived instead of migrated? The answers usually point clearly one way. When they don't, we run a short discovery and a test migration to settle it with evidence rather than opinion. ## A middle path Sometimes the answer is "upgrade now, clean up later" — get onto a supported version quickly, then retire dead customizations in a follow-up. The [version compatibility matrix](/en/version-compatibility/) helps you see how far the jump really is before you commit. Not sure which path fits? The [project estimator](/en/estimator/) walks you through the same questions we do and gives you a complexity read in a few minutes. --- ## Why downgrading Odoo isn't a bad idea (and when it's the right call) Source: https://projomania.com/en/blog/when-to-downgrade/ Summary: Downgrades have a reputation they don't deserve. When a downgrade is the right move, the alternatives are worse. Here's how we think about the decision. Published: 2026-03-22 Author: Mohamed Magdy Every few weeks a client calls and asks for an Odoo downgrade. Another firm has told them it is impossible. We take it on, ship it, and nobody mentions it again. This post is the public version of the conversation we have at kickoff. ## When a downgrade is right Four patterns cover 90% of legitimate downgrade cases: - **Release regression** — a major version introduced behavior that your business cannot absorb. Patching forward is possible, but slower and more expensive than moving back. - **Third-party lag** — a module or integration you depend on has not shipped support for the version you migrated to. Vendor timeline isn't on your side. - **Licensing reset** — moving from Enterprise back to Community to rebuild on your own terms. - **Fleet standardization** — M&A dropped multiple Odoo versions into the same group and the common denominator is older than the newest. ## What makes downgrades genuinely harder On an upgrade, you can add new fields with defaults. On a downgrade, newer fields may have no home on the target schema. The first and most important deliverable is the **data-loss report** — a full mapping of what carries over, what gets archived, and what is dropped, with functional leads signing off per area before the migration runs. ## What we tell clients up front If a downgrade is the wrong answer, we say so. Sometimes the cleaner path is to patch forward. Sometimes it is to keep the newer version and replace a dependency. Sometimes it is to stand up two environments and split users. We are not selling you a downgrade. We are selling you the engagement that ships the right outcome. ## If a downgrade is the right call Expect roughly the timeline of an upgrade plus a premium for the data-loss analysis. Expect a test migration. Expect UAT. Expect a rehearsed rollback. Everything a good migration does, with one more early-phase deliverable. ## The one thing you do not get Silent data loss. If a field gets archived rather than carried over, it is on the data-loss report, the mapping document, and the final audit. Nothing disappears without you knowing. --- # Case studies ## Field-service SaaS Source: https://projomania.com/en/case-studies/field-service-mobile/ Published: 2026-01-22 ## Context A field-service SaaS running on Odoo had a strong back-office product but their technicians in the field were still on paper-and-photos. Adoption of Odoo's out-of-the-box mobile surface had stalled; they needed a purpose-built app that understood their workflow. ## Challenge Build a cross-platform mobile app that worked offline, handled large photo uploads, captured signatures, and stayed reliable on marginal connectivity. Integrate against the Odoo backend without requiring a parallel API team. ## Approach 1. **Backend layer** — we extended Odoo with a custom JSON-RPC facade tuned for mobile, with predictable payload shapes and offline-friendly state transitions. 2. **Mobile app** — React Native + Expo, with a local SQLite store for offline-first operations and a sync engine that handled conflicts deterministically. 3. **Photo and signature handling** — compressed client-side, uploaded with resumable retries on reconnect. 4. **Store submission** — screenshots, listings, reviewer back-and-forth, published under the client's developer accounts. 5. **Post-launch** — two sprints of iteration based on real technician feedback. ## Outcomes - Shipped to both stores in 14 weeks from kickoff. - 400+ monthly active technicians within the first quarter. - Photo upload success rate above 99% even on marginal networks. - Support tickets from field techs dropped by over half. ## What made this work - Building the Odoo-side facade once, properly, rather than fighting the default REST surface. - Offline-first architecture from day one, not retrofitted. - One team responsible for both sides. No finger-pointing between a mobile team and a backend team. --- ## Regional manufacturing group Source: https://projomania.com/en/case-studies/manufacturing-downgrade/ Published: 2026-03-15 ## Context A mid-market manufacturing group on Odoo v15 upgraded to v17 as part of their annual cycle. Shortly after go-live a regression in a customized MRP workflow started producing incorrect picking lists for a subset of products. The workflow had been customized by a previous integrator; the original author was unavailable. Forward-patching required reverse-engineering the customization on v17 and was estimated at 8+ weeks. The business could not absorb the impact on picking accuracy for that long. ## Challenge Return to v15 with the data and customizations intact, and without compromising audit continuity. Two partners the client approached refused the engagement on the grounds that "Odoo doesn't downgrade." A third proposed a manual data re-entry which was not viable at the record count. ## Approach 1. **Source audit.** Identified every v17-only field, table, and relation. Produced a data-loss report mapping each to either a v15 target, an archive, or a discard (with client sign-off per area). 2. **Test migration** on an isolated replica. Migrated records, customizations reworked to v15 APIs, QWeb reports forward-ported. 3. **UAT** with functional leads from manufacturing, inventory, purchasing, and finance. Three iteration rounds. 4. **Production cutover** in a weekend window with a rehearsed rollback. 5. **Hypercare** for two weeks. Zero critical issues, three minor items fixed within SLA. ## Outcomes - The business was back on a stable v15 with the correct workflow. - Data loss was zero (everything that could not carry over was archived with access preserved). - The rollback was rehearsed but never needed. - The client retained us on a support plan to cover the next planned upgrade window. ## What made this work - Being honest about the data-loss surface up front. UAT surprises are project killers. - Treating the customization as a first-class deliverable. The migration was half-done without it. - Rehearsing rollback. The value was not in using it but in having the option. --- ## Retail chain, MENA Source: https://projomania.com/en/case-studies/retail-currency-migration/ Published: 2026-02-28 ## Context A retail group operating across eight subsidiaries had run on a local functional currency for a decade. Accelerating inflation made management reporting increasingly noisy; the group's board mandated a move to USD as the functional currency with full historical continuity for audit. ## Challenge Change the functional currency of every company while preserving historical records, open transactions, and reporting continuity. Odoo does not support in-place currency changes; the supported pattern is archive-and-rebuild per company, and the client had eight. ## Approach 1. **Legacy archive.** Each of the eight existing companies was archived. Full historical access preserved; no new transactions allowed. 2. **FX rate table** published and signed off by finance before any monetary field was touched. Period-specific rates for historical P&L reconciliation; point-in-time rate for opening balance sheet. 3. **New companies** created in USD with matching structure, policies, and reference data. 4. **Master data migration** — customers, vendors, products, accounts, fiscal positions, pricelists — all denominated correctly in the target. 5. **Monetary field conversion** with documented rounding and precision rules. Each conversion logged. 6. **Audit report** — line-by-line, 340k+ items, signed off before cutover. 7. **Cutover** over a long weekend. Eight companies switched. Reconciliation passed at 0.00 variance. ## Outcomes - Management reporting immediately usable in USD. - Audit trail intact from the legacy companies. - Eight companies now in a single multi-company database (a consolidation we included in the engagement). - The group's auditor accepted the migration on first review. ## What made this work - FX rate table published and signed off before any conversion ran. - Running the migration per company rather than for the whole group at once — smaller blast radius per pass. - The audit report as a first-class deliverable from day one, not a last-week scramble. ---