When enterprise compliance killed our cloud provider relationship

Processing 200K+ shipments monthly across the EU, a Rotterdam logistics platform had built everything on US cloud infrastructure. The tech stack was solid, costs were predictable, and 99.95% uptime kept everyone happy.

Until enterprise clients started asking: "Where exactly is our shipping data stored? Which governments can access our customs information?"

Turns out, being hosted on US cloud infrastructure in EU regions doesn't solve the CLOUD Act problem. Here's how we rebuilt their entire stack for complete data sovereignty without breaking production.

The technical problem behind the compliance issue

Their existing setup was actually well-architected:

• 6 load-balanced application containers
• Managed PostgreSQL with multi-zone read replicas
• Redis cluster for sessions and caching
• 2.3TB of shipping documents and customs data
• Full observability stack

Performance was solid: 180ms average API response, 99th percentile under 800ms, database queries averaging 45ms.

But the US parent company created legal exposure that enterprise clients couldn't accept. Three major contracts were at risk, and new deals were stalling on data sovereignty questions.

Bonus discovery: they were overpaying €18,000/month for managed services they barely used.

Migration strategy: parallel infrastructure, not incremental

Instead of migrating piece by piece (which creates complexity and partial-state nightmares), we built a complete parallel environment.

Advantages:

• Test the entire system under realistic load
• Immediate rollback if anything breaks
• Single coordinated switchover instead of managing migration state

Implementation details

We rebuilt everything on EU-sovereign infrastructure across Amsterdam and Frankfurt datacenters.

Load balancing configuration

Switched from managed load balancers to nginx with session affinity:

upstream logistics_app {
    server 10.1.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.1.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.1.1.12:8080 max_fails=3 fail_timeout=30s;
    server 10.1.2.10:8080 max_fails=3 fail_timeout=30s backup;
    server 10.1.2.11:8080 max_fails=3 fail_timeout=30s backup;
    server 10.1.2.12:8080 max_fails=3 fail_timeout=30s backup;
}

Database migration

Moved from managed PostgreSQL to self-managed with streaming replication. Used logical replication for zero-downtime data migration:

CREATE PUBLICATION logistics_migration FOR ALL TABLES;
CREATE SUBSCRIPTION logistics_sync 
    CONNECTION 'host=old_db port=5432' 
    PUBLICATION logistics_migration;

This kept the new database in sync while we gradually shifted read traffic for testing.

Monitoring stack

Replaced cloud provider monitoring with Prometheus and Grafana, tracking the same business metrics: shipment processing rates, API response times, database performance.

Results that matter

Performance improvements:

• API response time: 180ms → 120ms average
• 99th percentile: 800ms → 520ms
• Heavy reporting queries: 2s → 1.2s average

Cost reduction:

• Monthly costs: €18,000 → €11,200 (38% reduction)
• Predictable pricing, no surprise bills

Business impact:

• Secured €2.1M in new contracts within 6 weeks
• Data sovereignty became competitive advantage
• Zero downtime during migration

The key insight: managed cloud services often cost more and perform worse than properly configured dedicated infrastructure, especially when you have specific compliance requirements.

For logistics workloads with predictable patterns, the managed service premium isn't worth it. You get better performance, lower costs, and complete control over your compliance story.

Originally published on binadit.com