Cloud migration
I move teams onto AWS, Azure, or Google Cloud, or out of a setup they've outgrown. I map every dependency before anything moves.
On the AWS migrations I delivered as a consultant, client NPS went from 8 to 10. That result didn't come from the interesting parts. It came from the boring ones: accounts nobody owns, a network that grew by accident, a dependency nobody drew on the diagram. So I map what you actually run before anything moves. Once the map is accurate, the right order of moves is easy to see.
- Readiness assessment and a target architecture your team can run
- Landing zone, identity, and networking in an EU region
- Multi-account AWS foundations in Terraform, ready for due diligence
- Migration in waves, with a rehearsed cutover
- Off Heroku, a single server, or on-premises hardware, awkward workloads included
- Legacy code modernised onto managed services along the way

