{"id":3347,"date":"2026-07-20T09:00:00","date_gmt":"2026-07-20T07:00:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/scaling-odoo-19-200-utenti-pmi-italiane-guida\/"},"modified":"2026-06-10T07:55:40","modified_gmt":"2026-06-10T05:55:40","slug":"scaling-odoo-19-200-utenti-pmi-italiane-guida","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/scaling-odoo-19-200-utenti-pmi-italiane-guida\/","title":{"rendered":"Scaling Odoo a 200+ utenti: architettura distribuita, multi-server, cloud (guida PMI)"},"content":{"rendered":"<p><em>Quarantatreesima guida operativa Odoo 19 per PMI italiane. C&#8217;\u00e8 una differenza enorme tra &#8220;gestire Odoo per 30 utenti&#8221; e &#8220;gestire Odoo per 200+ utenti&#8221;. La crescita non \u00e8 lineare: ogni step (50, 100, 200, 500 utenti) richiede revisioni architetturali, processi rinforzati, governance pi\u00f9 strutturata. Le PMI italiane che gestiscono bene questa transizione costruiscono un asset che le accompagna fino a diventare aziende medio-grandi. Quelle che non la gestiscono incontrano colli di bottiglia critici. In questa guida vediamo come progettare lo scaling di Odoo.<\/em><\/p>\n<p>Vediamo: soglie critiche utenti, architettura multi-server, sharding e read replica, organizzazione team IT interno, governance evoluzioni, casi pratici PMI italiane in crescita.<\/p>\n<h2>Le soglie critiche di scaling<\/h2>\n<h3>Soglia 1: 30-50 utenti \u2014 Single-server tuned<\/h3>\n<ul>\n<li>Architettura: 1 server applicativo + 1 DB<\/li>\n<li>CPU: 4-8 core, RAM: 16-32GB<\/li>\n<li>Storage: 200-500GB NVMe SSD<\/li>\n<li>Workload: gestibile senza scaling speciale<\/li>\n<li>Investimento infra: 5-15k \u20ac\/anno<\/li>\n<\/ul>\n<h3>Soglia 2: 50-100 utenti \u2014 Tuning intensivo<\/h3>\n<ul>\n<li>Architettura: server pi\u00f9 grande + tuning PostgreSQL<\/li>\n<li>CPU: 8-16 core, RAM: 32-64GB<\/li>\n<li>Worker: 17-33 (formula 2\u00d7CPU+1)<\/li>\n<li>Read replica per reporting<\/li>\n<li>Investimento: 15-30k \u20ac\/anno<\/li>\n<\/ul>\n<h3>Soglia 3: 100-200 utenti \u2014 Multi-server<\/h3>\n<ul>\n<li>Load balancer + 2-3 app server<\/li>\n<li>DB primario + 1-2 read replica<\/li>\n<li>Session storage Redis condiviso<\/li>\n<li>Investimento: 30-60k \u20ac\/anno<\/li>\n<\/ul>\n<h3>Soglia 4: 200-500 utenti \u2014 Architettura distribuita<\/h3>\n<ul>\n<li>Load balancer ridondato + 5-10 app server<\/li>\n<li>DB con read replica geografica<\/li>\n<li>Caching layer (Redis cluster)<\/li>\n<li>CDN per asset statici<\/li>\n<li>Monitoring distribuito<\/li>\n<li>Investimento: 60-150k \u20ac\/anno<\/li>\n<\/ul>\n<h3>Soglia 5: 500+ utenti \u2014 Enterprise architecture<\/h3>\n<ul>\n<li>Multi-region setup<\/li>\n<li>Database sharding (partitioning)<\/li>\n<li>Microservizi per integrazione<\/li>\n<li>Team IT dedicato (5-15 persone)<\/li>\n<li>Investimento: 150k+ \u20ac\/anno infrastruttura<\/li>\n<\/ul>\n<h2>Architettura multi-server: i componenti<\/h2>\n<h3>Load balancer (entry point)<\/h3>\n<ul>\n<li>HAProxy, Nginx, AWS ALB, Azure App Gateway<\/li>\n<li>Health check su app server<\/li>\n<li>SSL termination + WAF (Web Application Firewall)<\/li>\n<li>Rate limiting per protezione DDoS<\/li>\n<li>Sticky sessions per gestione sessioni utente<\/li>\n<\/ul>\n<h3>App server tier (Odoo workers)<\/h3>\n<ul>\n<li>2-10 server identici (stateless)<\/li>\n<li>Configurazione condivisa via Git\/Ansible<\/li>\n<li>Auto-scaling se cloud-native<\/li>\n<li>Rolling deployment per zero-downtime<\/li>\n<li>Local cache per asset statici<\/li>\n<\/ul>\n<h3>Database tier<\/h3>\n<ul>\n<li>Master (writes) + 1-3 read replica<\/li>\n<li>Streaming replication PostgreSQL<\/li>\n<li>Connection pooling (PgBouncer)<\/li>\n<li>Backup automatici + DR setup<\/li>\n<li>Monitoring query performance<\/li>\n<\/ul>\n<h3>Cache tier<\/h3>\n<ul>\n<li>Redis cluster per session storage<\/li>\n<li>Memcached per object cache<\/li>\n<li>CDN per asset (immagini, JS, CSS)<\/li>\n<li>Browser cache aggressivo<\/li>\n<\/ul>\n<h3>Storage tier<\/h3>\n<ul>\n<li>Object storage (S3, MinIO) per filestore<\/li>\n<li>Block storage per DB (NVMe SSD)<\/li>\n<li>Backup storage separato (S3 Glacier, archive tier)<\/li>\n<li>CDN integration per static assets<\/li>\n<\/ul>\n<h2>Read replica: scaling delle letture<\/h2>\n<h3>Quando serve read replica<\/h3>\n<ul>\n<li>Report e analytics pesanti<\/li>\n<li>Workload mix: 70% read, 30% write tipico<\/li>\n<li>Integrazione BI esterna (export massivi)<\/li>\n<li>Audit log query frequenti<\/li>\n<\/ul>\n<h3>Configurazione Odoo per read replica<\/h3>\n<ul>\n<li>Modulo <code>db_routing<\/code> per routing query<\/li>\n<li>Read queries: replica<\/li>\n<li>Write queries: sempre primary<\/li>\n<li>Eventual consistency: gestione delay replication<\/li>\n<li>Failover automatico se replica down<\/li>\n<\/ul>\n<h3>Cross-region read replica<\/h3>\n<ul>\n<li>Per organizzazioni internazionali<\/li>\n<li>Latenza locale per utenti<\/li>\n<li>Read replica in ogni region<\/li>\n<li>Write sempre primary (con latenza accettabile)<\/li>\n<\/ul>\n<h2>Volumi tipici per scale<\/h2>\n<h3>Manifattura 200 utenti: cosa significa operativamente<\/h3>\n<p>Una PMI manifatturiera con 200 utenti gestisce simultaneamente decine di ordini di produzione, hundreds di task operativi, migliaia di transazioni magazzino:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-scaling-01-mrp-dashboard.png\" alt=\"Dashboard MRP Odoo 19 alto volume per scaling 200+ utenti PMI manifattura\" class=\"aligncenter size-full wp-image-3344\"\/><\/p>\n<ul>\n<li>50-150 ordini produzione attivi contemporaneamente<\/li>\n<li>500-2.000 work order quotidiani<\/li>\n<li>10.000-50.000 movimenti magazzino al mese<\/li>\n<li>200-500 fatture al giorno<\/li>\n<li>5.000-20.000 lead\/opportunit\u00e0 nel CRM<\/li>\n<\/ul>\n<h2>Ordini produzione su volumi alti<\/h2>\n<p>La lista degli ordini di produzione su scala richiede paginazione efficiente, filtri performanti, ricerche su volumi alti:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-scaling-02-mrp-orders.png\" alt=\"Lista ordini produzione Odoo 19 alto volume scaling PMI 200+ utenti\" class=\"aligncenter size-full wp-image-3345\"\/><\/p>\n<ul>\n<li>Indici dedicati su date, state, partner<\/li>\n<li>Filtri di default smart (max ultimi 90 giorni)<\/li>\n<li>Lazy loading per liste con &gt; 1000 record<\/li>\n<li>Search avanzata con full-text PostgreSQL<\/li>\n<li>Export batch per grandi dataset<\/li>\n<\/ul>\n<h2>Movimenti finanziari su volumi alti<\/h2>\n<p>Sul lato finanziario, l&#8217;alto volume di transazioni bancarie e movimenti contabili richiede architettura ottimizzata per riconciliazioni rapide e reporting in tempo reale:<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-scaling-03-bank-moves.png\" alt=\"Lista movimenti bancari Odoo 19 alto volume per scaling PMI 200+ utenti\" class=\"aligncenter size-full wp-image-3346\"\/><\/p>\n<ul>\n<li>Import batch movimenti banca (5.000+ al mese)<\/li>\n<li>Matching automatico con AI\/rules<\/li>\n<li>Riconciliazione massive in pochi minuti<\/li>\n<li>Audit log per traceability<\/li>\n<li>Reportistica real-time aggiornata<\/li>\n<\/ul>\n<h2>Team IT interno: dimensionamento per scale<\/h2>\n<h3>30-100 utenti: 0-1 dedicato<\/h3>\n<ul>\n<li>Partner esterno gestisce tutto<\/li>\n<li>1 referente IT interno part-time<\/li>\n<li>Costo team IT interno: 0-50k \u20ac\/anno<\/li>\n<\/ul>\n<h3>100-300 utenti: 2-4 persone<\/h3>\n<ul>\n<li>1 System Administrator<\/li>\n<li>1 Functional Consultant<\/li>\n<li>1 Sviluppatore custom (part-time o full-time)<\/li>\n<li>Partner esterno per progetti specifici<\/li>\n<li>Costo team IT: 150-280k \u20ac\/anno<\/li>\n<\/ul>\n<h3>300-1000 utenti: 5-10 persone<\/h3>\n<ul>\n<li>2 System Administrator (HA coverage)<\/li>\n<li>2 Functional Consultant (per area)<\/li>\n<li>2-3 Sviluppatori senior<\/li>\n<li>1 DevOps engineer<\/li>\n<li>1 IT Manager<\/li>\n<li>Partner esterno per specialty<\/li>\n<li>Costo team IT: 400-700k \u20ac\/anno<\/li>\n<\/ul>\n<h3>1000+ utenti: team strutturato 15+<\/h3>\n<ul>\n<li>CTO + IT Manager<\/li>\n<li>Team operazioni (3-5 persone)<\/li>\n<li>Team sviluppo (5-8 persone)<\/li>\n<li>Team data\/BI (2-3 persone)<\/li>\n<li>Team security (1-2 persone)<\/li>\n<li>Costo team IT: 1M+ \u20ac\/anno<\/li>\n<\/ul>\n<h2>Governance per scale<\/h2>\n<h3>Steering committee Odoo<\/h3>\n<ul>\n<li>Mensile per PMI 100+ utenti<\/li>\n<li>Partecipanti: CTO, CFO, business owner<\/li>\n<li>Owner: IT Manager Odoo<\/li>\n<li>Output: roadmap prioritizzata, budget allocato<\/li>\n<\/ul>\n<h3>Change Advisory Board (CAB)<\/h3>\n<ul>\n<li>Settimanale per PMI 200+ utenti<\/li>\n<li>Review change request prima di deploy<\/li>\n<li>Risk assessment per ogni change<\/li>\n<li>Documentation requirements<\/li>\n<li>Rollback plan obbligatorio<\/li>\n<\/ul>\n<h3>Service Level Agreement (SLA) interni<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-pool-046.png\" alt=\"scaling Odoo architettura distribuita multi-server\" class=\"aligncenter size-full wp-image-3456\"\/><\/p>\n<ul>\n<li>SLA per ogni tipo richiesta utente<\/li>\n<li>Helpdesk con ticket tracking<\/li>\n<li>Reportistica SLA performance mensile<\/li>\n<li>Escalation matrix definita<\/li>\n<\/ul>\n<h2>Migrazione cloud per scaling<\/h2>\n<h3>Vantaggi cloud per scale<\/h3>\n<ul>\n<li>Scaling on-demand (auto-scaling)<\/li>\n<li>Disaster recovery pi\u00f9 semplice<\/li>\n<li>Managed services riducono ops<\/li>\n<li>Global presence per multi-region<\/li>\n<li>Pay-per-use model<\/li>\n<\/ul>\n<h3>Provider tipici per Odoo<\/h3>\n<table border=\"1\" cellspacing=\"0\" cellpadding=\"6\">\n<thead>\n<tr>\n<th>Provider<\/th>\n<th>Pro<\/th>\n<th>Contro<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>AWS<\/td>\n<td>Servizi completi, RDS, EKS<\/td>\n<td>Complessit\u00e0, costo<\/td>\n<\/tr>\n<tr>\n<td>Azure<\/td>\n<td>Integrazione Microsoft stack<\/td>\n<td>Performance variabili<\/td>\n<\/tr>\n<tr>\n<td>GCP<\/td>\n<td>Cloud SQL PostgreSQL ottimo<\/td>\n<td>Meno servizi specializzati<\/td>\n<\/tr>\n<tr>\n<td>OVH\/Hetzner<\/td>\n<td>Costo basso, hosting europeo<\/td>\n<td>Meno managed services<\/td>\n<\/tr>\n<tr>\n<td>Odoo.sh<\/td>\n<td>Managed Odoo, semplice<\/td>\n<td>Limitazioni infrastruttura<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Migration plan tipico<\/h3>\n<ul>\n<li>Mese 1: assessment + decisione provider<\/li>\n<li>Mese 2-3: setup ambiente cloud + test<\/li>\n<li>Mese 4: migration data + dual-running<\/li>\n<li>Mese 5: cutover produzione<\/li>\n<li>Mese 6: optimization + monitoring<\/li>\n<li>Costo migration: 30-80k \u20ac per PMI 100+ utenti<\/li>\n<\/ul>\n<h2>Sharding e partitioning per very large scale<\/h2>\n<h3>Quando serve sharding<\/h3>\n<ul>\n<li>Tabelle &gt; 100M record<\/li>\n<li>Multi-tenant con isolamento dati<\/li>\n<li>Performance lineare con crescita<\/li>\n<li>Maintenance window ridotta<\/li>\n<\/ul>\n<h3>Table partitioning PostgreSQL<\/h3>\n<ul>\n<li>Range partitioning (per data)<\/li>\n<li>Hash partitioning (per ID)<\/li>\n<li>List partitioning (per categoria)<\/li>\n<li>Esempio: tabella account_move partizionata per anno<\/li>\n<li>Beneficio: query 10-50x pi\u00f9 veloci su anno corrente<\/li>\n<\/ul>\n<h3>Database sharding (rarely needed for Odoo)<\/h3>\n<ul>\n<li>Database separati per dimensione (es. per company, per region)<\/li>\n<li>Complessit\u00e0 altissima<\/li>\n<li>Tipicamente: 5000+ utenti o 10TB+ data<\/li>\n<li>PMI italiane: raramente necessario<\/li>\n<\/ul>\n<h2>Monitoring distribuito per scale<\/h2>\n<h3>Stack monitoring raccomandato<\/h3>\n<ul>\n<li><strong>Infrastructure metrics<\/strong>: Prometheus + Grafana<\/li>\n<li><strong>Application Performance<\/strong>: New Relic, Datadog APM<\/li>\n<li><strong>Log aggregation<\/strong>: ELK Stack o Loki<\/li>\n<li><strong>Error tracking<\/strong>: Sentry<\/li>\n<li><strong>Synthetic monitoring<\/strong>: Pingdom, UptimeRobot<\/li>\n<li><strong>Real User Monitoring (RUM)<\/strong>: Datadog, FullStory<\/li>\n<\/ul>\n<h3>Alert da configurare<\/h3>\n<ul>\n<li>Response time &gt; 2s sostenuto per 5 min<\/li>\n<li>Error rate &gt; 1% per 5 min<\/li>\n<li>CPU &gt; 80% per 10 min<\/li>\n<li>DB connection &gt; 90%<\/li>\n<li>Disk &gt; 85%<\/li>\n<li>SSL certificate scadenza &lt; 30 giorni<\/li>\n<\/ul>\n<h2>Errori comuni nello scaling<\/h2>\n<h3>&#8220;Scaling verticale all&#8217;infinito&#8221;<\/h3>\n<p><strong>Problema<\/strong>: PMI continua ad aumentare CPU\/RAM oltre il punto di efficienza.<br \/>\n<strong>Soluzione<\/strong>: oltre 16 CPU passare a multi-server, sotto pagare per resources poco usate.<\/p>\n<h3>&#8220;No load testing prima di scaling&#8221;<\/h3>\n<p><strong>Problema<\/strong>: nuova architettura messa in produzione senza test, fallisce al primo picco.<br \/>\n<strong>Soluzione<\/strong>: load test con volume 2-3x atteso prima di deploy.<\/p>\n<h3>&#8220;Team IT sotto-dimensionato&#8221;<\/h3>\n<p><strong>Problema<\/strong>: 200 utenti gestiti da 1 sysadmin part-time, errori e ritardi.<br \/>\n<strong>Soluzione<\/strong>: rapporto 1 IT dedicato per ogni 50-100 utenti operativi.<\/p>\n<h3>&#8220;Cloud cost out of control&#8221;<\/h3>\n<p><strong>Problema<\/strong>: scaling automatico genera fattura 5x preventivata.<br \/>\n<strong>Soluzione<\/strong>: alert budget, reserved instances per baseline, auto-scaling con cap.<\/p>\n<h3>&#8220;Customization non scalano&#8221;<\/h3>\n<p><strong>Problema<\/strong>: customization sviluppata per 50 utenti collassa con 200.<br \/>\n<strong>Soluzione<\/strong>: review customization durante ogni step di scaling, refactor where needed.<\/p>\n<h2>Casi pratici PMI italiane<\/h2>\n<h3>Caso 1 \u2014 Manifattura cresciuta da 80 a 280 utenti<\/h3>\n<ul>\n<li>Anno 1: tuning single-server + ottimizzazioni<\/li>\n<li>Anno 2: multi-server con load balancer<\/li>\n<li>Anno 3: migration ad AWS multi-AZ<\/li>\n<li>Investimento totale: 95k \u20ac infra + 180k \u20ac team IT<\/li>\n<li>Risultato: response time stabile a 1.2s media<\/li>\n<\/ul>\n<h3>Caso 2 \u2014 Distributore multi-store: scaling regionale<\/h3>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-pool-047.png\" alt=\"deployment cloud Odoo 200 utenti PMI\" class=\"aligncenter size-full wp-image-3457\"\/><\/p>\n<ul>\n<li>120 store, 350 utenti totali, 5 regioni<\/li>\n<li>Read replica per region (latenza locale)<\/li>\n<li>Sharding per region da considerare se cresce ulteriormente<\/li>\n<li>Investimento: 65k \u20ac\/anno infra<\/li>\n<li>Risultato: response time &lt; 800ms in ogni store<\/li>\n<\/ul>\n<h3>Caso 3 \u2014 E-commerce: peak handling Black Friday<\/h3>\n<ul>\n<li>40k utenti web + 220 operatori interni<\/li>\n<li>Auto-scaling cloud per peak (10x normale)<\/li>\n<li>CDN aggressivo per asset<\/li>\n<li>Cost: 12k \u20ac settimana Black Friday vs 3k \u20ac normale<\/li>\n<li>Risultato: 0 downtime durante peak<\/li>\n<\/ul>\n<h3>Caso 4 \u2014 Servizi B2B: scaling fallito<\/h3>\n<ul>\n<li>Crescita 60 \u2192 180 utenti in 18 mesi<\/li>\n<li>Nessun investimento infrastruttura<\/li>\n<li>Performance peggiorate: response time 8-15s<\/li>\n<li>Recovery emergency: 4 mesi + 85k \u20ac rebuild<\/li>\n<li>Lesson learned: pianificare scaling 12 mesi avanti<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>A che soglia conviene passare a multi-server?<\/h3>\n<p>Generalmente 80-100 utenti concorrenti su 4 CPU. Indicatori: CPU &gt; 70% media giornaliera, response time degradante, lamentele utenti. Multi-server non \u00e8 mai prematuro se preparato adeguatamente.<\/p>\n<h3>Posso restare on-premise per 500+ utenti?<\/h3>\n<p>S\u00ec tecnicamente, ma economicamente svantaggioso. Costo on-premise per 500+: 100-200k \u20ac\/anno + team dedicato + DR complessit\u00e0. Cloud equivalente: 50-100k \u20ac\/anno + team pi\u00f9 piccolo. ROI cloud favorevole oltre 200 utenti tipico.<\/p>\n<h3>Quanto costa la migrazione cloud completa?<\/h3>\n<p>Per PMI 100-300 utenti: 30-80k \u20ac one-time + costo run aumentato del 20-40% rispetto on-premise (compensato da riduzione costi operations). Tempo migration: 4-8 mesi tipico.<\/p>\n<h3>Devo riscrivere le customization per scaling?<\/h3>\n<p>Solo quelle che non scalano (volumi alti, integrazioni esterne). 60-70% delle customization Odoo standard scalano nativamente. Audit pre-scaling identifica le 10-30% da refactor. Costo refactor: 20-50% costo iniziale customization.<\/p>\n<h3>Quanto tempo serve per pianificare scaling 100\u2192200 utenti?<\/h3>\n<p>Pianificazione: 2-3 mesi. Esecuzione: 4-6 mesi. Stabilizzazione: 3 mesi. Totale: 9-12 mesi end-to-end. Iniziare quando si raggiunge 80% capacit\u00e0 attuale (segno crescita rapida).<\/p>\n<h2>Prossimi passi<\/h2>\n<p>Nelle prossime guide vedremo come <strong>migrare da on-premise a cloud<\/strong> in dettaglio, come <strong>gestire upgrade major con anni di customization<\/strong> accumulate, e come <strong>misurare ROI complessivo Odoo<\/strong> nel lungo termine (5+ anni).<\/p>\n<p style=\"margin-top:30px;background:#f4f4f8;padding:18px;border-radius:8px;\"><strong>Vuoi scalare Odoo nella tua PMI in crescita?<\/strong><br \/>\nG Tech Group affianca le PMI italiane nello scaling Odoo da 50 a 500+ utenti: assessment, architettura multi-server, migration cloud, team IT dimensionamento. Track record di scaling riusciti senza downtime.<br \/>\n<a href=\"https:\/\/brentasoft.com\/preventivatore.php\"><strong>Richiedi un preventivo gratuito<\/strong><\/a> oppure prova la nostra <a href=\"https:\/\/odoo.brentasoft.com\/\">demo Odoo 19 live<\/a>. Oppure <a href=\"https:\/\/www.odoo.com?utm_campaign=partner-d192ce8a&amp;utm_source=partner_ref\" target=\"_blank\" rel=\"noopener noreferrer\">prova Odoo direttamente su odoo.com<\/a> (link partner Brentasoft).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Quarantatreesima guida Odoo 19: scaling architettura per 200+ utenti. Soglie critiche, multi-server, read replica, team IT, governance, sharding, casi pratici PMI in crescita.<\/p>\n","protected":false},"author":2,"featured_media":3344,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Scaling Odoo 200+ utenti: guida PMI italiane","_seopress_titles_desc":"Come scalare Odoo a 200+ utenti: soglie critiche, multi-server, read replica, cloud migration, team IT, governance, casi pratici PMI italiane.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"https:\/\/brentasoft.com\/blog\/scaling-odoo-19-200-utenti-pmi-italiane-guida\/","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2026\/06\/odoo-scaling-01-mrp-dashboard.png","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[24,689],"tags":[],"class_list":["post-3347","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-erp-gestionali","category-guide-odoo"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/3347","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=3347"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/3347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/3344"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=3347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=3347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=3347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}