There is a real trigger.
A contract end, hardware, licence cost or growth limit provides both a deadline and economic basis.
All services
AWS migration
Into the cloud, without flying blind. With the cost model done before the move.
The trigger is usually a date: the data centre contract runs out, the hardware is end of life, the virtualization licence suddenly costs three times as much. I plan and run the move to AWS, with the cost calculation standing before the move and a rehearsed way back for every step.
AWS Certified Solutions Architect – ProfessionalAWS Certified Security – SpecialtyHashiCorp Certified: Terraform Associate
What you get
- An inventory of every system with dependencies and a migration path per application
- A cost model for the target state, before the first server moves
- A landing zone in Terraform: accounts, network, permissions, logging
- A cutover plan with a rollback path, rehearsed before it is needed
Scope & working together
Inventory and cost model as a self-contained two to four week engagement. The migration itself then runs in waves, ordered by risk.
Remote from Germany. Straight with me, no agency in between.
The starting point
The date is fixed. The plan is not.
Migrations rarely fail on the technology. They fail because nobody fully knows what is actually running: which application depends on which database, which cron job has been doing something important at night for eight years, which firewall rule exists and why. Without a deliberate effort that map only appears under time pressure, which is too late.
The second classic is the invoice. Move one to one and you take your utilization problems with you, and pay for them by the hour from then on. That is why the cost calculation belongs before the move rather than in hindsight, and why for some systems the honest recommendation is to change them first, or not bring them at all.
Typical symptoms- The data centre contract runs out in twelve months.
- Nobody has a complete list of what runs on which server.
- Licensing costs for virtualization have jumped sharply.
- There is no defensible figure for what AWS will cost per month.
- No rollback is planned, because it is supposed to work.
- The team has never run AWS in day-to-day operation.
Who this is for
For companies where moving to AWS has a deadline and real consequences.
For CTOs, IT leaders and infrastructure owners with production workloads. A data-centre contract, hardware or an existing platform creates a concrete trigger while operations still need to remain predictable.
Dependencies must move too.
Applications, databases, networks and partners are connected; the plan must expose their order.
Cost and rollback come first.
You want target cost, migration waves and rollback paths before the first production workload moves.
What I do
Record.
Calculate.
Move.
01
Inventory and dependencies
What runs where, what depends on it, who uses it. I record servers, services, databases, jobs and data flows, and make the dependencies visible, including the ones nobody has on their list any more. That map is the basis for everything else.
02
A migration path per application
Not everything deserves the same treatment. Some of it gets lifted across, some gets containerized on the way, some gets rebuilt, and some gets switched off because nobody needs it any more. For each application that decision is made with reasons and an effort estimate attached.
03
The cost model before the move
What the target state costs per month, realistically, based on your actual utilization rather than your server specifications. Including the line items that surprise people on the first invoice: data transfer, NAT gateways, logs, backups. Where moving one to one would be expensive, that is established up front.
04
Landing zone and baseline security
Before the first application moves, the foundation stands: account structure, network, access through SSO rather than long-lived keys, central logging and encryption. Whether the AWS landing zone is built through Control Tower or directly in Terraform depends on the case: Control Tower takes work off your hands and prescribes structure, a build of your own leaves more freedom and more responsibility. Both are described in Terraform as far as the route allows: with Control Tower the part AWS rolls out stays in its hands. Either way it remains reproducible and explainable in an audit.
05
Cutover with a way back
Databases move with replication, the switchover window is measured in minutes. Every step has a rollback path, rehearsed before it is needed. Migration runs in waves ordered by risk, with the uncritical systems first so the team has the routine before it matters.
06
Handing over operations
Running AWS is a different job from running servers. Monitoring, alerts, runbooks and cost control that does not surface only at month end, plus pairing with your team until day-to-day operation works without me.
Specific cases
Building an AWS landing zoneFor when the environment has long run on AWS but everything lives in one account and the first customer asks about separation and logs. Account structure, access through SSO, guardrails, central logging. A page of its own.Introducing TerraformFor when the environment already runs on AWS but exists only in the console. Import what is there rather than recreating it, state with locking, drift removed, environments reproducible. A page of its own.
A deadline behind you and still no defensible plan?
Let’s spend 30 minutes on scope and timeline.
How it runs
Know what is there, then move it.
The inventory is a self-contained engagement. After it you decide with numbers whether and how it continues.
STEP 01
Frame the situation
Trigger, deadline, scope, who runs it afterwards. 30 minutes is enough for a first read.
STEP 02
Inventory, 2–4 weeks
Systems, dependencies, a migration path per application, and a cost model for the target state.
STEP 03
Landing zone
Accounts, network, permissions and logging in Terraform, before the first application moves.
STEP 04
Migration in waves
Uncritical first, business critical last. Every wave with a cutover plan and a rehearsed rollback.
The outcome
What you end up with.
A move without surprises
What appears on the invoice was known beforehand. No system that only surfaces when you switch it off.
An environment that is reproducible
Accounts, network and permissions come out of Terraform. The second environment is an apply, not a week of work.
A team that can run AWS
Runbooks, monitoring and pairing, rather than an environment only the contractor understands.
Technologies I use
Proven tools. No experiments.
Accounts
- AWS Organizations
- Control Tower
- IAM Identity Center
- Landing zone
Network
- VPC
- Transit Gateway
- Route 53
- Elastic Load Balancing
- CloudFront
Compute
- ECS Fargate
- EKS
- EC2
- Lambda
- Auto Scaling
Data
- AWS DMS
- Amazon RDS
- Aurora
- S3
- DynamoDB
Security
- IAM
- KMS
- CloudTrail
- GuardDuty
- Secrets Manager
Infrastructure
- Terraform
- AWS CDK
- CloudFormation
- Docker
Operations
- CloudWatch
- OpenTelemetry
- Datadog
- Prometheus
Delivery
- Blue/green
- GitHub Actions
- GitLab CI
- Cloudflare
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development. Today I move running systems to AWS without the business standing still. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Working together
Working with your team or delivering independently.
You do not need to bring a particular setup. I adapt the engagement to how your company works and how much responsibility you want to hand over.
01Together
I work as part of your team.
If knowledge and responsibilities already sit with you, I join wherever additional experience is needed. Inside your workflows, in direct contact, without creating a parallel track.
- Integration into your sprints, reviews and technical decisions
- Pairing and knowledge transfer throughout delivery
- Code, documentation and operations remain fully with your team
02Independent
I take ownership of delivery.
If you lack time or capacity internally, I take a clearly scoped piece of work from technical clarification through to production. You set the objective and constraints; I take care of the path there.
- One point of contact from clarification through to delivery
- Regular, clear progress updates without day-to-day supervision
- A proper handover with documentation and a walkthrough
Whichever model you choose, you always know what is being built, which decisions are pending and what happens next. Billing follows the project and the model you prefer: clearly bounded work at a fixed price, longer or more open-ended work by time spent.
Continuity
Your system remains yours.
Independent delivery does not create dependency on me. Everything required to develop and operate the result stays in your environment from day one and remains ready for handover throughout the engagement.
Access stays with you.
Code, cloud accounts, pipelines and secrets live in your systems. Operations never depend on a personal account or credentials that only I control.
Knowledge does not stay in my head.
Architecture decisions, operating procedures and known risks are documented where your team will find them and kept current as the work progresses.
Someone else can take over.
Reproducible environments, automated deployments and regular handovers allow your team or another provider to continue without starting again.
The goal is not for you to depend on me permanently. The goal is for you to remain free to decide who develops the system next.
Client voices
What clients say afterwards.
“A big thank you to Tim! The AWS migration was a really big chunk for us, but you handled it with complete confidence. Especially with the small issues that came up along the way, you were on it immediately and did not let go until everything ran.”
Common questions
Before you ask.
We have to get off VMware. Do you do that?
The AWS side yes, the VMware side no. What the estate costs on AWS, which items surprise you on the first bill, what comes along and what is better switched off, in which order the move runs and where the way back sits: that is my ground. The inventory work in vSphere, the licence negotiation with Broadcom and the comparison against Proxmox or Nutanix are not. For those you need somebody with operational practice in virtualization, and I would rather tell you that now than in week three.
Do we need AWS Control Tower for the landing zone?
Not necessarily. Control Tower sets up account structure, guardrails and logging to a prescribed pattern and takes work off your hands, above all when nothing is in place yet. If you already have a grown account landscape or particular requirements for networking and permissions, a build of your own in Terraform often serves you better. That decision comes out of the inventory rather than ahead of it, and it depends less on your size than on what already exists.
What will AWS cost us per month?
That is the question that belongs before the move. The cost model comes out of the inventory, based on your actual utilization rather than your server specifications, and includes the line items that surprise people on the first invoice: data transfer, NAT gateways, logs, backups.
Is the move worth it at all?
Not always, and not for everything. Move one to one and you take your utilization problems with you and pay for them by the hour from then on. For some systems the honest recommendation is to change them first, or not bring them. That gets settled by the inventory, and if the overall maths does not work I will say so too.
How long does a migration take?
The inventory takes two to four weeks. The move itself depends on how many systems there are and how entangled they are, which only becomes defensible once the dependency map exists. Migration runs in waves so something is finished early rather than everything landing at the end at once.
What if something goes wrong at cutover?
Every step has a rollback path that gets rehearsed beforehand. That is also why the uncritical systems move first: so the team has the procedure down before it touches anything business critical.
Can we keep parts in our own data centre?
Yes, and often that makes sense, whether for latency, licensing or assets still being depreciated. Then the job is a clean, secured connection between the two worlds rather than a complete move.
Terms that come up here
Landing zoneNAT gatewayEgress costTagging strategyWell-Architected FrameworkRTO and RPOBlue-green deploymentMulti-regionObservabilitySLO, SLI and SLABig bang migrationAuto scalingInfrastructure as codeCanary releaseData migrationLift and shiftReplatformingServerlessVPCIAMAmazon RDSCloudFrontContainerKubernetesLoad balancerChaos engineeringLeast privilegeSecrets managementZero trustEncryption at rest and in transitPenetration test
To the glossaryOther services
What else I help with.
Backend development
Backends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn moreLegacy modernization
Modernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreReducing AWS costs
I find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreImproving AWS resilience
So that a single fault does not take the whole application with it: dependencies and single points of failure identified, recovery rehearsed rather than documented, changes delivered as Terraform.
Learn moreAI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreProcess automation
Replacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn more