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.
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.
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 symptomsWhat 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.
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.
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.
Before the first application moves, the foundation stands: account structure, network, access through SSO rather than long-lived keys, central logging and encryption. All of it in Terraform, so it stays reproducible and explainable in an audit.
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.
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.
The inventory is a self-contained engagement. After it you decide with numbers whether and how it continues.
Trigger, deadline, scope, who runs it afterwards. 30 minutes is enough for a first read.
Systems, dependencies, a migration path per application, and a cost model for the target state.
Accounts, network, permissions and logging in Terraform, before the first application moves.
Uncritical first, business critical last. Every wave with a cutover plan and a rehearsed rollback.
What appears on the invoice was known beforehand. No system that only surfaces when you switch it off.
Accounts, network and permissions come out of Terraform. The second environment is an apply, not a week of work.
Runbooks, monitoring and pairing, rather than an environment only the contractor understands.
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.
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.
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.
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.
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.
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreReplacing 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 moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreModernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn more