The decision an architect makes today commits the organization to a platform for the next 18-36 months. The decision the architect makes about that decision commits the organization to the cost of moving off that platform when the situation changes. Most architects model the first decision carefully and ignore the second one entirely. They build the buy-vs-build math. They build the TCO. They sign the contract. And then in month 19 the vendor raises prices 50%, the agent quality stalls, the strategic context shifts, or the business unit is acquired — and the team discovers that migration is a six-month project costing 30-50% of the original build. The premium for not modeling exit cost is the difference between leveraged renegotiation and a forced march. This lesson is the migration cost model. Three big drivers — prompt rewrites, tool re-wrapping, eval set rebinding — and the lock-in premium math you bake into the original choice so that "we'll figure out migration later" never becomes "we cannot leave."

Why the Migration Cost Is the Decision You Are Already Making

When you choose a platform today, you are also implicitly choosing a migration cost tomorrow. Every line of platform-specific configuration, every proprietary prompt format, every wrapped tool that only runs in the vendor's runtime, every test case that only validates inside the vendor's eval tooling — each is a unit of switching cost being silently built. By month 12 you have a meaningful pile of these units. By month 24 the pile is the program.

The result: in year 3 when the vendor renegotiates, they know exactly what your migration cost is (the vendor's customer success team builds spreadsheets of "stickiness" by customer). You probably do not, because you never modeled it. The negotiation is over before it starts.

The remedy is to bake migration cost into the original choice and refresh it quarterly. You do not need a perfect migration plan; you need a credible estimate. A credible estimate gives you renewal leverage. The absence of one gives the leverage to the vendor.

The vendor knows your migration cost. The vendor's customer success team models it explicitly. Most architects do not. The asymmetry is structural; the negotiation outcome follows the asymmetry.

The Three Migration Cost Drivers

Migration cost for an agent program decomposes cleanly into three drivers. They are not equal in size; they vary in shape per platform. But these three account for 85%+ of migration cost on every program we have seen in production.

Driver 1: Prompt rewrites

Every prompt your team has built, refined, and tested in the source platform has to be rewritten in the target platform. The reason it is not "copy/paste" is that prompts are bound to the platform's structures. An Agentforce Topic has a specific shape; the Instructions reference Salesforce-native concepts; the prompt depends on the available Actions (which are themselves platform-specific). A Copilot Studio Topic uses Power Fx expressions in its trigger phrases, generative answers wired to specific knowledge sources, and the underlying orchestrator's routing logic. Neither ports cleanly to the other or to a horizontal stack.

For each prompt, the work is roughly: read source, understand the intent, identify dependencies (tools, data, downstream prompts), rewrite for the target's prompting style, re-test against the eval set, debug platform-specific behaviors. Junior teams underestimate this work by 60%; senior teams underestimate it by 30%.

Driver 2: Tool re-wrapping

Every tool the agent can call has to be re-wrapped for the target platform's tool-calling contract. Agentforce Actions implemented as Flows or Apex methods do not run anywhere else. Copilot Studio actions implemented as Power Automate flows or custom connectors do not run anywhere else. The underlying business logic may be reusable (if the action calls a downstream API the logic survives), but the platform-specific wrapper does not.

The mitigation that reduces this driver — covered in lesson 1.3.6 — is MCP servers. If the original implementation uses MCP, much of the tool surface ports. If the original implementation uses platform-native action constructs, re-wrapping is full-rebuild. The choice you made in year 1 about MCP vs platform-native tools determines the migration cost.

Driver 3: Eval set rebinding

Eval sets are bound to the platform that runs them. Braintrust eval sets reference Braintrust dataset IDs, scoring functions, judge prompts. Agentforce Testing Center test suites reference specific Topics, Instructions, expected Action invocations. Copilot Studio's Application Insights traces produce platform-specific signal. Moving an eval suite from one platform to another involves: re-authoring the test inputs in the target's format, re-implementing the scoring logic, re-running the cases to calibrate the new platform's outputs against the test expectations, and rebuilding the judge prompts to match the new agent's outputs.

For mature eval suites (200+ test cases, 4-layer recipe — covered in lesson 3.5.2), this is meaningful work. For thin eval suites, less so. The architect who under-invested in eval has a smaller migration in this category and a much larger production risk during the migration.

The Migration Cost Model

The model. For each of the three drivers, estimate engineering days, multiply by loaded daily rate, add platform/tooling cost, add risk-adjusted production-disruption cost during the migration window.

Step 1: Inventory the assets

• Number of prompts (topics, instructions, system prompts)
• Number of tools (actions, flows, custom connectors, API wrappers)
• Number of eval cases (golden, edge, adversarial)
• Number of integrations to external systems
• Number of users / consumers depending on the agent

Step 2: Estimate per-asset migration days

• Prompts: 0.5-2 days each depending on complexity and dependency depth. A simple FAQ-style prompt is half a day. A multi-step orchestrator prompt with branching logic is two days.
• Tools: 1-5 days each. MCP-wrapped tools are 1-2 days (mostly retest). Platform-native Action rebuilds are 3-5 days each.
• Eval cases: 0.2-0.5 days per case for the suite as a whole, plus 5-15 days for the scoring framework rebind.
• Integrations: 5-20 days each to re-establish in the new platform.
• User impact: training, communication, rollback plan. ~10-30 days of cross-functional coordination.

Step 3: Multiply, sum, add overhead

Worked example. An agent with 40 prompts, 25 tools (15 MCP-wrapped, 10 platform-native), 200 eval cases, 6 external integrations. Engineering days: 40 prompts x 1 day = 40. Tools: 15 MCP x 1.5 days + 10 native x 4 days = 62.5. Eval: 200 x 0.3 days + 10 days framework = 70. Integrations: 6 x 10 days = 60. User impact: 20 days. Total engineering days: 252.5. Loaded daily rate $1,200: $303,000 engineering. Add platform license overlap during migration (3 months running parallel): ~$200K-$400K depending on the source and target platforms. Add risk-adjusted production disruption cost (~$50K-$200K depending on the rollback plan). Round number: $600K-$900K migration cost for a department-scale agent.

That is the number you should be tracking from month 1. Compare it to the cost of staying on the platform through year-3 renewal at the inevitable 30-60% price increase. If migration cost is $700K and renewal price increase is $400K/year x 3 years = $1.2M, the migration breaks even in 18-24 months. The architect runs that math and walks into the renewal meeting with options.

The Lock-In Premium: The Number to Bake into the Original Choice

The lock-in premium is the discount you should demand on a platform to compensate for its migration cost. It is the architect's leverage tool at the original procurement.

How to calculate it

Lock-in premium = (Estimated migration cost / 36 months) / (estimated annual platform cost). For the worked agent: ($700K / 36) / ($1.34M) = $19.4K/$1.34M = 1.45% per month of platform cost in implied lock-in tax.

Multiply by the term of the contract. A 3-year contract is 36 months. 1.45%/month x 36 months = 52% implied lock-in premium over the contract life. That is the amount of value you are paying for in switching cost that you cannot easily recover.

How to use it

You do not actually demand a 52% discount at procurement; the vendor will refuse. You use the number to negotiate for things that reduce your migration cost:

• Multi-year price guarantees (caps on the year-3 jump)
• Migration-credit clauses (vendor commits to fund engineering days if you migrate)
• Right-to-port data (eval sets, prompts in exportable format)
• SLA penalties that include a no-fault migration off-ramp
• MCP-first commitments from the vendor (reduces tool re-wrapping cost)

The negotiation. You walk in with the migration cost number ($700K) and the renewal jump scenario ($400K/year x 3 years = $1.2M). You ask for either price stability through year 3 or a migration credit at renewal. Vendors who want a long-term customer will discuss this. Vendors who refuse are telling you something about how the year-3 conversation will go.

When Migration Actually Happens: Five Scenarios

Migration is not theoretical. It happens. The five scenarios that drive most migrations in 2026.

Scenario 1: Vendor price increase

Sierra raises your renewal 60%. Decagon raises it 45%. Agentforce wants you to expand to Data Cloud Pro. The price-driven migration is the most common. The math is clear: if migration cost is less than 24-30 months of price increase, migration is rational.

Scenario 2: Quality stagnation

The vendor's agent quality plateaus. Other vendors ship faster. Your team's eval shows the gap widening. By month 18 the agent is measurably worse than the alternative. Quality-driven migration is rarer but more politically charged — the business unit that approved the original purchase has to acknowledge the failure.

Scenario 3: Strategic shift

The business unit reorganizes. The agent's primary workload changes. Salesforce becomes less of a data home; Snowflake becomes more. The data gravity argument that made Agentforce right in year 1 no longer holds. Strategic-shift migration is the hardest to predict and the most expensive because the new platform also needs to be chosen.

Scenario 4: Acquisition or divestiture

Your company is acquired; the acquirer is on a different platform. Or you divest a business unit; the agent program goes with it. M&A-driven migration is fast and political — usually decided by the integration team, not the architect.

Scenario 5: Regulatory or compliance change

A new data-residency requirement, a new auditability requirement, a new privacy rule that the vendor cannot meet. Regulatory-driven migration is the most urgent — usually 6-month deadlines from regulators don't accommodate the typical migration timeline. The architect who pre-modeled migration has options. The architect who did not has a crisis.

Case Study: The Fintech That Migrated Off Sierra in Month 22

The fintech from lesson 1. They bought Sierra at month zero, deflection hit 54% by month 4, savings were strong, the program was a success. The architect started running migration-readiness analysis at month 12, refreshed quarterly. By month 18 the spreadsheet showed migration cost of ~$680K against a year-3 renewal that the Sierra rep had floated as 40-50% higher.

The architect walked into renewal with three things: the migration cost number, a list of platforms credible to migrate to (Decagon for like-for-like; horizontal build for cost optimization), and a 90-day-build-validation plan. Sierra negotiated. Final renewal: 12% increase instead of 45%, plus migration credit language in the contract.

Net savings from the prepared migration analysis: $33%-savings on year 3 renewal = $440K against $80K of prep work analyzing the migration. ROI of preparation: 5.5x. The cost of NOT preparing would have been the 45% renewal increase locked in for three more years.

That is the math. The architect who models migration cost saves enough at renewal to fund three years of platform fees. The architect who does not pays the lock-in premium.

Case Study: The Program That Could Not Leave

A counter-case. A mid-market company built their first agent program on Agentforce in 2024. By 2026 they had 80 Topics, 200 Actions, three years of accumulated eval data, and 14 integrated downstream systems. The vendor's year-3 renewal proposal was a 70% increase plus required Data Cloud expansion.

The architect ran the migration analysis. Cost: $2.4M and 14 months. Against a renewal increase of $800K/year for three years = $2.4M total. Break-even at 36 months exactly. The architect made the case to stay; the increase was paid; the program limped along under cost pressure for two more years until the next renewal cycle. The architect resigned shortly after.

What went wrong. No MCP-wrapping in year 1 (so every Action had to be rebuilt). Eval suite in Agentforce Testing Center natively (so the full suite had to be re-authored). Prompts written in Agentforce-idiomatic style with deep Salesforce object references (so every Topic was a from-scratch rewrite). The decisions that made the year-1 implementation fast made the year-3 migration impossible.

The lesson: the architect's job is not to make the year-1 implementation as fast as possible. It is to make the year-1 implementation fast and reasonably portable. The portability discipline is the difference between a program that adapts and a program that gets trapped.

The Portability Checklist for the Architect on Day One

The decisions you make at month zero that materially reduce migration cost at month 24. A short list. Each costs 5-15% more in year 1 and reduces migration cost 40-70%.

Wrap tools as MCP servers when possible

For any tool that talks to a system outside the platform (databases, APIs, external SaaS), implement as an MCP server, not as a platform-native action. The MCP server runs anywhere; the platform-native action runs only here. Lesson 1.3.6 covers MCP in detail. The yield: tool re-wrapping cost drops from 3-5 days per tool to 1-2 days.

Author eval cases in a portable format

Even if you run eval through Braintrust or LangSmith or the platform's native testing center, the canonical eval set lives in a portable format — typically JSON or YAML files in source control. Each test case has input, expected output, scoring criteria. The platform's eval runner consumes these; the canonical source is portable. The yield: eval set re-authoring becomes re-importing in the target platform.

Externalize prompts

Prompts live in source control as text files with templating placeholders. The platform consumes them at runtime. When you migrate, the prompts come with you. You still have to adapt them to the new platform's prompting style, but you have the canonical text. The yield: prompt migration becomes adaptation, not from-scratch authoring. 40-60% reduction in this driver.

Document data flows and dependencies

Every architect should be able to answer: which prompts use which tools? Which tools call which downstream systems? Which eval cases test which agent paths? This documentation pays migration dividends because the new platform team can reason about the existing system without reverse-engineering it. The yield: 20-30% reduction in the "understand what the previous team built" tax.

Choose vendors who support portability

Vendors with explicit data-export commitments, MCP support, and migration-credit language in contracts are easier to leave. This is itself a sourcing criterion — alongside features and pricing, evaluate the vendor's portability posture. Vendors who resist data export are telling you about their year-3 negotiating intent.

The Quarterly Migration-Readiness Review

The discipline that converts a portability checklist into ongoing readiness. Once a quarter, the architect refreshes the migration readiness assessment.

1. Inventory. Updated count of prompts, tools, eval cases, integrations.
2. Migration cost estimate. Apply the per-asset days to the inventory; update the total.
3. Renewal scenario. What does the vendor's renewal proposal look like at current trajectory? Add 30-50% for the year-3 jump.
4. Break-even comparison. Migration cost vs accumulated renewal premium. If migration cost is less than 24 months of renewal premium, the migration is rationally on the table.
5. Target platform shortlist. Which platforms would you migrate to? What's their fit by data-gravity rule (lesson 2)?
6. 90-day-validation plan. What would a low-cost validation of the target platform look like? Pilot scope, eval criteria, exit gate.

This review takes 4-8 hours per quarter once the format is built. The architect who runs it for 8 quarters and never migrates is still ahead — they walk into every renewal with leverage. The architect who runs it once and migrates saves the multi-million-dollar lock-in tax.

The Three Failure Modes to Avoid

The "we never migrate" fallacy

Architects who think they will never migrate are wrong on a 5-year horizon. Vendor pricing changes. Strategic context shifts. Acquisitions happen. Better platforms emerge. The right question is not "will we migrate?" but "when we migrate, how prepared will we be?"

The "platform-native is best practice" fallacy

Vendor documentation will tell you to use platform-native constructs because they are easier in year 1. They are. They also lock you in. The portability discipline (MCP-wrapped tools, externalized prompts, source-controlled eval) costs more in year 1 and saves order-of-magnitude more in year 3. The vendor will not advise it because it works against the vendor.

The "we'll figure it out later" fallacy

Migration plans built reactively (after the vendor surprises you with a renewal jump) take 50-100% longer than migration plans built proactively. The reactive plan also lacks the eval-validation phase that proves the new platform meets quality bars — meaning you discover quality regressions in production. The proactive plan has time to validate. The reactive plan does not.

The Architect Discipline: The Three Numbers You Track

Quarterly, every quarter, the architect maintains three numbers in the migration-readiness file.

1. Current migration cost estimate for the program. Updated based on the latest asset inventory.
2. Projected next renewal increase based on vendor signaling and market data.
3. Months to break-even on migration vs continued renewal premium.

These three numbers turn the abstract risk of platform lock-in into a concrete, trackable, board-presentable position. They are the reason a $440K savings at renewal happens; they are the reason a 70% renewal increase is fought and won; they are the reason the program adapts to changing context instead of being trapped by it.

Connecting Back to the Original Platform Decision

This chapter has been four lessons of platform-selection discipline.

• Lesson 1 — Build vs Buy vs Compose. Per-workload decision, 100K-units break-even, five questions.
• Lesson 2 — Agentforce vs Copilot Studio. Data gravity rule, six deal-breakers, per-workload again.
• Lesson 3 — The TCO Model. Seven cost categories, 24 months, risk-adjusted.
• Lesson 4 — Migration Cost. Three drivers, the lock-in premium, the portability checklist.

The synthesis: the platform decision today is also a decision about your flexibility in year 3. The architect who treats them as one decision (single platform choice) has half the picture. The architect who treats them as two (the choice and the exit plan from the choice) has the full picture. Year 3 will tell you which architect you were.

Key Takeaways

• The vendor knows your migration cost. Most architects do not. The asymmetry decides the year-3 negotiation.
• Three migration cost drivers: prompt rewrites, tool re-wrapping, eval set rebinding. They account for 85%+ of migration cost on every program in production.
• For a department-scale agent with 40 prompts, 25 tools, 200 eval cases, and 6 integrations: migration cost is roughly $600K-$900K. Plan around that order of magnitude.
• Lock-in premium = (migration cost / 36 months) / annual platform cost. Multiplied across a 3-year contract this is the implied switching tax. Use it as negotiation leverage at the original procurement, not as a price-discount demand.
• Five migration scenarios: vendor price increase, quality stagnation, strategic shift, M&A, regulatory change. All are real; one of them happens to most programs over 5 years.
• The fintech that prepared migration analysis won a 12% renewal vs 45% — saving $440K against $80K of prep. ROI of preparation: 5.5x.
• The portability checklist: MCP-wrap tools, externalize prompts, author eval cases in portable format, document data flows, choose portability-friendly vendors. 5-15% year-1 cost premium, 40-70% migration cost reduction.
• Quarterly migration-readiness review takes 4-8 hours. It is the discipline that turns lock-in risk into leverage.
• Three failure modes: "we never migrate," "platform-native is best practice," "we'll figure it out later." All three concede the negotiation before it starts.
• Three numbers to track every quarter: current migration cost estimate, projected next renewal increase, months to break-even. These are the architect's leverage at every vendor conversation.