Windows-to-Linux Containerization for a National Telecom

01 The Challenge

A major national telecom provider’s operational-support-system (OSS) API services — the services that provision and manage subscriber lines — were Windows-only .NET applications. That single fact blocked any move to containers and modern orchestration: no Linux images, no shared container platform, no path forward for some of the most critical services in the estate.

The blockers were buried deep. Windows-only DLLs hid inside dependency trees, data-access layers leaned on Windows-specific drivers, and the hardest problem of all — IBM DB2 and Informix native client libraries on Linux — had no ready-made answer. Leopard Data led the containerization effort, while carrying a normal sprint load of production bug fixes across the OSS API estate the entire time.

02 The Approach

We started by auditing each service’s dependency tree to isolate the Windows-only DLLs, then rewrote the data-access layers onto cross-platform EF Core. The DB2/Informix problem was solved the unglamorous way: working directly with IBM support, through fix packs, until the native client libraries reliably delivered data access on Linux.

With the blockers cleared, services — subscriber management and switch-integration APIs — were ported to build and run on RHEL, packaged as Docker and Podman images, and deployed and validated through Portainer onto the shared container platform. We also researched the Consul/service-mesh direction for what would come next.

Just as important as the ports themselves: we wrote the wiki documentation and runbooks — NuGet configuration for Linux, LD_LIBRARY_PATH setup, build tasks — so other teams could repeat the pattern without re-solving the same problems.

03 The Delivery

The first formerly-Windows-only OSS services went live as Linux containers on the shared platform, validated end-to-end through Portainer. What had been a hard wall — native IBM database clients on Linux — became a documented, repeatable step in the build.

None of this displaced the day job. Production defect fixes across the OSS API estate shipped sprint after sprint alongside the containerization work, so the migration never came at the expense of the services keeping subscriber lines running.

05 Tech Stack