What Is AI Migration? Can Enterprises Migrate AI Like Cloud Workloads?

Enterprises are adopting AI faster than they are documenting how it works. A team may start with a model API, then add prompts, retrieval, memory, connectors, scheduled jobs and approval steps until an AI-assisted task becomes part of day-to-day operations.

The manual handoff is only the beginning

At an individual level, people already practice a rough form of AI migration: export a conversation history, summarize the context, write a handoff or SKILL.md file, then move that material to another AI. If the new system can continue the work and follow the same process, it feels as if the AI has moved.

But what actually moved? A handoff can carry context that has been written down, and a skill can package a procedure. Neither automatically transfers native memory, live session state, tool permissions, connector configuration, scheduled tasks, audit history or behavior shaped by the original model and runtime.

At enterprise scale, the thing being migrated is rarely just a model. It is an AI workload: behavior to reproduce, knowledge to preserve, tools to reconnect, memory to classify, workflow and state to continue, governance to maintain, economics to remeasure, and the business outcome to revalidate. Migration is successful only when the target re-establishes the required outcome, authority boundaries and controls. This is where AI migration meets AI architecture. When those components are externalized, versioned and observable, changing a model or runtime becomes a managed architectural decision rather than an emergency effort to recover context and process.

What is being migrated?

A cloud migration often moves application components, data and infrastructure. An AI migration must also preserve or deliberately re-create behavior under specific constraints. There is no checksum for an AI workload’s behavior: the target has to pass evaluation and business acceptance, not merely receive copied files.

The migration unit may be a model endpoint, an AI feature, a retrieval-augmented generation (RAG) application, an agent, a multi-agent workflow, scheduled automations, or the way a team works with AI. Calling all of these simply “the model” hides dependencies that can determine whether the change is safe.

Model migration

This is the narrowest scope: replace one model or endpoint while keeping the application and workflow mostly intact. Even then, instruction following, tool calls, structured output, context handling, safety behavior, latency and cost can change. A matching API shape does not guarantee matching behavior. The AWS Transform changelog lists a model-to-model migration custom transformation for generative AI workloads. That is a specific model-level capability, not evidence that an entire enterprise AI workload - including its memory, permissions, workflow state, evaluations and operational controls - moves with it. Source: AWS Transform changelog.

AI application migration

Moving a chatbot, RAG system, document pipeline or AI feature involves more than the model. Embeddings, vector indexes, retrieval logic, prompt templates, filters, logging, data-residency rules and integration with the existing application may all need adaptation.

Agent migration

An agent may read data, choose an action, call a tool, write to a business system and wait for human approval. Its migration scope therefore includes instructions and skills, tools and API contracts, identity and permissions, knowledge and retrieval, short- and long-term memory, workflow state, scheduled tasks, approval points, audit trails, failure handling and idempotency.

Human–AI operating context

Over time, a team develops a way of working with AI: decision history, quality expectations, exceptions, review habits and delegated authority. Some of that context is documented; some lives in platform memory or in one employee’s working habits. A platform change can therefore affect the organization’s operating context, not only its data.

Interoperability is not the same as migration

MCP, A2A and Agent Skills are useful building blocks, but each addresses a different boundary. Interoperability means systems can communicate. Portability means a capability can run elsewhere with acceptable adaptation. Migration also requires discovery, adaptation, validation, cutover, rollback and post-cutover operations. From TitanBases’ perspective, there is not yet a single broadly adopted end-to-end AI migration playbook comparable in maturity to established cloud migration practice. That is a statement about the current state of practice, not a claim that no research, vendor tools or partial approaches exist.

MCP: a more consistent tool and resource connection

The Model Context Protocol (MCP) defines how AI application hosts connect to server-provided tools, resources and prompts through clients. This can reduce bespoke integration work at the tool boundary. MCP focuses on protocol-level context exchange; it does not decide how an application uses an LLM or transfer an agent’s memory, business policy, workflow state, evaluation baseline or provider-specific behavior. Source: MCP Architecture overview.

A2A: agents can collaborate without becoming portable

The Agent2Agent (A2A) Protocol is an open standard for communication and collaboration between AI agents built with different implementations. Its documented request lifecycle covers agent discovery, authentication and messaging. A2A can support interoperability without exposing every agent’s internal memory, tools or proprietary logic. That does not make an agent portable or move its state, permissions and operating controls. Source: A2A request lifecycle (official documentation, Linux Foundation project).

