Build on the stack you have - why "first, migrate" is a red flag

There's a pattern in AI proposals worth learning to recognize: before any value shows up, a migration does. A new platform, a new CRM, a "modern data foundation" - and once you're on it, then the intelligent stuff begins.

When a proposal starts that way, someone is optimizing for themselves.

What a migration actually asks of you

Your ERP, your CRM, your accounting package - these aren't just software. They're years of accumulated decisions, integrations, data history and muscle memory. Getting onto them cost real money and real time; some companies spend years on a single ERP implementation. The processes wrapped around them were shaped by daily use, not by a project plan.

A proposal that begins with replacement is asking you to write all of that off. Pay the migration cost, take the migration risk, retrain everyone, rebuild every connection to the outside world - and accept that during the transition, your operation runs on two systems and full attention on neither. All before the thing you actually wanted, the automation, has delivered a single result.

There's a quieter cost too: you're being asked to admit your own past decisions were wrong. They usually weren't. The system works; that's why you're still on it.

Why builders push migrations anyway

Rarely because your stack can't support the goal. Mostly because greenfield is easier for the builder - integrating with a real ERP means learning its API, its quirks, its twenty years of field conventions, and a shiny new platform means none of that. And when the new platform is the vendor's own, the migration isn't a technical recommendation at all. It's a business model: once your data and processes live in their system, so do you.

Neither reason has anything to do with your outcome.

The integration route

The alternative is unglamorous and works: leave the systems of record where they are and build the intelligent layer on top, connected through their APIs.

The automation reads from the ERP and writes to the CRM. It picks up the mailbox, the portal feeds, the exports you already produce. When it categorizes, drafts or decides, the result lands in the systems your team already has open - not in yet another tab they have to remember to check. Nothing about their day changes except the part that got easier. That last point is most of the battle: adoption kills more automation projects than technology does, and adoption is easiest when there's nothing new to adopt.

It's also simply a stronger system. The value of AI in a business comes from context, and your context lives in the systems you already run - the customer history in the CRM, the financials in the ERP, the correspondence in the mailbox. Wiring those together and putting intelligence on top gives the model everything your company knows. A fresh platform starts empty.

When a migration is the right call

For honesty's sake: sometimes the incumbent really is the problem. The vendor is gone, there's no API and no way to get data out, or the "system" is a spreadsheet that stopped coping two years ago. Then a move can be the right call.

But notice the reasoning: the system is failing on its own terms. That's a decision to take deliberately, on its own timeline - not a toll you pay because an AI proposal requires it. Even then, the practical route is often gradual: build the new capability alongside, connect it to what exists, and let the old system shrink instead of scheduling a cliff.

The question to ask

Integration work is the bulk of what I do, so I have a bias here - but it's a bias you can borrow when you evaluate any proposal, including mine. Ask: what stays?

The answer you want is "everything that works." If the answer is a migration project with AI waiting politely at the end of it, get a second opinion. I'm available for exactly that - and if the honest answer in your case is that something genuinely does need replacing, I'll tell you that too.