AWS Transform

You will not use this daily and that is the point. It is scoped to migrations: mainframe estates, framework upgrades, containerising an application onto a managed cluster, and planning the waves for a server fleet. The deciding trait is that narrowness, because a general agent turned loose on forty-year-old code produces confident nonsense and this one at least knows which problem it was built for.

Pick it when modernisation is a funded programme with a deadline. Pick Amazon Q Developer for the code you write on a normal Tuesday, which this service will never see.

The dangerous failure here is not a crash. Translated code that compiles and runs while computing a slightly different answer is the characteristic defect of automated modernisation, and it surfaces in a quarterly reconciliation rather than a test run. The user guide describes discovery, planning and conversion; it does not describe how correctness of the converted behaviour is established, which leaves that burden entirely on the customer.

What it does right: the scope is named workloads and named source languages rather than a promise about any code, which is an unusually disciplined claim for this category.

1. The decomposition is by domain rather than by task: distinct agents for mainframe estates, framework conversion, containerisation and fleet planning, each carrying its own assumptions about the source material. That is a defensible way to bound a hard problem. 2. Context is the customer's estate, gathered through a discovery phase, which is the correct order of operations.

No model is named beyond the managed inference platform, and no benchmark or accuracy figure is published for any workload. The observation: a service that will rewrite a bank's core cannot be evaluated before you buy it, and nothing in the documentation acknowledges that.

The commercial logic is close to perfect for the seller. Modernisation moves estates onto their own infrastructure, the work is billed inside an account relationship that already exists, and nobody churns off a migration halfway through. Pricing power is therefore near total, which is presumably why the rate card was not legible when this row was recorded.

There is no acquirer and no pivot to model here; the only risk is the service being folded into another product line, which happens to a third of them. Position: the vendor risk is zero and the negotiating leverage is also zero, so price the engagement, not the tool.

One sentence on the demo: it does the work no engineer volunteers for. Procurement is the easy part, because there is no new vendor, no new agreement and no new security review; the controls come from the account and the console, which our team already administers. What it does not do is fit our engineering workflow at all, since it is a console-driven programme rather than something that runs on our pipelines.

Onboarding is a project plan, not a training session. Approved with conditions: scoped to one wave, with a named owner and a spend alarm.

There is nothing here for me. I cannot supply a key, cannot point it at my own hardware, cannot attach my own tool servers, and cannot script the thing from a shell, because the documented way in is a console job. The models are unnamed and unswappable. If it does something wrong I file a ticket and wait, which is the opposite of every reason I do this work.

The grudging admission is that none of this is a mistake. Nobody modernises a mainframe on a laptop, and a service touching a regulated estate was never going to hand me a config file. It is a contract, not a tool.