Someone asked me a version of this last week, and it's the question I get most often.
The enterprise tools already exist. They're also badly implemented. So a new tool starts absorbing work out of convenience and necessity, in exactly the places you'd tell it not to go. What do you do about that?
Enterprise is full of half-implemented solutions and baskets of spreadsheets. That isn't a jab at anyone. It's the accumulated result of a lot of reasonable decisions made under deadline by people who inherited the last set.
There are two obvious answers. Both are bad.
The first is the full teardown. Rip out the system that isn't working, implement it properly, stop the bleeding. Often that's the technically correct answer. It's also an ugly answer, nobody wants to figure out what it costs, and it competes for budget against things with revenue attached. I've watched teardown proposals die in committee more often than I'd like.
The second answer is the one that happens by default, which is nothing. The new tool keeps absorbing work. Each absorption is individually defensible. Six months later you have two systems that both think they own the process, and the interesting question becomes which one is lying.
So here's what we actually do. Pick a boundary and pilot the boundary.
Not a replacement. Not a migration. A boundary. One explicit line where you say this system stops and that system starts, and then a small piece of real work that proves whether the line is in the right place.
A worked example
Say you have Workfront, and you're using maybe the last little piece of it. Most of what it does could live somewhere else. But your creative assets are in there, and it ties into AEM, so the creative side is genuinely easier where it is.
The question isn't whether to replace Workfront. The question is where Workfront ends and where Airtable starts.
One answer: project and work management moves. Deliverables, milestones, assignments, status, the whole coordination layer. Creative assets stay in Workfront, because of AEM.
That's a hard cutoff. This is where Workfront stops. This is where Airtable begins. You could argue about whether it's the right cutoff, and you probably could keep Workfront and bolt something else on instead. That argument is fine, and it isn't the point. The point is that you drew a line out loud, which means you can now test it.
So the pilot is narrow. Run project management in Airtable for the deliverables being produced in Workfront. Nothing else moves.
What the pilot is actually testing
This is where it usually goes wrong. The pilot is not testing whether Airtable can do project management. It can. That was never in question, and a pilot designed to answer it will succeed and teach you nothing.
The pilot is testing the boundary. There are two outcomes and both are useful.
Workfront still earns its last mile. The creative integration turns out to matter more than you thought, the boundary holds, and you now have a documented reason for keeping a tool people had been complaining about. That's a result.
Or it doesn't. Once the coordination work moved, the thing you were preserving Workfront for turns out to be thinner than expected, and you can make the case to pull it out. Also a result, and now the case rests on evidence instead of on a general feeling that the tool is annoying.
You can make the case to replace a point solution once you've built the bridge to where it's still valuable. Until that bridge exists, the conversation is two departments asserting preferences at each other.
Why this works politically, which is most of why it works
A teardown proposal asks somebody to give something up before anyone knows what they'll get back. That's why they stall.
A boundary pilot asks nobody to give up anything. Finance keeps its system. The creative team keeps Workfront. The only thing that changes is that one clearly scoped piece of coordination work happens somewhere new, for a defined period, against a stated measure.
It also forces the one conversation that needed to happen anyway: which of these two systems is responsible for what. You were going to have to answer that eventually. A pilot is a cheaper place to answer it than a migration plan.
One caveat, and it's a real one
A boundary pilot doesn't fix execution.
Poor execution isn't going to change because you moved it to Airtable. Organizations tell me their last implementation didn't work, and when we go back through it, the thing that didn't happen was deciding. Nobody established who owned what, so the build absorbed the ambiguity and shipped it.
If that's the actual problem, a pilot in a new tool will reproduce it faithfully and on schedule.
Which is why the pilot needs a success measure written down before it starts. Not that the team likes it. Fewer clicks. Less time to roll out the campaign. Some named operational outcome somebody will be accountable for.
If there's no success criteria, then the deliverable is satisfaction. Client satisfaction, team member satisfaction, stakeholder satisfaction. And satisfaction is not something you can deliver against. It's feelings and hopes and dreams.
The short version
Convenience is not an architecture strategy. But neither is a teardown you'll never get funded.
Pick the boundary. Prove the boundary. Then let the evidence tell you whether the incumbent still deserves its last mile.
The boundary is the deliverable. The tooling decision follows from it.