Migrating Bedrock Agents Classic to AgentCore: A UK Enterprise Playbook

Why this migration is on the clock

Amazon Bedrock Agents (launched 2023) is now branded Amazon Bedrock Agents Classic. AWS has stated Classic will no longer be open to new customers from 30 July 2026, and the recommended destination for agent workloads is Amazon Bedrock AgentCore.

If your UK estate already runs Classic agents with Lambda action groups and CloudFormation, you need a migration plan — not another proof-of-concept. This article is a practical playbook: what changes, what stays, and how to move without a big-bang outage.

Classic vs AgentCore (in one table)

AgentCore gives two paths:

1. Harness — declare model, tools and instructions; closest to Classic's managed feel.
2. Code-defined — deploy Strands/LangGraph/custom agents on AgentCore Runtime when you need multi-agent patterns or custom orchestration.

A UK-safe migration sequence

1. Inventory before you rewrite

For each Classic agent, capture:

• System prompt and guardrail IDs
• Knowledge Bases / RAG attachments
• Action group APIs and IAM roles
• Invocation clients (API Gateway, Step Functions, internal apps)
• Data classification (customer PII, payment, HR)

Priority = production traffic × blast radius × Classic-only dependency.

2. Choose harness vs code-defined

• Harness if the agent is mostly instruction + a handful of tools and you want config-first ops.
• Code-defined (Strands recommended for Classic-like behaviour) if you already customise orchestration, need supervisor patterns, or want Git-reviewed Python.

AWS documentation and the Agent Toolkit migration skill can import Classic agent IDs into a scaffolded project (agentcore create --type import ... --framework Strands). Treat that as a starting point — always review generated IAM and prompts.

3. Re-home tools behind Gateway where it pays off

Lambda action groups that are really "enterprise tools" belong behind AgentCore Gateway as MCP tools so the next agent can reuse them with Cedar-based access control. Keep one-off glue as local @tool functions.

4. Dual-run, then cut over

1. Deploy AgentCore Runtime beside Classic.
2. Shadow traffic or canary a low-risk cohort.
3. Compare tool call success, latency, and wrong-action rate.
4. Point clients at Runtime invoke APIs; keep Classic as fallback for a defined window.
5. Decommission Classic only after stability criteria are met (not after the first green demo).

5. UK compliance checklist

• Map AgentCore CloudWatch/observability streams into your SIEM
• Re-attest IAM least privilege (Runtime role ≠ "admin for convenience")
• Confirm Knowledge Base citations still meet your generative-AI policy
• Update DPIA / AI risk register entries for the new runtime boundary
• Align change records with ITIL windows on production agents

What usually breaks (and how to avoid it)

• Prompt drift — Classic orchestration formatting ≠ Strands/LangGraph; retune system prompts with golden dialogues.
• KB assumptions — some Classic knowledge attachments need explicit retrieval wiring after import.
• Custom orchestration — return-of-control / custom Lambda orchestrators must be rebuilt as framework-native graphs or tool chains.
• Client SDKs — callers must switch to AgentCore Runtime invoke patterns (SigV4 / JWT as designed); leave Classic aliases live until clients are updated.

30-day starter plan

Week 1 — Inventory + pick one non-critical production agent.
Week 2 — Import/scaffold on AgentCore; wire tools; add eval set of 30 real prompts.
Week 3 — Dual-run; fix IAM and prompt regressions.
Week 4 — Cut over that agent; document the pattern for the next five.

Bottom line

Agents Classic maintenance mode is a calendar problem as much as a technology one. UK teams that standardise on AgentCore Runtime + clear tool ownership (Gateway/MCP) will spend less time babysitting per-agent plumbing and more time on evaluation quality.

Do not wait for July 2026 pressure. Migrate one real agent this month, prove dual-run discipline, then industrialise the pattern across your Classic estate.