When CDK Was Not Enough
Restore Blue helps organizations manage coastal restoration projects. Millions of trees, complex tracking, real impact data. The infrastructure was built on AWS CDK and it worked. But as the platform grew, the limitations became hard to ignore.
CDK is powerful but developing with it is slow. Every change requires a full deployment. There is no way to test a Lambda function locally with real infrastructure. You write code, deploy, wait, check logs, repeat.
SST changed that. Live Lambda development meant I could see changes instantly. Resource bindings gave me type safe references between infrastructure and application code. The developer experience was significantly better.
The Migration Strategy
The key was running both stacks in parallel. The CDK stack kept serving production traffic while the SST stack was built and validated alongside it.
Phase one was deploying the SST stack with the same resources as the existing CDK stack. Phase two was routing new traffic to SST resources. Phase three was validating that SST handled every workload correctly. Phase four was decommissioning the CDK stack.
The Tricky Parts
DynamoDB tables needed to be recreated with SST naming conventions without losing data. That required a careful export and import process validated multiple times before the production cutover.
Route53 records needed to switch from CDK to SST resources atomically. One wrong DNS change could take the entire platform offline.
The team needed to coordinate feature freezes around migration windows. Every migration run needed to be scheduled, communicated, and executed cleanly.
Testing Saved Us
I ran the full migration in staging three times before attempting production. Each run uncovered something. A missing permission, a misconfigured environment variable, a Lambda function that referenced the old resource name.
By the time we did the production migration, it was routine. Thirty minutes of work and the CDK stack was decommissioned. Zero downtime, zero data loss.
What I Learned
Parallel stacks are safer than big bang migrations. Run both, validate the new one, then turn off the old one. Automate your validation. If you can test it in a script, test it in a script. And run the migration more times than you think you need to.
Top comments (0)