How Meridian Logistics Cut Infrastructure Costs by 62% with a Cloud-Native Migration

Overview

In early 2025, Meridian Logistics — a regional freight broker operating across twelve U.S. states — was running a decade-old on-premises infrastructure that had become a strategic bottleneck. With 220 employees, 3,800 daily shipments, and a customer portal built on a legacy PHP monolith, the company knew that each maintenance window was an exercise in negotiation and patient mitigation. Webskyne was engaged as the engineering partner to design and execute a full cloud-native migration over an eighteen-month horizon. This case study documents what actually happened: the real mistakes, the unplanned pivots, and the hard numbers that emerged when the migration was complete.

The Challenge

Meridian's infrastructure had grown organically for ten years. What began as a single server in an Austin co-lo had expanded into six machines hosting a PHP-based dispatch portal, an internal EDI integration layer written in SOAP-backed Java, a self-hosted Microsoft SQL database with unlogged triggers, and a backup regime that consisted of nightly tape offloads to a locked room nobody had key access to. By early 2025, the system was barely functioning as a cohesive stack.

The pain was quantifiable. Infrastructure costs were climbing at 18 percent annually, and that number did not include the hidden cost of operational toil. The engineering team of fourteen spent roughly thirty percent of its time on break-fix work: patching unpatched kernels, recovering corrupted database indexes, and explaining to customer service why the portal went down during business hours. The company had failed three PCI-DSS compliance audits in eighteen months. A SOC 2 attempt had been abandoned mid-engagement because the auditor could not map controls to undocumented services running on machines whose purpose nobody remembered.

Feature velocity was the strategic killer. The legacy stack required a full-stack deploy for even minor changes. A request to adjust freight-margin calculation logic took three weeks: one week of regression testing on a staging environment that was not a true production replica, one week of manual protocol migration testing, and one week of nervous production deployment during a Sunday maintenance window. Sales was losing deals because competitors were shipping real-time tracking dashboards while Meridian was still arguing about how to upgrade its jQuery version.

The Goals

We established five non-negotiable goals at the kickoff:

• Cost: Reduce annual infrastructure spend by at least 50 percent within eighteen months, with the savings verified independently by Meridian's CFO.
• Architecture: Migrate all forty-seven identified services to a containerized, orchestrator-managed environment running on Azure Kubernetes Service (AKS), with no service-to-service communication changes visible to customers.
• Availability: Achieve zero unplanned downtime during the migration, and validate a post-migration uptime SLA of 99.95 percent through independent synthetic monitoring.
• Velocity: Reduce time-to-production for non-infrastructure changes from three weeks to under one week, and enable bi-weekly deployment cycles for the customer portal.
• Compliance: Pass a SOC 2 Type II audit by month twelve, completing the compliance program that had been stalled for two years.

These goals were deliberately aggressive. A 50 percent cost reduction while simultaneously improving uptime and accelerating deployment cycles was not a linear tradeoff; it required doing three contradictory things at once. We needed to be more reliable, faster, and cheaper all in the same budget envelope.

The Approach

We rejected the big-bang migration pattern immediately. Meridian could not afford a six-month freeze on feature development, and the business risk of moving all services simultaneously was untenable. Instead, we proposed a mutation of the strangler fig pattern: incrementally route traffic and workload through new services while the legacy stack continues running, shrinking it over time until it can be switched off in a controlled decommission.

Before writing any code, we ran a four-week discovery sprint. The output was an application dependency graph that revealed Meridian's actual architecture was not forty-seven services — it was three monolithic applications hiding behind four poorly documented facade services. Understanding the true topology let us sequence the migration in dependency order rather than arbitrary service groups, which saved months of rework.

For the destination architecture, we chose:

• Orchestration: AKS for container management, with spot instances for non-critical batch workloads.
• Backend: NestJS with TypeScript for all new microservices, replacing PHP service nodes.
• Frontend: Next.js for the customer portal, integrating with an existing React component library.
• Data: PostgreSQL as the primary relational store, Redis for caching, and a new event-sourcing pattern for dispatch state changes.
• Infrastructure as Code: Terraform modules for reproducible environment provisioning.
• Observability: Prometheus, Grafana, and the ELK stack for logging, with synthetic monitors distributed across five geographic regions.
• Secrets Management: HashiCorp Vault with dynamic secret generation for database credentials.

A critical early decision was to form a Platform Engineering sub-team from Meridian's existing engineers rather than hire externally. We ran a two-week bootcamp on Kubernetes, Terraform, and GitOps workflows. The result was that the team that built the platform also owned it, which eliminated the handoff friction that kills most internal platform projects.

Implementation

The migration was executed in five sequential phases, each ending with a validated checkpoint before the next began.

Phase 1 — Foundation (Months 1–3)

The first objective was to build the new operational model before moving any production traffic. We stood up the AKS clusters, established the CI/CD pipeline using GitLab runners with environment-specific promotion rules, and deployed the observability stack to the new cluster while leaving the legacy infrastructure untouched. We also migrated twelve low-risk internal tools — SSO utilities, reporting cron jobs, and notification dispatchers — to validate the deployment pipeline at scale with zero business impact.

The SQL database migration began here using Debezium change-data-capture. Every INSERT, UPDATE, and DELETE against the legacy SQL Server was streamed into a shadow PostgreSQL instance in real time, giving us an up-to-date replica without any downtime. This approach meant that when transition time came for each service, the database would already be synchronized and validated.

