Migration & Adoption

Switching Clouds: Porting Claude Workloads Between Platforms

Moving a Claude workload from Bedrock to Vertex AI, or from either to Claude Platform on AWS, is far less dramatic than a typical cloud migration. Most of your code does not change — but four specific things do.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Companies switch Claude platforms for ordinary business reasons: a merger lands you on a different cloud, procurement negotiates a better committed-use deal elsewhere, or a feature you need — say, the Batch API — simply is not available where you started. The good news is that the same models run everywhere, and the official anthropic Python SDK was designed so that the code you wrote for one platform ports to another with minimal surgery. The prompt you spent months refining, the tool definitions, the streaming logic — all of that travels as-is.

What stays identical

The shape of every messages call is the same across all four platforms: Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. You pass the same message structure, the same system prompt, the same tool definitions, and you get back responses in the same format. Streaming, tool use, vision, extended and adaptive thinking, and prompt caching all work the same way, because they are core capabilities available on all four platforms. In practice, if your application logic is separated from client construction — one function that builds the client, everything else just calls it — a platform switch touches a handful of lines.

The four things that change

1. The client class. Each platform has its own client in the same SDK: AnthropicAWS() for Claude Platform on AWS, AnthropicBedrockMantle() for Bedrock, AnthropicVertex() for Vertex AI, and AnthropicFoundry() for Foundry. Swapping the class is usually a one-line change plus an install extra (for example pip install -U "anthropic[vertex]").

2. Authentication. This is where the real work lives, because it involves your platform team, not just your developers. Bedrock uses standard AWS credentials; Vertex AI uses GCP Application Default Credentials; Foundry uses a resource plus API key; Claude Platform on AWS uses AWS SigV4 signing with AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID environment variables. Budget time for IAM policies, service accounts, or key issuance on the destination platform.

3. Model IDs — but only for Bedrock. Bedrock prefixes model IDs with anthropic. (for example anthropic.claude-sonnet-5); every other platform uses the bare ID (claude-sonnet-5). If model IDs are hardcoded in your application rather than in configuration, moving to or from Bedrock is when you will discover that.

4. Feature availability. This is the item that can quietly break a migration plan, so it gets its own section below.

from anthropic import AnthropicVertex

# Was: AnthropicBedrockMantle(aws_region="us-east-1")
#      with model="anthropic.claude-sonnet-5"
client = AnthropicVertex(project_id="my-project", region="global")

response = client.messages.create(
    model="claude-sonnet-5",   # bare ID off Bedrock
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this contract."}],
)
print(response.content)

Check the feature gaps before you commit

Not every capability exists everywhere. The Batch API, Files API, code execution tool, and web fetch tool are not available on Bedrock or Vertex AI; they are available on Claude Platform on AWS and mostly in beta on Foundry. The web search tool is absent on Bedrock and only a basic variant exists on Vertex AI. Managed Agents exist only on the first-party API and Claude Platform on AWS. A workload that relies on overnight Batch processing, for example, cannot move to Bedrock without re-architecting that piece. Inventory which platform features your application actually calls before anyone signs the new agreement.

Rule of thumb: Keep the client class, model ID, and region in configuration, not code. A team that does this can stand up the same workload on a second platform in days; a team with hardcoded IDs and scattered client construction spends weeks finding them.

A practical migration checklist

First, inventory features: list every API capability you use and confirm it exists on the destination. Second, set up auth on the destination platform and make one successful call from a scratch script before touching production code. Third, swap the client class and model IDs behind your configuration layer. Fourth, rerun your evaluation suite — same prompts, same expected behaviors — to confirm output quality is unchanged; the models are the same, but this is cheap insurance and catches configuration mistakes. Fifth, run both platforms in parallel for a bounded period, routing a small share of traffic to the new one, then cut over. Finally, revisit quotas and cost alerts on the destination — limits you raised on the old platform do not follow you.

Where to go next

If you have not yet picked a destination, the feature gaps article covers exactly what Bedrock and Vertex AI do not support, and the multi-cloud strategy article weighs whether running two platforms permanently is worth it. The feature matrix on the main guide is the quick-reference version.