Cloud Migration

Zero downtime during cutover comes from preparation, not luck. The key steps: (1) Build the new environment completely and validate it thoroughly before touching the live system. (2) Run old and new environments in parallel — during this period the new environment is being tested with production-equivalent traffic patterns. (3) Set up database replication so the new database stays in sync with the old one during the parallel period. (4) When both we and the client are confident, execute the DNS cutover with minimal TTL. (5) Monitor intensively for 48 hours post-cutover with the old environment still running and DNS rollback ready. The parallel running period is typically 1–2 weeks — longer for complex environments or high-risk migrations.

For a lift-and-shift migration (same architecture, new infrastructure), code changes are minimal — typically configuration updates for environment variables, connection strings, and storage paths. For a cloud-native re-architecture (taking advantage of cloud services like managed databases, object storage, serverless functions), code changes may be required to replace infrastructure-specific components. We identify which approach is appropriate in the assessment phase and document any required code changes clearly before migration begins. We never discover code change requirements mid-migration.

Every migration engagement includes a 60-day post-migration support period — intensive monitoring for the first 48 hours, active monitoring and rapid response for the remaining period. During this time we also identify cost optimisation opportunities — cloud resources are often initially over-provisioned to ensure stability, and right-sizing once traffic patterns are established can reduce ongoing costs. After the 60-day period, you can continue on a cloud management retainer or hand management to your own team with full documentation of the infrastructure we've built.