Phase 2 — Strangler Fig (Months 4–8)

We deployed an API gateway in front of the legacy monolith. Rather than rewriting all services, we began routing traffic for discrete API endpoints to new NestJS services. First came customer authentication, then shipment status endpoints, then rate calculation. Each migration required a feature-flag-gated switch of request routing, with auto-rollback if error rates exceeded a strict threshold.

The dispatch engine — the most critical and most tightly coupled legacy module — was split at the domain boundary. Order intake moved to a new service in month five. Route optimization moved in month six. Each module was delivered with a fully parallel legacy path still active, allowing us to validate behavior under real load before fully cutting over.

Phase 3 — Optimization (Months 9–12)

With the core services on the new platform, we focused on cost governance and resilience. AKS cluster autoscaling was tuned using predictive scaling rules based on historical peak volume. Spot interruptions were actively managed by moving non-critical workloads to reserved instances. We deployed an internal cost dashboard that surfaced per-team spend, giving engineering managers the data to make intentional tradeoffs rather than reacting to end-of-month invoice surprises.

SOC 2 preparation happened in parallel. Because every infrastructure change was version-controlled and every production access was logged via Vault, the evidence file compiled quickly. Meridian passed its SOC 2 Type II audit in month eleven.

Phase 4 — Hardening (Months 13–15)

Before decommissioning the legacy stack, we ran chaos engineering tests against the new platform. We simulated pod failures, network partitions, and database availability losses. Each test was followed by a blameless review. The result was a significantly hardened platform with automated self-healing behaviors, circuit-breaker patterns, and a tested disaster-recovery runbook that reduced mean-time-to-recovery from hours to minutes.

Phase 5 — Decommissioning (Months 16–18)

The final phase was not technical — it was psychological. Engineers who had spent a decade with the legacy system were reluctant to decommission the last server. We treated decommissioning as a product launch: documented every step, ran multiple drill runs, and celebrated each sunset milestone publicly.

In month seventeen, we cut DNS over to the new cluster entirely. The legacy data center was powered down in month eighteen. The final tape backup was ceremonially destroyed — with scissors — in the presence of the entire engineering team.

Results

The project finished slightly ahead of schedule and materially exceeded every quantitative goal. Two months before the eighteen-month deadline, we completed all five phases. The CFO independently verified an infrastructure cost reduction of 62 percent against the original baseline — more than the 50 percent target we had committed to. The savings came from three sources: eliminating physical colocation overhead, replacing over-provisioned VM reservations with dynamic AKS autoscaling, and retiring legacy software licensing costs that had been quietly rising for years.

Zero-downtime was maintained throughout the migration. We synthesized this claim with five independent synthetic monitors running from different geographic regions, testing every core API endpoint every thirty seconds. Not a single customer-facing outage occurred during the eighteen-month engagement — a validation of the strangler fig approach and the rigorous feature-flag rollback discipline.

Feature velocity improved from quarterly major releases to bi-weekly deployment cycles for the customer portal, exceeding the one-week target for non-infrastructure changes. The engineering team moved from dreading the monthly maintenance window to shipping improvements on a predictable cadence. Recruitment also shifted: Meridian went from struggling to attract mid-level engineers to receiving unsolicited applications, because the technology stack had become one that engineers wanted to work on.

Metrics

• Infrastructure cost reduction: 62 percent (target was 50 percent).
• Services migrated: 47 microservices and internal tools containerized and orchestrated on AKS.
• Completion timeline: 18 months, with Phase 5 finish two months ahead of schedule.
• Uptime during migration: Zero unplanned customer-facing downtime, verified by five-region synthetic monitoring.
• Post-migration SLA: 99.99 percent availability across core APIs.
• Deployment frequency: From major releases every 12+ weeks to production deployments every two weeks, with hotfix capability in under 24 hours.
• P1 incident reduction: 40 percent decrease in severity-one incidents, driven by observability and automated rollback policies.
• Compliance: SOC 2 Type II certification achieved in month eleven, PCI-DSS remediation completed in month fourteen.

Lessons Learned

1. The strangler fig is not just a technical pattern — it is a risk-management tool. By keeping the legacy system running in parallel, we gave every stakeholder — engineering, operations, sales, customer service — the psychological safety to validate the new platform under real conditions. Big-bang migrations feel fast until they fail, and then they feel catastrophic.

2. Invest in observability on day one. Our decision to deploy the full observability stack before migrating a single service meant that every behavioral change was captured the moment it happened. Without that early investment, the migration would have been opaque, and debugging production issues during the transition would have consumed far more time than it did.

3. Train existing engineers instead of replacing them. The Platform Engineering sub-team built the platform and owned it. That ownership created accountability and institutional knowledge that external contractors or new hires could not have provided in the same timeframe. Moreover, the bootcamp gave existing engineers a career growth path, which reduced turnover at exactly the moment the company needed stability.

4. Cost governance has to be intentional, not incidental. Cloud cost transparency is not automatic. Without the internal dashboard surfacing per-team spend, the infrastructure savings would likely have eroded within a year as new services were provisioned without cost constraints. The governance layer is as important as the technology layer.

5. Documentation is a feature, not a footnote. The SOC 2 audit was manageable largely because every infrastructure change, access grant, and deployment pipeline was documented as part of the workflow. Treating documentation as part of the Definition of Done — rather than a task to complete after the work — compounded into a compliance asset that saved weeks of auditor query cycles.