AWS Transform: Which Interface Fits Your Migration Team

AWS Transform now gives a migration team four ways into the same workspace: a browser console, an IDE, a command line and MCP. Choosing between them is less about which one is "right" and more about who is doing what on the project that day. Here is how to match them to the people on your migration, and what to check about data residency before a South African team starts.

On 9 October 2026, AWS published a guide to the AWS Transform interfaces on its Migration & Modernization blog. Its scenario will be familiar to anyone who has run a migration programme: dozens of applications, several teams, a mix of .NET services and older monoliths, and leadership asking for a status update every week. The guide's central point is simple. Every interface reads and writes the same workspace, so job history, context and artefacts follow the work from one surface to the next. You are choosing a form factor for a task, not locking the project into a tool.

That matters because a migration is not one kind of work. It is set-up and access control, then planning, then hands-on change to code and servers, then repetition at scale. Each stage has a different owner, and each owner works best in a different place.

Which AWS Transform interface should each role use?

Interface	Best for	Who usually uses it	Typical task
Console	Getting oriented, setting up, tracking progress	Platform engineers, tech leads, stakeholders	Creating a workspace, assigning roles, approving tasks, building a wave plan
Kiro (or another IDE)	Hands-on transformation work	Developers	Modernising a .NET application to run on Linux, reviewing changes inline
CLI	Repeatable, scripted runs	Developers and platform engineers who automate	Running the same Custom transformation across many services, or inside a CI/CD pipeline
MCP	Combining Transform with other tools	Operations engineers, teams using AI assistants	Building Transform into a wider, multi-tool workflow

Console: where the programme is run

The console is the browser view of the workspace. It is where a platform engineer creates the workspace, connects source repositories and assigns roles such as Approver and Contributor. It is also where a tech lead approves tasks that are waiting on a human decision and checks how many applications are in flight. For infrastructure work, the AWS guide gives the example of an engineer mapping VMware virtual machines and physical servers to Amazon EC2 instances and containers while building a migration wave plan. If you are the person reporting progress on a Friday, this is your view.

Kiro and other IDEs: where the code changes

For developers, the Transform agent sits inside the IDE, next to the code, terminal and file tree. AWS names Kiro, and the guide also lists Claude Code, Codex and Cursor as options. The example is a developer taking a .NET application to cross-platform .NET that runs on Linux, through analysis, transformation and validation, without leaving the editor. This is the right place for work where a person needs to read each suggestion, push back on the approach and own the result.

CLI: where repetition becomes a script

The command line is for deterministic, repeatable runs: batch jobs, bulk changes and CI/CD pipelines. It can run interactively or fully autonomously. The AWS example runs atx custom transform with non-interactive flags to apply one transformation across 12 microservices. One limit to note: the guide says the CLI handles Custom transformations only, while the console, the IDE route and MCP can each run transformations end to end for any workload type.

MCP: where Transform joins a bigger workflow

MCP is the protocol layer that lets AI tools combine Transform with other tools, and it also sits underneath the IDE integrations. It suits an operations team that wants migration jobs to be one step in a larger, automated process rather than a separate console to watch.

Pick the interface for the task in front of you. The workspace, not the tool, is what keeps the project together.

AWS Transform data residency in South Africa: what to check first

The interface question is the easy one. For a South African organisation, the question that deserves more time is where your data sits and travels while the work happens. AWS's own documentation answers most of it, and a few points are worth putting in front of your information officer before anyone connects a repository.

The workspace does not run in Cape Town

According to the AWS Transform supported Regions page, workspaces can be created in US East (N. Virginia), Europe (Frankfurt), Europe (London), Asia Pacific (Mumbai), Sydney, Tokyo, Seoul and Canada (Central), with São Paulo available for mainframe agents only. Africa (Cape Town) is not on that list. AWS's data protection page says your data is stored in the Region where your AWS Transform profile was created, and that it includes your questions, the responses and context such as console metadata and code in your IDE. So the Region you choose for the workspace is a decision about where that material is kept.

Your migrated workloads can land in Cape Town

The workspace Region and the target Region are separate. On 22 June 2026, AWS announced that AWS Transform for migrations supports all commercial Regions as migration targets, and Africa (Cape Town) is among the 16 Regions that announcement added. AWS frames the change around data residency requirements. The target account documentation adds two details worth knowing: when the target Region differs from the workspace Region, some of your data is transferred across Regions, and server replication data goes directly from your source environment to your target account and Region.

Inference can be processed outside the workspace Region

AWS Transform is powered by Amazon Bedrock and uses cross-Region inference. The cross-Region processing page lists where requests can be routed, and the answer differs by capability. For Transform for migrations, requests from a Frankfurt or London workspace may be routed to all commercial Regions. For Custom transformations, the same workspaces route within European Regions. Separately, general questions about AWS may be answered by calls to Frankfurt, and an administrator can switch that off in settings.

Content may be used for service improvement unless you opt out

AWS's service improvement page says questions, responses and generated code may be used to improve the service, including for model training. The opt-out is an AI services opt-out policy in AWS Organizations. If your source code or configuration contains anything sensitive, set this before the first job runs.

None of this rules AWS Transform out for a POPIA-conscious organisation. It means the decision about where personal information and source code may go should be made deliberately, and written down, rather than discovered after the fact.

A short pre-flight checklist

1. Choose the workspace Region on purpose. Record why, and which data will be stored there.
2. Set the target Region per job. AWS's migration jobs page allows one target Region per job, so if workloads need to land in af-south-1, check every job is configured that way.
3. Review cross-Region processing for each capability you plan to use. Migrations, Custom transformations and mainframe work route differently.
4. Apply the AI services opt-out policy if your organisation does not want its content used for service improvement.
5. Assign roles before work starts. Decide who can approve tasks in the console, so human checkpoints do not stall a wave.
6. Agree which interface each team uses. Console for the programme lead, IDE for developers, CLI for anything repeated more than a few times.

The tool speeds up the work. It does not make the plan.

AWS Transform can take on a lot of the repetitive effort in a migration, but the decisions that make a migration go well still sit with people: which applications move first, what the landing zone looks like before anything arrives, how each wave is tested, and how you roll back if a cutover misbehaves. That is the order of work on our Cloud Migration page: assess the estate and its dependencies, build a Well-Architected landing zone first, migrate in validated waves with rollback at every step, then keep optimising after go-live.

The planning matters even on a deadline. When BizzCo was given 15 days to move its Moodle environment out of an on-premise data centre, the work still started with a Well-Architected Landing Zone, with the application on Amazon EC2 and the database on Amazon RDS inside a VPC. A tool that writes the transformation faster is most useful when that foundation is already decided.

If the bigger task is the code rather than the servers, such as breaking up a monolith or moving .NET services off Windows, the approach on our Serverless Modernization page applies: modernise one domain at a time and validate each slice against the old path before it takes over.

Where to start

If you are weighing up AWS Transform for a migration, or deciding which Region your workloads should land in, a discovery session is a sensible first step. We map your estate and its dependencies, and build a migration plan that fits your timeline and budget. You can request one through our contact page, or read more about how we approach it on the Cloud Migration page.