Dual region migration: Outpost → Türkiye VPS → Frankfurt ECS
Client
B2B SaaS Platform (Confidential)
Year
2026
I led a high risk infrastructure migration for a multi service B2B SaaS platform. The goal was to stand up a new Türkiye production environment (services + PostgreSQL) and cut traffic over via Route53, then migrate DE workloads to an existing Frankfurt ECS cluster with a separate PostgreSQL instance, and finally decommission the legacy environment without breaking production.
My Role: Product Manager, delivery lead across engineering + ops (phasing, readiness gates, risk/rollback, documentation)
Goal: Stand up TR production first, then migrate DE workloads to Frankfurt ECS, then decommission the legacy environment without breaking production.
Scope of Work
Architecture diagram shows the target state: two isolated environments with their own PostgreSQL instances, and clear boundaries between services and data. It’s the “single source of truth” I used to align decisions, dependencies, and rollout order.
A phased plan with validation gates. Phase 1 shipped TR production via DNS cutover, Phase 2 moved DE workloads to Frankfurt ECS with a separate DB, Phase 3 removed legacy infra only after stability checks.
This is the cutover runbook. We reduced TTL in advance, updated Route53 records, validated service health and core flows, and defined rollback triggers before touching production traffic. It kept execution predictable and reduced rework during the window.
Branch-based deployment made shipping repeatable: main deploys to Türkiye production, de-main deploys to Frankfurt ECS. The pipeline bakes in health checks and rollback paths so releases don’t depend on manual steps.
