AWS Transform and Superwerker: same vocabulary, different problems

Most people will read AWS Transform's landing zone agent as Superwerker's smarter cousin. I don't think that's right. Same destination. Different problems. Treating them as substitutes is how greenfield teams buy enterprise process they don't need - and how migration teams under-buy governance they do.

I saw the announcement via a LinkedIn post, and it stuck because the vocabulary overlaps heavily with a tool I've actually used and rate highly: Superwerker. I haven't run Transform myself - this is a read from the announcement and docs, not a hands-on review. I'd genuinely like to hear from anyone who has.

Superwerker: opinionated defaults, shipped

Superwerker is a free, MIT-licensed CloudFormation stack. You run it, and it stands up a multi-account baseline - Control Tower, SSO, and sensible guardrails - without a discovery workshop. We used it on a recent greenfield build and had SSO and baseline guardrails live in an afternoon. The entire decision tree is a public repo you can read end to end before you commit to anything.

I'm generally a fan of opinionated tooling. If there is a sensible default, I'd rather spend engineering time building product than debating OU structures. If I were founding again tomorrow with a blank AWS org, I'd run Superwerker before I spent a day on account design.

Greenfield teams don't fail because their landing zone wasn't migration-aware. They fail because they never got a baseline and spent months refactoring after the event.

Transform: a different problem

Transform's agent is a different shape of tool entirely. It's not a standalone landing zone builder - it's embedded in AWS Transform's end-to-end migration workflow. Transform gathers information about your organisation, migration waves, compliance requirements and account structure before proposing a landing zone. That's a fundamentally different problem from "deploy me a sensible default."

Where Forge sits

Forge deliberately stops at the landing zone boundary. That's infrastructure governance, and every organisation has different requirements. Once that foundation exists - whether it came from Superwerker, AWS Transform or something else - that's where Forge starts.

A working rule of thumb

• Greenfield startup? Use Superwerker.
• Enterprise migration? Look seriously at AWS Transform.
• Brownfield AWS estate? Use judgement.

Every organisation carries different history and constraints. I haven't used Transform yet, so I'd genuinely like to hear from teams that have. I'm much more interested in where this rule breaks down than where it holds.