Monolith zu AWS migrieren – ohne Ausfallzeiten

Migrating a monolithic application to cloud-native architecture without downtime sounds impossible. We did it for a logistics company operating across 6 countries. Here's the step-by-step approach that made it work.

Assess what you actually have

Before any migration, you need a brutally honest assessment of your current system. Map every dependency, every integration point, every piece of infrastructure that keeps the lights on.

We spent two weeks documenting the existing monolith — database schemas, API endpoints, cron jobs, file storage patterns, and authentication flows. This assessment prevented at least a dozen surprises during migration.

The strangler fig pattern

We used the strangler fig pattern: build new services around the old system, gradually routing traffic to new components while the monolith shrinks. No big-bang cutover. No weekend maintenance windows.

• Identify a bounded context that can be extracted as an independent service
• Build the new service alongside the monolith, sharing the same database initially
• Route traffic to the new service using feature flags
• Once stable, migrate the data store and cut the dependency on the monolith
• Repeat until the monolith is empty

Infrastructure as Code from day one

Every piece of cloud infrastructure was provisioned via Terraform. No manual console clicks, no snowflake environments. This meant our staging environment was identical to production, and rolling back a failed deployment was a single command.

Zero-downtime database migration

The database migration from SQL Server to PostgreSQL was the highest-risk phase. We used a dual-write strategy: the application writes to both databases simultaneously during the transition period. Once we confirmed data consistency, we cut over reads to PostgreSQL and retired the old database.

Total downtime during the entire 8-month migration: under 15 minutes — and that was a planned maintenance window for a DNS change.