Agent Skills: reusable procedures still need runtime checks

Agent Skills make reusable procedures easier to package and share. The current Claude Code documentation describes a skill as a SKILL.md file containing instructions and allows supporting files. Yet a skill can still depend on runtime extensions, available tools, permission models and model-specific interpretation. Treat it as a migration artifact to test, not proof that the whole workload is portable. Source: Claude Code Skills documentation.

A simple way to keep the terms straight: interoperability is the ability to communicate; portability is the ability to run elsewhere with acceptable changes; migration is the controlled process of moving and validating the workload end to end.

A practical AI migration framework

Cloud migration practice offers a useful comparison, not a ready-made AI playbook. AWS Prescriptive Guidance describes seven migration strategies for applications: Retire, Retain, Rehost, Relocate, Repurchase, Replatform and Refactor or Re-architect. AI workloads need additional decisions because behavior, data access, tools and operating controls are part of what must continue. Source: AWS migration strategies.

1. Discover the workload and its dependencies

Start with the business task, not the model name. Identify the outcome, owner, users, inputs, outputs and downstream systems. Then inventory model and version, prompts, skills, knowledge stores, vector indexes, tools, connectors, identities, permissions, scheduled jobs, workflow state, evaluations, telemetry and failure paths. A dependency that cannot be explained is a migration risk, not a detail to defer.

2. Map the current-state boundaries

Record data sources and direction, read/write boundaries, the identity used by each action, human approval points, state stores, audit evidence, provider-specific capabilities and rollback paths. Verify configuration against runtime logs: source code may contain unused integrations, while a platform connector may be invisible in the repository.

3. Establish a behavioral baseline

Build a representative evaluation set before changing the source system. Include ordinary cases, missing and conflicting information, unsafe requests, permission failures, provider errors, duplicate actions and cases requiring human review. Behavioral parity is not byte-for-byte output equality: different models may use different wording while still preserving the behavior, constraints and outcomes that matter.

Separate deterministic checks from semantic or probabilistic evaluation. Deterministic checks cover schema validity, structured-output compliance, function and tool-contract correctness, required fields, authorization, prohibited actions, side-effect constraints, and latency or reliability ceilings where appropriate.

Semantic evaluation covers task success, groundedness, answer relevance, domain correctness, safety behavior, policy adherence, retrieval quality and behavioral consistency. Use deterministic assertions, reference-based evaluation, task-specific metrics, semantic similarity where appropriate, human review and calibrated model-based graders. Model-based graders can be useful, but must be calibrated against human judgment.

Record the baselines, acceptance gates and evidence in AWMM; a target is accepted only when it passes the agreed gates, not simply because its outputs look plausible. For governance context, NIST AI RMF 1.0 organizes risk-management work around Govern, Map, Measure and Manage. It is a risk-management framework, not an AI migration framework, so use it to inform governance and evaluation rather than as a migration method. Source: NIST AI RMF Core, Figure 5.

4. Externalize the assets that should survive

Move critical instructions into versioned files, define tool contracts, keep knowledge in governed stores, describe memory with an explicit schema, represent workflows as state machines where possible, and maintain repeatable evaluations. Keep secrets in a secrets manager and record references only. A SKILL.md can package a procedure, but it cannot replace identity, dependency mapping, permissions, state, evaluations or evidence.

A proposed portability package might include a manifest, instructions, skills, workflow definitions, tool contracts, knowledge and memory manifests, policies, evaluations, a source-to-target mapping and a rollback plan. This is a TitanBases architectural proposal, not an industry standard.

5. Prepare the target environment before moving workloads

An AI landing zone is not merely infrastructure. It establishes stable operational boundaries into which migrated workloads can be introduced and validated.

In this practical TitanBases architecture view, four control planes matter: Identity & Policy (workload identity, user/service authorization, permissions and policy enforcement); Model & Orchestration (model routing, model gateway, orchestration and runtime controls); Context & Data (RAG, memory, retrieval, data boundaries and provenance); and Operations & Assurance (observability, evaluations, guardrails, reliability, cost and incident controls).

Before workloads arrive, establish a model gateway or routing layer; least-privilege tool access; secret management; knowledge boundaries; prompt and skill versioning; logging and tracing; evaluation; cost attribution; human approval; retention; incident handling; fallback and rollback; an approved model/provider catalog; and policy enforcement.

