The consultancy of Jeff Kloythanomsup, Amsterdam
Cloud migration for EU startups and small businesses
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.
I keep seeing the same pattern at every company size. The startups and Fortune 500 teams I've worked with made the same migration mistakes, but a scale-up can't absorb them. That's why I build the landing zone in Terraform, move workloads in waves, and stay through cutover and the quiet weeks after it. I highly recommend fixing the foundation in one deliberate move rather than patching it for another year.
Reference architecture
How the pieces connect
An illustrative flow, not a diagram of a client environment.
1
Current estate
Accounts, workloads, data, and existing constraints.
2
Dependency map
Traffic, identity, storage, and failure domains.
3
EU landing zone
Networking, IAM, policies, and infrastructure as code.
4
Migration waves
Move and verify workloads in controlled stages.
5
Cutover checks
Rollback, data integrity, and operational tests.
6
Run and hand over
Monitoring, runbooks, and team ownership.
What's included
Readiness assessment and a target architecture your team can run
I inventory what you run and what depends on what. The target design on AWS, Azure, or Google Cloud follows from that map. I keep it small enough for your team to defend and operate.
Landing zone, identity, and networking in an EU region
Accounts, single sign-on, VPCs, and the guardrails between them. I set them up once, in the EU region your customers and your data protection officer expect. Every workload that follows inherits them.
Multi-account AWS foundations in Terraform, ready for due diligence
Everything lives in code from day one, reviewable and repeatable. The code is yours when I leave. An enterprise buyer or an investor doing technical due diligence can read it as it stands.
Migration in waves, with a rehearsed cutover
We move low-risk workloads first and rehearse before each wave. Every wave has a rollback path we've actually tried. Go-live week stays calm.
Off Heroku, a single server, or on-premises hardware, awkward workloads included
I've moved all three: the platform bill that stopped making sense, the one big server everything leans on, and the clusters and licensed software other teams route around. Awkward workloads are where an accurate map pays off.
Legacy code modernised onto managed services along the way
Where a rewrite pays for itself, I do it. That can mean containers, a managed database, or a Glue job in place of a batch script. At a major airline, that last one cut processing time by 90%.
Where I've done it
Every item here comes from my CV. View CV.
Senior Cloud Engineer, AWS consulting partner, 2021 to 2026
Delivered AWS migrations for a diverse customer base alongside architects and delivery managers, including moving high-performance computing workloads from on-premises to AWS. Client NPS on those engagements rose from 8 to 10.
Senior Delivery Engineer, managed cloud provider, 2020 to 2021
Sped up a Fortune 500 migration under the AWS Migration Acceleration Program by training five client engineers on Jenkins CI/CD, containerisation, and EKS deployment, so the client's own team carried the rest.
Senior Delivery Engineer, managed cloud provider, 2020 to 2021
Led the modernisation of a major airline's fare-management application, converting a legacy Python codebase to AWS Glue jobs and cutting processing time by 90%.
Senior DevOps Engineer, engineering agency, 2019 to 2020
Migrated mission-critical applications to AWS with Terraform and Terragrunt, removing a one-hour backup downtime window along the way.
Lead Cloud Support Engineer, AWS consulting partner, 2016 to 2018
Architected multi-account AWS infrastructure for two mission-critical banking applications on Fargate, Aurora, and ElastiCache.
Tools I reach for
AWS (EC2, ECS, EKS, Lambda, S3, Glue, Aurora/RDS, Fargate), Terraform, Terragrunt, CloudFormation, Docker, Kubernetes, Python, Bash.
Guides on this
The GDPR for startups running a cloud platform
What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.
Keeping data in the EU on AWS, Azure, and Google Cloud
How to keep customer data in EU regions on AWS, Azure, and Google Cloud, what still leaves, and the controls that prove it to a customer or auditor.
Other services
Platform engineering
I do cloud engineering on the platform you already run. I make it calmer, cheaper, and understood by more than one person on the team.
Read moreCloud security hardening
I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.
Read moreAI-built app security review
I review the app your AI coding agent wrote, from secrets and sign-in to the cloud account behind it, and rank what to fix first. From €500.
Read moreAI integration
I do AI consulting and AI engineering for EU teams. I put language models to work on the problems that matter, and I ship them to production.
Read moreFractional cloud leadership
Cloud architecture and a senior cloud lead on a fixed monthly retainer, long before a full-time cloud team makes sense.
Read moreCommon questions
- Which clouds do you migrate to?
- AWS, Azure, or Google Cloud, with an EU region as the default. Most of my hands-on work is on AWS. I hold the AWS Solutions Architect and DevOps Engineer Professional certifications.
- Can you move us off Heroku or a single server?
- Yes. A platform bill that stopped making sense, one big server, and on-premises hardware are the usual starting points. The first step is the same for each. I build an inventory of what runs and what depends on what.
- How long does a startup cloud migration take?
- Three variables set the timeline: the number of workloads, how tangled the dependencies are, and how much downtime the business can accept. A small estate can move in a few weeks. A larger one goes in waves, each with a rehearsal and a tested rollback. The readiness assessment turns those variables into a dated plan. Until then, the honest answer is: it depends.
- How is a cloud migration priced?
- Per project, not by the hour, in three fixed packages. A single application (one app off Heroku or a single server) is €10,000. A multi-account landing zone with four to fifteen workloads is €22,500. An enterprise estate (on-premises hardware, several clouds, or a compliance requirement) is €35,000. The Cloud Cost & Architecture Review (€2,500) sets the scope and fixes the price before any workload moves, and its fee comes off the migration price if you go ahead within 30 days.
- Will our own team be able to run it afterwards?
- That's the whole point. Everything lives in Terraform, reviewable and owned by your team. I stay through cutover and the weeks after it. I step back once your engineers run the platform without me.
Let's talk.
A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?
Prefer email or phone? hello@netninjas.eu or +31 6 45984313