How Model Group gained control over the group's hybrid environment and stopped paying for tools it no longer needed.
Three sets of tools. Dozens of sites across Europe. Hundreds of servers. One IT team overseeing it all. And fragmented tooling with no unified management. We helped Model Group change that.
1 April 2026 · Project timeline: 2025 · Author: EnterCloud

Model Group is an international manufacturer of corrugated packaging with production plants in Switzerland, Germany, the Czech Republic, Poland and Croatia. The group employs more than 4,600 people across 15 plants throughout Europe.
The Czech subsidiary Model Obaly, a.s. operates five plants (in Opava, Nymburk, Hostinné, Moravské Budějovice and Pack Shop Praha) with approximately 1,340 employees. The company grows slowly and deliberately: the last plant was added in 2003. Family ownership, conservative management, a focus on stability and reliability. Three-shift industrial production where a system outage is not an IT problem — it is a production problem.
Infrastructure does not grow according to plan. It grows according to need. Every year a new server, a new application, a new site is added. And each one gets its own tool, its own process, its own team.
Model Group ended up exactly here: Windows servers managed one way, Linux servers another, Azure VMs a third. No common view. No unified security policy. And with a concrete threat on the horizon — the approaching end of extended support for critical systems that could not be migrated overnight.
The most painful question was not technical. It was operational: how many servers have up-to-date patches right now? Nobody could answer with certainty.

Roztříštěný tooling, tři sady nástrojů a žádný jednotný přehled. Tady jsou 3 kroky, kterými jsme to změnili:
Instead of migrating everything to the cloud (which is neither realistic nor always the right choice for a manufacturing company), a unified management layer was created over the entire environment.
Azure Arc connected on-premises servers, Azure VMs and physical machines into a single view in the Azure portal. Every server, regardless of where it physically sits, can from that point be managed with the same tools, the same policies and the same team.
The key is to understand what Arc does not do: it does not move workloads, does not interfere with running systems, does not require downtime. It adds a management layer. Everything else stays where it is.

What does this mean in practice?
A server in Opava and a VM in the Azure portal look and behave identically. Same tags, same policies, same reports. The IT team stops switching between contexts and starts actually managing.
Onboarding servers into Arc is done by installing a lightweight agent. For larger environments like Model Group with dozens of sites across Europe, the agent is deployed in bulk via Group Policy or scripts. The IT team does not visit each machine individually.
After onboarding, Azure Policies are applied automatically: Defender is deployed to all servers with a single policy, logs start flowing into a central Log Analytics workspace, and servers are assigned to patching waves based on their tags.
One thing that surprises people: onboarding reveals a state that was previously invisible. Linux servers with non-standard configurations, machines without up-to-date agents, systems with no coverage. Arc itself does not fix anything, but for the first time it shows what needs fixing.
That is exactly why we recommend planning for a clean-up phase after onboarding. It is not a complication. It is value.
Examples of queries the IT team could run for the first time after implementation:
“List servers by number of critical log errors in the past week.” / “Show servers trending towards running out of disk space next month.” / “Alert me when CPU on a production server exceeds 2× the normal value for this time of day.”

