Fernside Studio
Background
Archive
Journal Entry

AI Migration Costs: What Switching Really Takes

Documented
Capacity
7 MIN READ
Domain
Website Performance & Ops

Switching AI tools isn’t like switching email providers. Your prompts, training data, integrations, and team workflows are all vendor-specific. Here’s what AI migration costs actually look like: in money, time, and disruption, so you can plan properly instead of discovering the bill halfway through.

Hidden migration costs most people miss

The sticker price of the new tool is rarely the real cost. The real cost shows up in the work nobody puts on the quote.

  • Prompt rewriting. Prompts tuned for one model rarely perform the same on another. Expect to re-test and rewrite most of your prompt library.
  • Retraining or fine-tuning. Any fine-tuning work you did on the old model doesn’t transfer. You start from a fresh baseline.
  • Integration rebuilding. Every API integration connecting the old tool to your CRM, website, or booking system needs rebuilding for the new vendor’s API.
  • Data format conversion. Exports rarely land in the shape the new tool expects. Someone has to map and clean the data.
  • Team retraining. New interface, new quirks, new failure modes. Staff need time to relearn the tool, not just click through a tutorial.
  • Parallel running period. Most teams run old and new systems side by side for weeks to catch gaps before cutting over fully, which means paying for both.

None of this is exotic. It’s the same pattern seen in wider IT migration work: Standish Group’s CHAOS research has repeatedly found that more than half of IT projects run at roughly 189% of their original cost estimate, with an average overrun near 89%. AI tool migrations aren’t exempt from that pattern, if anything, the vendor-specific nature of AI workflows makes scope creep more likely, not less.

Data migration: what moves and what doesn’t

Before quoting a migration, work out what’s actually portable.

Usually portable:

  • Raw source documents and files you fed into the old tool
  • Exported conversation or output history (in whatever format the vendor allows)
  • Your own configuration notes, if you kept them outside the tool

Usually locked to the vendor:

  • Custom-trained or fine-tuned models, these don’t export
  • Prompt chains built inside a proprietary builder UI
  • Embeddings stored in a vendor-specific vector database
  • Workflow logic built with vendor-only automation blocks

This is the practical shape of data portability risk: not whether your data exists somewhere, but whether it exists in a form the next tool can actually use. If your evaluation criteria for a new AI vendor didn’t include an export test, that’s worth doing before you sign anything, not after.

Integration rebuilding: the part that eats the budget

Every connection your current AI tool has to another system, website forms, CRM, booking software, invoicing, needs to be rebuilt, not copied.

Reasons it’s rarely a straight swap:

  1. Webhook URLs change, so every downstream system needs repointing.
  2. Authentication differs. API keys, OAuth flows, and rate limits vary by vendor.
  3. Response formats differ. Field names, structure, and error handling won’t match, so parsing logic needs rewriting.
  4. Edge cases resurface. The quirks you patched over months on the old integration reappear on the new one, in different form.

As a planning rule of thumb, budget 60 to 80% of your original integration effort to rebuild each connection. It’s rarely a full rebuild from zero, since you already understand the business logic, but it’s far from a copy-paste job either. Teams that treat migration as “swap the API key” consistently underestimate this line item.

If your current setup already required custom workflow automation, assume the rebuild is closer to 80% than 60%. Bespoke logic doesn’t transfer cleanly between platforms.

The productivity dip nobody budgets for

Even a clean migration costs you time indirectly. Teams typically take two to six weeks to get back to their previous efficiency on a new tool, longer if the workflow was complex or the old tool was deeply embedded in daily habits.

This matters for your ROI math. If you’re switching to save £200/month on subscription fees but the switch costs six weeks of reduced output across a team, the payback period is longer than the spreadsheet suggests. Factor the dip in explicitly:

  • Estimate the team’s current output value per week
  • Estimate the expected efficiency loss (30 to 50% is a reasonable starting assumption for weeks one to two, tapering off)
  • Multiply across the adjustment period
  • Add that figure to your migration cost, not your “cost of doing business”

This is the calculation most vendors won’t help you make, because it’s not in their interest to slow down the sale.

Migration planning: reduce the pain

A few habits consistently reduce migration cost and risk:

Export your data early, before you need to. Don’t wait until you’ve decided to leave. Regular exports mean you’re never negotiating with urgency.

Document your current setup now. Write down every integration, every prompt template, every workflow rule. This document becomes your migration spec later, and it’s useful even if you never switch.

Run a phased migration, not a big-bang cutover. Move one workflow at a time. Validate output quality before moving the next.

Keep a genuine parallel-running window. Two systems running side by side for two to four weeks catches errors before they reach customers.

Have a rollback plan. Know exactly how you’d revert to the old tool if the new one underperforms in week one. If you can’t answer that in a sentence, you’re not ready to migrate.

This is the same discipline we apply when connecting business tools for clients in the first place: build the integration so it’s documented and portable from day one, so a future migration (if it ever happens) is a project, not a crisis. It’s also why we default to standard API integration patterns over vendor-proprietary automation builders wherever the client’s requirements allow it, it keeps future options open.

When switching isn’t actually the answer

Sometimes the tool isn’t the problem. If a general-purpose AI tool never quite fit your workflow, migrating to a different general-purpose tool tends to reproduce the same friction in a new shape. Read our note on when off-the-shelf tools aren’t enough before assuming the fix is “switch vendors” rather than “build something scoped to how you actually work.”

FAQ

How much does it typically cost to migrate between AI tools? It depends heavily on how many integrations and how much fine-tuning were involved, but for a small business running a handful of AI-connected workflows, budget for meaningful integration rebuild time plus two to six weeks of reduced team productivity, on top of any new subscription costs.

Can I avoid vendor lock-in entirely? Not entirely, but you can reduce it. Favour tools with clean data export, avoid proprietary no-code builders for critical logic, and keep your own documentation of every integration outside the vendor’s platform.

Is it cheaper to migrate or to build a custom system from the start? If you’re already hitting the limits of an off-the-shelf tool and considering a second migration, it’s worth costing out a scoped custom build against a third migration. Repeated switching costs add up faster than most founders expect.

Planning an AI migration, or trying to work out whether switching tools is even the right move? Talk to us about your setup before you commit budget to a switch. If you’re weighing a scoped, owned system instead of another off-the-shelf tool, our advisory and managed systems work is built for exactly this kind of decision.

Sources