This is a TitanBases-proposed architectural concept, not a formal standard. Do not move an agent into a runtime until the target can control what it may read, write and delegate. Otherwise, the organization may exchange vendor lock-in for operational risk.

6. Choose a strategy per workload

A practical TitanBases taxonomy can help frame the decision: retain a workload that has no safe or justified target; retire one that no longer creates value; repoint an application to a different model endpoint; rebind an agent to new tools, identity and knowledge; replatform it to a different managed runtime; reconstruct memory, skills or controls that cannot be transferred; or re-architect it to reduce avoidable coupling. These labels are a proposed working vocabulary, not an official migration standard. A portfolio can use several approaches at once.

7. Migrate in waves, from low risk to stateful

A sensible sequence is to begin with stateless summarization, classification, drafting or extraction that has no memory and no write-capable tools. Next move knowledge-grounded RAG or search and validate retrieval quality, citations, access control and index freshness. Then migrate tool-using agents with explicit permission checks and human approvals. Move stateful or scheduled agents last, after state snapshots, idempotency, pending-task handling and rollback have been exercised.

8. Treat memory and operational state as separate workstreams

Classify context before moving it. Knowledge, user preference, business facts, historical decisions, episodic memory and evidence have different owners, sensitivity and retention rules. Decide whether each item must migrate, may migrate, must be revalidated, must expire or must not migrate. Operational state—pending approvals, task status, cursors, retry counts and idempotency keys—should come from the system of record, not a chat summary.

Migrating RAG or vector-backed memory is not simply copying vectors. Changes in embedding model or dimensionality, chunking, normalization, metadata schema, namespace or tenant boundaries, index configuration, similarity metric, hybrid search, reranking, source-document provenance and retention or deletion policies may require re-embedding.

Test data portability (can documents, memory records and metadata be exported?), representation portability (can the target consume the same representation?), and behavioral portability (does retrieval still surface sufficiently equivalent evidence?). Run retrieval regression tests for recall and relevance on known queries, critical-document retrieval, citation and source correctness, tenant and permission boundaries, latency and failure cases. In AWMM, record these as assets, transformations, baselines, acceptance gates and evidence. A copied index is not proof of behavioral equivalence.

For write-capable agents, runtime rollback does not automatically reverse external side effects: database writes, CRM changes, tickets, provisioning, emails, financial actions and third-party API operations require stable operation identifiers or idempotency keys, durable operation state, and sometimes compensating actions.

Before cutover, drain, transfer, reconcile or explicitly abandon pending writes, queued actions, unresolved executions, scheduled jobs, external side effects and partially completed workflows. Unknown or high-risk state must be escalated to human exception handling rather than guessed.

9. Replay and compare before cutover

Run the target against the approved evaluation set. Where safe, use shadow traffic or parallel execution without allowing duplicate writes. Compare business outcomes, evidence quality, permissions, safety behavior, tool selection, failure handling, latency and cost. Investigate regressions instead of hiding them in an aggregate score. Keep human review for actions whose risk requires it.

10. Cut over with a rollback window

Define an explicit cutover owner, state-freeze or reconciliation plan, canary scope, success thresholds, monitoring window and rollback trigger. Prevent both systems from executing the same side effect. Preserve source logs and state until the target is accepted. A plan to switch back is not a rollback plan unless data and pending work can be reconciled safely. For write-capable agents, also define transaction boundaries, idempotency, compensating actions, approval for high-impact operations, immutable audit records, a kill switch and a safe degraded mode.

11. Operate and keep evaluating

After cutover, operate the target as a production workload—not as a completed project. Watch five signal groups: quality and behavioral drift; model or version changes; tool-call and retrieval failures; permission denials, policy violations and human overrides; and reliability, latency, token usage and cost per successful outcome. Keep versions of models, instructions, skills, policies, tools and evaluation sets. Investigate regressions at the scenario level, preserve the audit trail, and update the baseline when an approved business change is intentional. Migration ends only when the target is accepted, observable and operable.

What teams can prepare before a migration is scheduled

Worked example — hypothetical stateful support agent migration