The first consultation takes just 30 minutes. It is free, no commitment, and you will immediately know how and with what we can help you.
Fragmented tooling, three sets of tools and no unified view. Here are the results that changed all that:
Každý nástroj v prostředí stojí víc než jen jeho licenci. Stojí čas na správu, integraci, školení a údržbu. A pro prostředí kolem 500 VM a 30 hypervisorů se tyto náklady rychle sečtou. Bez Azure Arc by Model Group potřeboval System Center pro Windows část, samostatný nástroj pro Linux management a další vrstvu pro centralizované logování. TCO bez Azure Arc se pohybuje mezi přibližně 601 000 až 891 000 EUR za 5 let. S Azure Arc a Software Assurance klesá tento náklad na přibližně 197 000 EUR za 5 let. Průměrná úspora: přes 9 000 EUR měsíčně.
Z čeho se skládá úspora?
S Azure Arc nevznikají náklady na samostatný Linux management nástroj (65–130 tis. EUR / 5 let) ani na log management stack (43–87 tis. EUR / 5 let). Windows část je pokryta Software Assurance bez extra poplatku za Arc.
Původně byly logy pro Windows Server uloženy lokálně nebo přesměrované přes WEF, Linux logy lokálně nebo přes Syslog forwarding. Každý incident znamenal ruční přepínání mezi systémy a zdlouhavé hledání příčiny. Po nasazení Azure Arc začala data z on-premises serverů proudit do stejného centrálního Log Analytics workspace. Poprvé v jednom místě — Windows, Linux, Azure, kontejnery. Retence až 2 roky. Logy navíc slouží jako základ pro automatizace přes Logic Apps a Azure Functions.
Co to znamená při řešení incidentu?
„Který proces měl problém s připojením k ověření CRL certifikátu?" Místo přepínání mezi nástroji jeden dotaz — a odpověď platí pro celé prostředí najednou.
Původní stav: WSUS pokrýval jen Windows a jen část z nich. Linux se záplatoval ručně nebo vůbec. Nikdo nevěděl, kolik procent prostředí je skutečně aktuální. Po nasazení Azure Arc a Azure Update Manager získal Model Group jednotný přehled o stavu aktualizací u 100 % serverů. Pomocí tagů byly servery rozřazeny do maintenance windows — výroba, testování, kanceláře. Patching běží automaticky v daném pořadí. Pro komplexní scénáře se závislostmi — například SAP servery — byla nastavena orchestrace pomocí Logic Apps a Azure Automation.
Tip z praxe
Patchování je nudné — a to je dobře. Pokud je vaše patchování dramatické, něco se děje špatně. Cílem je dělat ho tak pravidelně a automaticky, aby o něm nikdo nepřemýšlel.
Některé produkční systémy běžely na Windows Server 2012 R2 — verzi, které Microsoft ukončil rozšířenou podporu. Plná migrace před termínem nebyla realistická. Řešení: Extended Security Updates aktivované přímo pro Arc-spravované servery, v režimu pay-as-you-go — stejný přístup platí i pro SQL Server. Model Group platí jen za stroje, které ESU skutečně potřebují. Jak migrace postupuje, licence se uvolňují. Žádný compliance gap, žádný krizový projekt.
Model Group potřeboval audit Microsoft SQL napříč celým prostředím — z důvodu licencování a plánované konsolidace. Standardně jde o zdlouhavý manuální proces: někdo obchází servery, sbírá data, sestavuje tabulky. Azure Arc měl SQL extension. Auditor se přihlásil a okamžitě viděl aktuální přehled celého SQL prostředí skupiny:
Žádná příprava navíc. Arc byl již nasazen — data byla prostě tam.
„Získáme přehled o tom, kde SQL skutečně běží, v jakém rozsahu a v jakém stavu — ne jen o tom, kde si myslíme, že běží."
The IT team has one dashboard instead of three tools. Patching is an automated process with reporting, not a manual task. An SQL audit that would previously take weeks now takes hours. The security posture of the entire group environment is visible in one place.
And perhaps the most important change: the IT team stopped paying for things it does not need, and stopped dealing with things the system can handle on its own.
What the customer says
“For the first time we had a complete overview of the entire environment: every server visible, every server managed.”
IT Director
Model Group
We did not act as an external vendor who comes in, deploys and leaves. We set up ESU licensing so that Model Group only pays for what it genuinely needs, and stops paying as soon as systems are migrated.
The entire solution was handed over to the internal team with the goal of knowledge transfer, not dependency.
* Tooling savings are based on a modelled TCO calculation for the Model Group environment (30 hypervisors, ~500 VMs). Other metrics are based on project documentation.
We have seen this at dozens of companies. In a first 30-minute call with an expert you will find out whether Azure Arc is the right solution for you.