Forty operators closing the shift simultaneously. The finance module generating the SAF-T. A 100 Mbps fibre connection that, on paper, looked more than sufficient. Within eleven minutes, the shop-floor terminals froze and the factory stopped. The fault did not lie with the MULTI ERP. It lay with the network — and nobody had sized it for this moment.
This scenario repeats itself systematically in Portuguese factories that migrate to cloud ERP without reviewing their network infrastructure. What follows is not a generic networking manual. It is what we see on the ground — what fails, why it fails, and what to do before production stops.
The thesis nobody wants to hear: the network is the ERP
When a cloud ERP fails in a factory, the first call goes to the software vendor. The second goes to the ISP. The third — rarely needed, because the problem has already been "solved" with a reboot — should go to the network architect. But that role does not exist in most Portuguese industrial SMEs.
A cloud ERP is not a web application. It is a set of distributed services that depend on controlled latency, guaranteed bandwidth and traffic segmentation. Treating the internet connection as the sole sizing vector is the most expensive error — and the most common.
The network does not support the ERP. The network is the ERP. When the network fails, the ERP fails. When the network is slow, the ERP is slow. No software can compensate for poor infrastructure.
What made this urgent now: the transition from on-premise ERP to cloud — accelerated by the regulatory pressure of SAF-T in industrial production, by the need for post-pandemic remote access and by PT2030 incentives — has left factories with 2000s network infrastructure depending on services that require 2020s networks. The mismatch is structural. And the threat landscape has worsened it: in 2024, CERT.PT recorded 2,758 cybersecurity incidents in Portugal, a 36% increase on 2023, with roughly 78% occurring in private entities (CNCS, 2024). Factories are no exception — they are a preferred target precisely because their security infrastructure is more fragile than in regulated sectors.
What changed: from local LAN to WAN dependency
On-premise ERP vs. cloud ERP: what the network now has to do
In an on-premise ERP, critical traffic travels across the local LAN. Latency is 1–2 ms. The server is in the same building — or in the same corridor. In a cloud ERP, that traffic crosses the WAN, the ISP, the cloud provider's backbone and back again. Even with a data centre in Lisbon or Porto, realistic latency is 15–40 ms under normal conditions. Under load, it can triple.
For query operations — a salesperson checking stock, a manager opening a Qlik Sense dashboard — 40 ms is imperceptible. For real-time transactional operations — a KORA Productivity terminal recording production entries every 30 seconds, with 60 terminals simultaneously — 40 ms accumulates and becomes visible. With jitter (latency variation), it becomes unbearable.
The peak nobody calculates
The most frequent sizing error we see: calculating bandwidth for the average user, not for the simultaneous peak. In a textile factory with 80 operators, the 17:00 shift close generates a peak of 60–70 simultaneous transactions in under 5 minutes. If the sizing was done for 20 concurrent users, the network collapses precisely when operational pressure is at its maximum.
There is a detail the manuals do not mention: the worst moment is not the isolated shift close. It is the shift close that coincides with the monthly SAF-T and with a backup left pending from the previous night. The three processes compete for the same connection without any prioritisation. It is at this intersection — not on a normal day — that the network gives way. And it is precisely this intersection that average sizing ignores.
There is no single traffic profile, but there are recognisable patterns. Real-time MES entries generate many small, high-frequency transactions, sensitive to latency and jitter. Warehouse management with the KORA Inventory Suite produces bursty traffic, dependent on industrial Wi-Fi with guaranteed coverage. Finance and reporting create heavy but occasional operations — the monthly SAF-T, month-end close, BI reports are predictable but intense peaks. Videoconferencing and remote access contend with ERP traffic if no QoS is configured. Backups and replication, without prioritisation, consume bandwidth at critical moments.
Real technical options: WAN connection
Dedicated fibre, shared fibre and SD-WAN
| Technology | Typical bandwidth (PT) | Typical latency | SLA available | Relative cost | Suitable for |
|---|---|---|---|---|---|
| Shared fibre (FTTH/FTTB) | 100 Mbps – 1 Gbps | 10–30 ms | No (best-effort) | Low | Factories <20 users, non-critical ERP |
| Dedicated fibre (Leased Line / MPLS) | 10 Mbps – 1 Gbps symmetrical guaranteed | 5–15 ms | Yes (99.9%+) | High | Factories with critical ERP, continuous production |
| SD-WAN with 2 connections (fibre + 4G/5G) | Dynamic aggregation | Variable, policy-managed | Partial (depends on ISP) | Medium | Factories with multiple connections, automatic failover |
| Private / campus 5G | Up to several Gbps | <10 ms | Yes (own network) | Very high | Large factories, intensive automation, dense IoT |
For most Portuguese factories with 50–200 employees, the practical combination is dedicated fibre as the primary connection and 4G/5G as failover, managed by an SD-WAN device. Shared fibre as the sole connection is an operational risk — not a saving.
The SD-WAN argument that vendors do not explain
SD-WAN does not increase the available bandwidth. It aggregates and manages multiple connections with routing intelligence. If the two underlying connections are of poor quality, SD-WAN distributes the traffic between two poor connections. The quality of the physical connection is irreplaceable.
SD-WAN is a multiplier. If the base is weak, it multiplies weakness. Configure the physical connections first; then put intelligence on top.
Internal architecture: LAN, segmentation and industrial Wi-Fi
Network segmentation by function
In a factory with cloud ERP, the internal network needs to separate at least four traffic domains. The production/OT network — shop-floor terminals, PLCs, sensors, MES systems — must be isolated from the corporate network by firewall or VLAN with strict ACLs. The corporate network covers office PCs, ERP, email and videoconferencing, with filtered internet access. The warehouse network serves barcode scanners, picking terminals and label printers, dependent on industrial Wi-Fi with guaranteed coverage. The management network — switches, APs, firewalls, monitoring servers — has access restricted to administrators.
This segmentation is not merely good security practice. It is a requirement of the NIS2 Directive (Directive (EU) 2022/2555, transposed in Portugal by Decree-Law No. 65/2025) for companies in critical sectors, including industry. The separation between OT and IT networks is explicitly referenced in the NIS2 technical controls. The article NIS2 in depth: technical controls for the Portuguese factory details the regulatory framework.
QoS: prioritising what matters
Quality of Service is the mechanism that ensures ERP traffic does not compete on equal terms with the video streaming of an employee on a break. Configure priority queues on the egress router and on the core switches. Maximum priority for ERP traffic (identified by the destination IP of the cloud server or by port/protocol), VoIP and production terminals. Medium priority for email, remote access and managed videoconferencing. Low priority for backups, software updates and unclassified traffic.
Without QoS, a nightly backup that starts at 22:00 and is still running at 08:00 the next morning can consume 40–60% of the available bandwidth during the start of the shift. This is the type of problem that IT only discovers when the production manager calls to complain — and that never appears in incident reports because "the system sorted itself out" after half an hour.
Industrial Wi-Fi: the detail projects ignore
Office Wi-Fi and industrial Wi-Fi are different products. In a 5,000 m² warehouse with metal racks, forklifts in motion and 30 picking terminals, a domestic or office access point is inadequate. The minimum requirements for industrial Wi-Fi in a warehouse or shop-floor environment: access points certified for industrial environments (IP54 or higher in damp or dusty areas); fast roaming between APs with handoff below 50 ms, critical for terminals in motion; dual-band with traffic separation; a centralised controller for channel and power management; and a coverage survey before installation — not after.
A footwear factory in Felgueiras with 800–1,200 SKUs and three axes of variation (colour, size, model) managing stock in real time needs Wi-Fi with no dead zones. A dead zone in a picking aisle is not an inconvenience — it is a process stoppage.
Sizing: the formula that works in practice
Calculating the required bandwidth
There is no universal formula, but there is a structured method. Identify the real concurrent users at peak — not the total number of employees, but how many access the ERP simultaneously at the moment of greatest load. Estimate consumption by type of operation: ERP transactions (low volume, high frequency) versus BI reports (high volume, low frequency) versus file uploads (high volume, occasional). Add background traffic — backups, updates, monitoring, videoconferencing. Apply an overhead factor of 2x–3x over the calculated figure: the network should not habitually operate above 50% of maximum capacity. Peaks of 80% are acceptable; peaks of 100% cause packet loss. Define the latency requirement: for cloud ERP with real-time production terminals, the target is below 50 ms end-to-end and below 20 ms of jitter. Measure — do not assume.
Decision matrix by factory size
| Factory size | Concurrent ERP users (peak) | Recommended WAN connection | Failover | Industrial Wi-Fi | QoS mandatory |
|---|---|---|---|---|---|
| Micro (<20 employees) | 5–10 | Shared fibre 100 Mbps | 4G router | Prosumer APs with centralised management | Recommended |
| Small (20–80 employees) | 10–30 | Dedicated fibre 50–100 Mbps or SD-WAN | Automatic 4G/5G | Industrial APs, survey mandatory | Mandatory |
| Medium (80–250 employees) | 30–80 | Dedicated fibre 100–500 Mbps + SD-WAN | Dedicated secondary connection | Industrial APs with controller, fast roaming | Mandatory + active monitoring |
| Large (>250 employees) | 80+ | Dedicated fibre 1 Gbps+ or MPLS | Geographically redundant connection | Industrial Wi-Fi with dedicated controller, possibly private 5G | Mandatory + NOC or MSP |
Network security: what NIS2 requires and what factories ignore
The attack surface grew with cloud ERP
When the ERP was on-premise, the main attack vector was the internal network. With cloud ERP, you add: the WAN connection, the credentials for accessing the cloud portal, the integration APIs with partners, and the mobile terminals. Each of these vectors is a door. And industrial SMEs are the disproportionate target: according to the Verizon Data Breach Investigations Report 2025, ransomware was present in 88% of data breaches at small and medium-sized enterprises, against 39% at large organisations.
The reason is simple: SMEs have the same digital exposure as large companies — cloud ERP, remote access, integrations with customers and suppliers — but a fraction of the security resources. The garment factory in the Vale do Ave is no less attractive than a bank. It is easier to compromise.
Minimum network controls for cloud ERP in an industrial environment
Next-generation firewall (NGFW) with application traffic inspection — not just port/IP filtering. VPN with multi-factor authentication (MFA) for all remote access to the ERP, including the IT staff member accessing from home at the weekend. OT/IT segmentation with a firewall between the two domains — not just a VLAN without ACLs. DNS filtering to block malicious domains before a connection is established. Traffic monitoring with anomaly alerts: a production terminal that starts making DNS requests to external domains is a sign of compromise, not a network problem.
For the zero trust approach in industrial networks, the article Industrial cybersecurity: zero trust in OT networks of Portuguese factories details the practical implementation. For vulnerability management in an OT environment, see NIS2 in depth: patch and vulnerability management in an OT environment.
The specific risk of remote access to the ERP
Remote access to the ERP — the finance director closing the month from home, IT providing support on a Saturday — is the most frequent compromise vector in industrial SMEs. The combination of weak credentials, absence of MFA and direct access to the ERP via RDP or VPN without segmentation creates an exposure that any attacker with access to the dark web can exploit for under 50 euros.
Configure remote access with VPN with mandatory MFA, sessions with automatic timeout, audit logging of all accesses, and the principle of least privilege. The user accessing remotely does not need access to every ERP module — and if their credentials are compromised, nor should the attacker.
What works in practice: three observed patterns
Pattern 1 — Separate networks before migrating
A textile factory in the Guimarães cluster, with around 120 employees and production of knitwear for European brands, invested 8–10 weeks in segmenting the internal network before touching the ERP. It separated the production network — recording terminals, machines with PLCs — from the corporate network. It installed a firewall between the two segments. Only then did it migrate. Production traffic never competed with finance traffic. Terminal response time remained stable even during the monthly close with SAF-T.
The error this sequence avoids is the most common: migrating the ERP first, discovering the network problems in production, and trying to resolve segmentation with the factory running — which forces maintenance windows negotiated with the production manager, who does not want to hear about IT at 6 a.m.
Pattern 2 — Poorly planned Wi-Fi in a distribution warehouse
A food distribution operator with a 15,000 m² warehouse in the Lousada–Paços de Ferreira corridor installed Wi-Fi based on a quote for a number of APs, without a coverage survey. The result was predictable: dead zones in the furthest picking aisles, terminals losing connection during roaming between APs, and the warehouse manager complaining that "the system keeps crashing". The system was not crashing. The network was.
Good practice is a coverage survey with a heat-mapping tool before installation, sizing by user density (not by area), and roaming testing with terminals in motion before go-live. A picking terminal that loses connection in the middle of an operation does not just generate frustration — it generates stock errors that cost more than the survey that was never done.
Pattern 3 — SD-WAN with automatic failover in a footwear factory
A footwear factory in Felgueiras, producing for international buyers who visit twice a year, implemented SD-WAN with dedicated fibre as primary and 5G as secondary. The failover policy is automatic — if the fibre goes down, ERP traffic migrates to 5G in under 30 seconds, with no human intervention.
The backup connection is not a security cost. It is production insurance. Calculate the cost of a 4-hour stoppage at the worst possible moment — then compare it with the monthly cost of a business SIM card with unlimited data.
The ROI of this redundancy is easily calculated: a 2-hour stoppage during the closing of an export order has an operational and reputational cost that exceeds the annual cost of the secondary connection. The international buyer does not wait for the fibre.
How to measure success after implementation
Network metrics IT should monitor continuously
End-to-end latency to the cloud ERP server: target below 50 ms at P95 — not on the average, at the 95th percentile, because it is the peak that destroys the experience. Jitter below 20 ms: high jitter is more destructive than high latency for frequent transactions. Packet loss: target zero under normal conditions; any loss above 0.1% on ERP traffic is a sign of a problem, not of normal variation. Bandwidth utilisation: alert when it exceeds 70% for more than 5 consecutive minutes. Primary connection availability: target 99.9% monthly, equivalent to less than 44 minutes of downtime per month. Failover time: test monthly — how long the secondary connection takes to assume the traffic and whether the ERP recovers the sessions or requires a new login.
The test nobody does but should
Simulate a failure of the primary connection during a low-load period — a Thursday afternoon, not a Monday morning. Check whether failover works, how long it takes, whether users notice, and whether the ERP recovers the sessions or requires a new login. Document the result. Repeat quarterly. For a structured resilience testing plan, the article Disaster recovery in the factory: what to test before you actually need it details the methodology.
Five steps to start this week
- Audit the current connection: measure latency, jitter and packet loss to the cloud ERP server during the load peak — shift close or month-end close. Use continuous ping, traceroute and iPerf. Compare against the targets above. If you do not have this data, you do not have a diagnosis.
- Map the traffic by type: identify all systems sharing the WAN connection — ERP, backups, videoconferencing, IP cameras, automatic updates. Quantify the consumption of each. The backup that nobody knew was configured to run in the morning is the most frequent suspect.
- Configure QoS on the egress router: prioritise ERP and production traffic. Limit backup traffic to 20% of bandwidth during production hours. This configuration alone resolves a significant fraction of performance problems without any hardware investment.
- Segment the internal network: separate at least the production/OT network from the corporate network. If you do not have a firewall between the two segments, this is the most urgent investment — before any bandwidth upgrade and before any discussion about NIS2.
- Install continuous monitoring: an alert system that notifies IT when latency exceeds 80 ms or bandwidth utilisation exceeds 70% for more than 5 minutes. Do not discover problems through your users — discover them first. The warehouse manager should not be the network monitoring system.
Network infrastructure for cloud ERP is not an IT project. It is a condition of operation. A factory that migrates its ERP to the cloud without reviewing the network is swapping a known risk — an on-premise server that fails inside the building — for an unknown one: dependency on an undersized WAN that fails at the worst moment and that nobody knows how to diagnose. The second is harder to explain to the CEO, harder to resolve in production, and more costly when the NIS2 auditor knocks on the door.
Sources
- CNCS — National Cybersecurity Centre, Cybersecurity in Portugal Report — Risks and Conflicts 2024, CERT.PT, 2024. Available at: cncs.gov.pt
- Verizon, Data Breach Investigations Report 2025, Verizon Communications, 2025. Available at: verizon.com/business/resources/reports/dbir
- Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2), Official Journal of the European Union, 27 December 2022.
- Decree-Law No. 65/2025, Diário da República, transposition of the NIS2 Directive into the Portuguese legal order.
- IBM Security, Cost of a Data Breach Report 2024, IBM Corporation, 2024. Available at: ibm.com/reports/data-breach
- ENISA — European Union Agency for Cybersecurity, Good Practices for Security of IoT and Smart Infrastructures, ENISA, 2023. Available at: enisa.europa.eu
Frequently asked questions
What is the difference between an on-premise ERP and a cloud ERP in network terms?
In an on-premise ERP, critical traffic travels across the local LAN with a latency of 1–2 ms. In a cloud ERP, that traffic crosses the WAN, the ISP and the provider's backbone, with realistic latency of 15–40 ms under normal conditions. Under load, it can triple. For real-time transactional operations with multiple terminals, this difference becomes critical.
What is the "peak nobody calculates" in network sizing?
It is the error of calculating bandwidth for the average user, not for the simultaneous peak. In a factory, the shift close generates 60–70 simultaneous transactions in under 5 minutes. The worst scenario occurs when the shift close coincides with the monthly SAF-T and a pending backup — three processes competing for the same connection without prioritisation. It is at this intersection that the network gives way.
What is the best WAN connection option for a factory with cloud ERP?
For most Portuguese factories with 50–200 employees, the practical combination is dedicated fibre as the primary connection and 4G/5G as failover, managed by an SD-WAN device. Shared fibre as the sole connection is an operational risk. Dedicated fibre offers guaranteed bandwidth, controlled latency and an SLA of 99.9%+.
What is SD-WAN and how does it work with cloud ERP?
SD-WAN aggregates and manages multiple connections with routing intelligence; it does not increase the available bandwidth. If the underlying connections are of poor quality, SD-WAN distributes traffic between two poor connections. It is a multiplier: if the base is weak, it multiplies weakness. Configure the physical connections first; then put intelligence on top.
Why is shared fibre (FTTH) inadequate for critical ERP?
Shared fibre offers 100 Mbps–1 Gbps without a guaranteed SLA (best-effort). It provides neither controlled latency nor traffic prioritisation. In a factory where the ERP is critical to production, the collapse of the network during a simultaneous peak paralyses operations. Dedicated fibre with an SLA is the safe choice.
What are the types of traffic that compete for the network in a factory with cloud ERP?
MES entries generate many small transactions sensitive to latency. Warehouse management produces bursty traffic. Finance creates heavy but occasional operations (SAF-T, month-end close). Videoconferencing and remote access contend with ERP traffic. Backups and replication consume bandwidth at critical moments. Without QoS configured, prioritisation is impossible.
What is the impact of jitter (latency variation) on a cloud ERP?
For queries (a salesperson checking stock), 40 ms of latency is imperceptible. For real-time transactional operations (a terminal recording entries every 30 seconds with 60 simultaneous terminals), 40 ms accumulates and becomes visible. With jitter, it becomes unbearable and causes the terminals to freeze.