case study

// production-case-study

Brexy.ai domain migration

A production cut-over from waisabi.com to brexy.ai across DNS, ACM certificates, Amplify hosting, ECS service checks, and deployment pipelines.

live site back to projects

// problem

The production brand needed to move from waisabi.com to brexy.ai without interrupting active services. The migration touched public DNS, certificate validation, Amplify domain routing, backend service health, and the CI/CD path that kept releases moving.

// constraints

  • Keep production available during the domain cut-over.
  • Validate SSL certificates before traffic moved.
  • Avoid manual changes that would drift away from Terraform.
  • Confirm ECS, ALB, frontend, and landing routes after the switch.

architecture.svg

Final Architecture

Brexy production request and deployment architecture Users reach brexy.ai through Route 53, CloudFront and Amplify for the frontend, and an application load balancer to ECS Fargate services backed by RDS, Redis, Secrets Manager, ECR, and CI/CD pipelines. Users brexy.ai Route 53 DNS + ACM Amplify frontend ALB health checks ECS Fargate 6 services RDS Redis Secrets GitHub Actions CodeBuild ECR image CodePipeline deploy

// what changed

  • Verified DNS records, ACM validation, and Amplify domain mapping before routing production traffic.
  • Checked backend ECS tasks, ALB target health, and container health checks after deployment changes.
  • Kept deployment paths versioned through GitHub Actions, AWS CodePipeline, CodeBuild, ECR, ECS, and Amplify.
  • Started Terraform import work so manually-created resources could move under state without recreation.

// result

The production domain moved to brexy.ai with no user-facing downtime called out in the migration notes. The work also exposed the places where runtime health, IAM permissions, and infrastructure ownership needed tighter checks before future changes.