Case Study · 01

Datacenter Exit: Migrating Three Interdependent Platforms Off Legacy Infrastructure

A mid-flight handoff, a sequencing mistake I corrected in real time, and a team spread across four countries — on a program that couldn't afford downtime.

Company Essilor Luxottica Role Platform Engineering Lead Stack Azure · AKS · Ansible · Kustomize · Zerto · GitHub Actions · Datadog
§1Context

A global optical retailer needed to exit its on-premise datacenter to eliminate the risk of failing legacy hardware. That meant three parallel migrations, each with a different owner and technical maturity — each pairing a legacy .NET monolith with a layer of modernized microservices, across multiple lower and production environments per platform, with CI/CD cutting over from legacy TFS to GitHub Actions along the way.

Ordering platform — company-wide eyewear orders Global PMS + EHR — thousands of practices Second PMS — shared codebase, separate front end

I inherited the program mid-execution, after the original architect was laid off. The architecture — Azure, AKS — was already decided. My job was to make it executable.

§2Decisions

AKS over managed container services

The team already ran on-prem Kubernetes via Rancher. AKS kept that operating model intact while matching a company-wide cloud directive.

Ansible for the monolith, Kustomize for the cluster

IIS, MSSQL, and middleware needed traditional configuration management. Kustomize governed all nine Kubernetes environments natively — no third-party overlay tool required.

Zerto replication to DXC for pre-cloud hardware

Some ordering-platform servers were too old for Azure. Using Zerto to replicate them to a DXC-owned datacenter kept the migration on schedule without forcing a rewrite.

§3Correction

One decision didn't hold up — and reshaped how I sequenced everything after it. We migrated the Kubernetes clusters first, planning for SQL Server to follow, but the databases were too large for the migration strategy we had in place, and the mismatch stalled the project. On the next platform in this program, I reversed the sequence — database first — because I now understood where the actual bottleneck lived. That correction became standard practice for the rest of the program.

§4Org complexity

A recurring pattern in distributed technical programs: team topology quietly becomes system topology — Conway's Law in practice. This program was a clean example. The platform team spanned the US, Philippines, and India; the DBA function reported separately out of the Philippines; the managed service provider operated out of Italy; and the original development team, who understood the monolith best, had no formal role in the migration.

Recognizing this early meant treating communication cadence and documentation as part of the technical plan, not overhead layered on top of it:

  • Daily syncs and weekly refinement calls to compensate for time-zone and reporting-line fragmentation
  • Wrote the user stories myself, filling the gap left by the dev team's absence
  • Documented the architectural decisions that previously existed only in the departed architect's head
  • Created a recurring space for the team to demo what they'd learned
§5Results
75% faster environment provisioning, via Ansible/Kustomize IaC
4wk → <1wk development lead time for modernized services
6hr → 45min MTTR, after Datadog observability rollout
§6Program map
ON-PREM Ordering Platform multiple lower + prod envs Global PMS + EHR multiple lower + prod envs Secondary PMS shared codebase, own front end Azure · AKS Ansible (monolith) + Kustomize (cluster) GitHub Actions CI/CD lower + prod envs per platform, cut over TFS → GitHub Actions DXC Datacenter via Zerto — too old for Azure
Simplified from working session notes — env counts and routing approximate.