Taking over an AWS system you did not build

The short answer

When you take over an AWS system you did not build, check four things in a fixed order before you let anyone change it: who owns and can access the account, how code actually reaches production, what the tests actually cover, and what is running and costing money. Do them in that order because each one tells you how much to trust the next. A system with a clean deploy path and no tests is a different problem from one with tests and a deploy path nobody can describe.

1. Ownership and access. Root, billing, domains, IAM, secrets. If you do not own these, you do not own the system.
2. The deploy path. Trace one change from a commit to a running process. Whatever you cannot trace, you cannot roll back.
3. The tests. Not the coverage number. What would actually fail if the checkout flow broke.
4. What runs and what it costs. Every resource with an owner and a reason, or a decision to switch it off.

The output is a map, a risk list you can defend, and a keep, fix or replace recommendation. The rest of this page is how I run each step, drawn from a takeover at Datavid where the starting point was 14 hand-built VPCs and no tagging.

Week one: ownership and access

Before anything technical, establish that you hold the keys. That means the root account email and MFA, the billing contact, the domain registrar and DNS, the IAM users and roles with administrator access, and every place a secret lives: Secrets Manager, Parameter Store, CI variables, and the inevitable .env file committed three years ago. Inventory these first without changing them. Then rotate the high-risk set on day one: root, administrator credentials, deploy keys, and anything a departed party could still hold.

Do not rotate everything at once. A credential you did not know was in use will take something down, and in week one you do not yet know how to bring it back. Inventory, rotate the dangerous few, then work through the rest as you learn where each one is consumed. CloudTrail tells you which access keys are actually being used; the ones with no activity in 90 days are the safe place to start deleting.

How it actually deploys

Pick one recent change and trace it end to end: the commit, the pipeline or the person who ran it, the artifact, the environment it landed in, and the process that is now serving it. In an inherited system this trace almost always has a gap, and the gap is where the risk lives. Common ones: a pipeline that only works from one engineer's laptop, an image tagged latest with no record of what is in it, a database migration applied by hand and never committed, or infrastructure that exists only in the console because the Terraform stopped being applied a year ago.

The question you are answering is whether you can roll back. If the trace is clean, you can. If it is not, the first repair is not a feature and not a refactor. It is making the deploy path describable and repeatable, because until then every other change is a one-way door.

What the tests actually cover

Ignore the coverage percentage for now. Ask instead: if checkout broke, or the sign-up flow, or whatever the product cannot live without, would any test fail before a customer noticed? Read the tests for the two or three paths that matter most. In inherited systems it is common to find high coverage of utility code and nothing on the flows that earn revenue, or a suite that has been red for months and is skipped in CI.

The honest output here is a short list: the flows that are protected, the flows that are not, and whether the suite runs at all. That list decides how carefully every later change has to be made and where the first tests should be written if you decide to keep the system.

What runs, and what it costs

Pull the resource inventory from AWS Config and the last three months from Cost Explorer, then put a name and a reason against every line. In practice a meaningful share of an inherited account is nobody's: the staging environment for a feature that shipped, the oversized database from a load test, the NAT gateway in a VPC nothing uses. On the Datavid takeover, the audit found 14 VPCs provisioned by hand with overlapping subnets and no tags, which meant cost could not be attributed to anyone and drift was causing about a dozen incidents a month.

Do not delete anything in this step. Tag it, name an owner or mark it as unowned, and note what it costs. Deleting comes later, once you know what the deploy path and the tests will tell you if you were wrong. What you can do immediately is turn on tagging enforcement so the problem stops growing; on that engagement AWS Config rules caught 90% of the untagged resources in the first month.

The map you should have at the end

A takeover review ends with something your team can point at. Mine has four parts. A component map: what runs where, what it talks to, and who owns it. An access map: every credential and role, who holds it, and when it was rotated. A risk list where each entry names the evidence, the blast radius and the fix, with the unknowns marked as unknown rather than guessed. And a keep, fix or replace recommendation in the order I would act, starting with whatever makes the next change safe to make.

The map is also the first honest handover document the system has had. On the Datavid engagement, the reference architecture and the Terraform modules that came out of the audit are what took new environment setup from two to three weeks to about 45 minutes, and the quarterly audit findings from 47 to 3. None of that was possible until someone had written down what was actually there.

What not to do in week one

• Do not start the rewrite. You do not yet know what the system does, so you cannot know what the rewrite has to do. Decide that on evidence, not on first impressions of the code.
• Do not delete resources to cut cost.Tag and name them. Deletion is safe only once you can roll back.
• Do not revoke the previous team's access as a reflex. Get your own read-only access first, then revoke theirs as a deliberate final step once you know what depends on it.
• Do not ship features. A two-week pause while the deploy path becomes repeatable costs less than one bad release with no way back.
• Do not trust the README. Trust CloudTrail, Config, the billing export and the pipeline logs. They cannot be out of date.

Turning a takeover into a handover

The goal of a takeover is not that I understand the system. It is that your team does, and can change it without me. So the review is done with your engineers, not to them: they run the traces, they write the map, and the risk list is theirs to argue with. On the Datavid work, the weekly review sessions where junior engineers explained why a decision was made, not just how, were the highest-leverage part of the engagement. Three of them went on to design compliant environments on their own.

If the review says keep and fix, your team has the plan and can carry it out. If you want hands-on help with the fixes, that is a separate, scoped phase with its own checks and its own written handover. Either way, the system stops being something you inherited and becomes something you own. That is the whole point. Start with the project rescue review if that is where you are.