Consider a stateful enterprise customer-support agent moving from Runtime A to Runtime B. Its workload includes core instructions; Agent Skills or equivalent procedural assets; MCP-connected tools; vector-backed knowledge; durable conversation and task memory; CRM write permissions; scheduled follow-ups; enterprise identity; observability; and an evaluation suite. This is an illustrative architecture example, not a TitanBases customer case.

Migration treatment: core instructions are portable but require validation; skills are portable where supported; MCP tool bindings must be rebound and contract-tested; a vector index may need rebuild or re-embedding when its representation changes; durable memory must be transformed and validated; permissions require explicit remapping and least-privilege review; scheduled jobs must be reconstructed or transferred safely; pending writes must be reconciled before cutover; the evaluation suite is preserved as the baseline; runtime-specific state is transformed, reconstructed or retired.

Illustrative acceptance gates—not universal thresholds—include: the approved critical-scenario pass rate meets its baseline; required tool-contract tests pass; no unauthorized permission expansion occurs; critical retrieval and memory scenarios pass; zero unresolved duplicate side effects remain; and the rollback procedure succeeds in a controlled test. The purpose is to make acceptance reviewable, not to claim a universal score.

Build an AI Workload Readiness Pack

A chat dump, HANDOFF.md or SKILL.md can preserve a slice of context or procedure. None is the whole workload. A useful starter pack can be maintained in ordinary documents and spreadsheets; exact file formats are optional. The minimum is an owner-verified record of what the workload does, how it should behave, what it depends on, what it can access, how success is evaluated and how it is operated.

Start with six owner-verified artifacts. The filenames below are examples, not mandatory formats.

• WORKLOAD.md - purpose, business and technical owners, users and expected outcome.
• BEHAVIOR.md - allowed, forbidden and approval-required behavior.
• DEPENDENCIES.yaml - models, data, tools, connectors, schedules and runtime assumptions.
• ACCESS-MATRIX.csv - identities, permissions, approval points and possible side effects.
• EVALS.jsonl - representative cases, expected outcomes and pass/fail conditions.
• RUNBOOK.md - how to operate, pause, recover, fall back and roll back.

Build the pack from evidence, not memory:

• Workload card - interview business and technical owners, users and operators. Record who depends on the output, where errors create real impact and who accepts the result.
• Behavior and policy - inspect approved instructions, policies, skills, tickets, change requests and recurring human corrections. Owners must confirm every rule.
• Dependencies - compare repositories, package locks, model identifiers, connector settings, workflow definitions, schedulers, cloud and AI consoles, data stores, monitoring destinations and runtime logs.
• Knowledge and memory - inventory documents, databases, object stores, indexes, platform memory, decision logs and pending workflow state. Record owner, sensitivity, access rules, freshness and retention.
• Permissions - verify IAM roles, service accounts, OAuth scopes, API permissions, connector settings, approval configuration and audit logs.
• Evaluations and operations - derive EVALS.jsonl from completed work, incidents, rejected outputs and failure cases. Build the runbook with the people who pause, resume and recover the workload.

Add MEMORY-REGISTER.csv and STATE-SCHEMA.md when the workload uses long-term memory or active workflows. HANDOFF.md should point to these governed records; SKILL.md can package a stable procedure. Neither replaces them. Each artifact should record its owner, evidence source, version and last review date. AI can organize a first draft, but people must verify it. Mark missing facts UNKNOWN or NEEDS REVIEW. Never guess access rights or workflow state, and never place passwords, API keys, tokens, secret values or customer data in the pack. Do not bulk-export conversations just in case.

Definition of ready

• Every artifact has an owner and review date.
• Important dependencies have supporting evidence.
• Secrets are absent and unknowns are explicit.
• Evaluations can be rerun.
• Actual permissions have been checked.
• Pending work has a source of truth.
• Another operator has tested the runbook.

If a colleague cannot take over without the creator standing beside them, the workload is not yet ready to move - and may not be ready to operate reliably.

From a migration framework to a machine-readable migration contract

The architecture principles in this framework are useful only if they can be made explicit, reviewable, and testable during a real migration.

To make that possible, TitanBases has initiated the AI Workload Migration Manifest (AWMM) — an open, vendor-neutral draft specification for describing and validating AI workload migration across runtimes.

AWMM does not replace interoperability protocols, agent packaging formats, or runtime-specific migration mechanisms. Instead, it defines the migration contract around them: what must move, what must be transformed or rebound, what may be lost, which risks must be controlled, what behavioral and operational baselines apply, which acceptance gates must pass, what evidence supports the result, and how rollback is handled.

The distinction is intentional:

• Interoperable does not mean portable.
• Portable does not mean migrated.
• Successfully imported does not mean behaviorally equivalent.

An AWMM manifest can describe instructions, skills, tools, models, memory, retrieval data, workflow state, identity, permissions, policies, secret references, observability, evaluation assets, dependencies, transformations, risks, baselines, acceptance gates, evidence, provenance, and rollback requirements.

AWMM is designed to coexist with technologies such as MCP, A2A, Agent Skills, durable-state formats, and runtime-specific migration systems rather than redefine them. Those technologies may solve individual interoperability or portability problems; AWMM describes how those pieces participate in a complete workload migration.

AWMM Draft Specification v0.1.0

The specification is intentionally published as a draft. TitanBases does not claim that AWMM is an industry standard or that a conforming manifest guarantees migration success. The purpose of the project is to make migration assumptions, gaps, acceptance criteria, and evidence explicit enough to be reviewed and improved in the open.

Frequently asked questions about AI migration

What is AI migration?

AI migration is the controlled process of moving or re-creating an AI workload on another model, provider, platform or agent runtime. It may include the model, instructions, knowledge, memory, tools, permissions, workflow state, evaluations and operational controls.

Is AI migration just switching a model or API endpoint?

No. Changing an endpoint is a narrow model migration, often called repointing in this article’s proposed vocabulary. The larger workload may also depend on knowledge, tools, memory, identity, policy, workflow state and production evaluation.

Can all conversation history and memory move to another AI?

Some information can be exported and re-shaped as context, governed knowledge or structured memory. Native platform memory, hidden runtime behavior, live session state and model interpretation usually cannot be transferred unchanged. Classify each item, verify its source and decide whether it should migrate, be revalidated, expire or be excluded.

Are SKILL.md or HANDOFF.md enough to migrate an agent?

No. They can preserve procedures, instructions and pointers to useful resources. They do not automatically transfer permissions, credentials, workflow state, scheduled jobs, native memory, audit history, dependencies or evaluation baselines.

Do MCP and A2A solve AI migration?

They help with interoperability at specific boundaries: MCP connects AI applications with tools and resources, while A2A supports communication between agents. Neither protocol by itself performs workload discovery, state migration, behavior validation, cutover or rollback.

How do we know an AI migration succeeded?

Do not judge success by whether two models produce identical text. The target must meet agreed business outcomes while preserving required permissions, safety controls, tool behavior and auditability within accepted quality, latency and cost thresholds. The evaluation set and business owner should define those thresholds before cutover.

When should an enterprise start preparing?

Start when a workload enters production or begins accumulating valuable knowledge and operating context. Inventory dependencies, establish an evaluation baseline and document an exit path before a provider change makes preparation urgent.

Conclusion: AI architecture needs a way out

The first wave of enterprise AI has rewarded speed: which model is stronger, which use case can be built quickly, and which team can put AI into work first. The next challenge is control. Once AI is part of a real process, organizations must be able to explain what it depends on, what it is allowed to do, how its outcomes are checked and what happens when the underlying model or platform changes.

AI migration is not proof that an AI project failed. It becomes relevant when the workload matters enough that the organization cannot afford to lose its knowledge, behavior or operating controls during a change. Teams that externalize and govern these assets can keep the capability they have built while replacing only the parts that need to change. If everything lives inside one platform, lock-in reaches beyond an API contract and into the way the organization works.

A mature question is not only “What is the newest model?” It is also “If we had to change this model or platform tomorrow, could we do so without losing the capability, context and control we rely on?” A sound AI architecture designs how a system starts, how it changes and how it can leave its current platform under control. The exit plan belongs at the beginning, not at the end of the lifecycle.

Planning an enterprise AI migration? TitanBases works with engineering teams on AI architecture, migration readiness, AI landing-zone design, evaluation, workload modernization and production deployment. Start by inventorying the workload, its dependencies and evaluation baseline before choosing a migration path.

Further reading and references

Cloud migration strategies (AWS Prescriptive Guidance)

MCP architecture (Model Context Protocol)

A2A overview and protocol concepts

Related TitanBases reading: AI orchestration layer

Related TitanBases reading: AI Architect skills