The Commercial Envelope: What Happens When the Business Case Changes?

There is no shortage of conversation about Headless, MCP, AI and the promise of getting technology delivered faster. It can get technical very quickly.

I’m a sales guy. I understand technology, but I tend to come at it from the other end. I want to know what it means for the customer, what it makes possible and whether it changes the economics of doing something that previously didn’t stack up. I also know when I need to get a much smarter technical person into the room.

That was on my mind after a conversation with a customer that has been looking for some time at moving from a legacy martech platform onto a modern platform such as Salesforce.

I’ve been thinking about the problem ever since.

It reminded me of my Ford Kuga.

My Kuga problem

My Kuga isn’t very good anymore.

It’s old. The technology is dated. There are much better cars around. It probably isn’t particularly economical and, if I’m honest, I wouldn’t be heartbroken if it disappeared tomorrow.

But it still does the school run.

It’s also fully paid for.

And that’s pretty much its job. I have a ute for the beach, bikes, dogs, camping, and everything else, so the Kuga doesn’t need to do much more than get my son to school and get us home again.

Someone could show me a much better car tomorrow and I’d probably agree with them.

Then I’d ask the obvious question:

Why would I spend $60,000 replacing something that still does the job?

That’s the problem with a lot of enterprise technology migrations.

The legacy platform might be old, frustrating and increasingly difficult to support. Everyone might agree that something newer would be better.

But if the proposal is essentially to spend millions of dollars moving from Platform A to Platform B so that the business can carry on doing roughly the same thing, the business case gets difficult very quickly.

You are asking the organisation to spend a lot of money to get back to where it already was.

The commercial envelope

Every technology investment has a point at which the numbers stop making sense. The cost, risk, complexity and disruption of doing something outweigh the value it creates.

That’s why organisations keep old technology.

It isn’t always because nobody knows there is something better. Quite often, everyone knows. The problem is that replacing it costs too much relative to what the business gets back.

The old thing is annoying, but functional.

The new thing is better, but expensive.

So the project sits there for another year.

I’ve seen versions of this throughout my career. I suspect most people who have worked around enterprise technology have as well.

The interesting question for me now is whether technologies such as Headless, MCP and AI can move that equation.

What happens when getting there costs less?

If you read my previous post on Salesforce Headless 360, you’ll know I went into the technology in much more detail there, including what I think is genuinely new about the combination of Headless, MCP and agents, and how Salesforce is approaching identity, permissions and governance.

I won’t repeat that here.

What I want to explore is what it could mean for the business case.

The important thing to understand is that Claude isn’t the story.

Claude is simply the client I’m using in my example. ChatGPT, Gemini, Cursor, Codex, Windsurf or a custom agent can sit in the same position because MCP is an open protocol. Salesforce’s Hosted MCP servers allow compatible AI clients to connect to Salesforce capabilities through a standardised interface.

Headless 360 opens Salesforce to different AI agents and clients. Image shared by the Salesforce Trailblazer community. Thanks to the community for making it available.

That matters commercially because I don’t have to make the whole investment case around one particular AI model.

The model can change.

The underlying business capabilities can remain.

And there is another potential change on the delivery side.

Salesforce is exposing more of the platform to agents through MCP. The Headless 360 MCP server can discover available Salesforce operations, understand what they require and dispatch those operations. Today that includes things such as querying and updating records, managing users and permissions, working with Apex and building event-driven integrations, with the library continuing to expand.

That doesn’t mean you can point an agent at a legacy platform and come back on Friday to find a perfect Salesforce migration waiting for you.

Migrations still need architects, developers, data specialists, testers and people who understand the business. The difficult bits don’t disappear.

But if agents can understand Salesforce metadata, APIs, configuration and business capabilities, some of the manual work involved in building and changing the target platform can be accelerated.

For a migration that costs millions and takes years, that matters.

And there is another side to the equation.

What can the new platform do that the old one couldn’t?

This is where I think the Headless part gets really interesting.

A modern platform doesn’t have to be used in the same way as the legacy one.

Salesforce is making its data, business logic and platform capabilities accessible through APIs, applications, agents and MCP-compatible clients rather than requiring every interaction to happen through the Salesforce interface.

That gives you options.

An employee could ask an agent to find information and take an action. A customer could interact through a web or mobile experience without needing to know Salesforce is underneath it. A developer could use an AI coding agent to work against Salesforce capabilities. An existing application could potentially use Salesforce as the underlying customer and process platform without exposing the Salesforce UI at all.

The question for a migration therefore becomes much bigger than whether the new platform can reproduce the old one.

What could we do now that wasn’t worth doing before?

That’s where the commercial envelope starts to move.

The CRM data problem might look different too

There is another part of this that I hadn’t really considered until I started thinking about Headless in this context.

For years, we’ve asked people to put information into Salesforce because the organisation needs a system of record.

That’s a reasonable argument.

It’s also a slightly shit user proposition.

“Please spend five minutes entering all this information because someone else might need it later.”

We’ve spent years trying to improve CRM hygiene through training, process, incentives, dashboards and management pressure.

Now imagine the person entering the information can get something back from it.

Your meeting notes, account history, opportunity information, customer interactions and other context are sitting in Salesforce. An agent can find that information and use it alongside information from other systems.

You could ask:

“What happened with this customer?”

Or:

“What do I need to know before tomorrow’s meeting?”

Or:

“What did we agree last time?”

Or:

“Update the opportunity and create the follow-up actions based on what we’ve just discussed.”

That’s a pretty different reason to keep the information up to date.

And it could make the system of record more useful to the person putting the data in, rather than simply more useful to the management team looking at it afterwards.

Go back to the business cases that didn’t work

Every large organisation has projects that never got over the line.

A better customer self-service experience. A new partner portal. A field application. More intelligent marketing journeys. Automated approvals. Better access to customer information. Replacing an ageing application. Connecting information across several systems.

Often, the problem wasn’t that anyone thought these things were impossible.

They just weren’t worth the money.

The projected benefit wasn’t big enough. The integration was too complicated. The implementation would take too long. The change required was too disruptive. The technology underneath was too difficult to work with.

So the business said no.

Those decisions made sense at the time.

But technology doesn’t stand still.

If the cost of building and changing the new platform falls, while the number of things you can do with it increases, some of those old decisions are worth looking at again.

But there’s another number we don’t always put into the business case.

What does it cost to stay where you are?

We tend to be pretty good at calculating the cost of replacing legacy technology. The migration programme. The implementation. The licences. The people. The change management. The disruption.

We are generally much less disciplined about calculating the cost of keeping it.

What does it cost when a new customer experience takes 18 months instead of three? What does it cost when developers spend their time working around an ageing platform? What opportunities never get proposed because everyone already knows the integration will be too difficult?

And what happens when a competitor can do something in weeks that takes your organisation a year?

The cost of doing nothing isn’t zero.

That’s another part of the commercial envelope.

So there are now three questions I’d ask about a legacy platform:

What did we decide not to build because the economics didn’t work?

Have the economics changed?

And what is it costing us to keep doing things the old way?

And what about security?

This is where the technical detail actually matters.

If we’re going to let an agent read and write against enterprise systems, the obvious question is:

Who exactly is allowing it to do that?

Salesforce’s Hosted MCP security model has authentication, authorisation, granular permission controls and logging. MCP transactions run as the authenticated user, with Salesforce’s existing object permissions, field-level security, sharing rules, profiles and permission sets applying. Actions are attributed to the user in the audit trail.

That doesn’t make an AI agent inherently safe. You still need to decide which users, clients and tools should have access, what they can do and where human approval is appropriate.

But it does mean the proposition isn’t simply:

“Let’s give Claude access to the CRM and see what happens.”

There is a governed access layer between the agent and the platform.

That’s important if we’re talking about enterprise adoption rather than a clever demo.

Salesforce’s Hosted MCP architecture includes authentication, authorisation, permission controls and logging.

Back to the Kuga

This is why my Kuga is still sitting in the driveway.

If someone offers me a newer Kuga that gets my son to school a bit more efficiently, I’m probably not interested.

But if the new vehicle costs less to run, can carry the bikes, handle the beach, tow something and gives me capabilities I don’t have today, I’m having a different conversation.

The new car has to earn its place.

I think enterprise platforms are much the same.

A migration that simply reproduces what the business already has is a hard sell.

A platform that costs less to change, can be used in more places, can make better use of the data already sitting inside it, can expose its capabilities to agents and can support things the old platform couldn’t economically support is a different proposition.

The migration is still expensive.

But the value on the other side can be considerably larger.

The migration isn’t the business case

This is probably the biggest thing I’ve taken away from thinking about this.

The migration itself isn’t the business case.

The outcome is the business case.

If all you’re doing is moving an ageing martech platform onto a newer platform, I can understand why the CFO might ask why they should spend the money.

But if you’re using the migration to create a customer engagement capability that is easier to evolve, accessible through different experiences, usable by agents, better connected to customer context and capable of supporting things that weren’t economically viable before, that’s a much more interesting investment.

And that is where I think Headless and MCP deserve attention beyond the technical conversation.

They may help reduce some of the work involved in getting to the new platform.

More importantly, they can change what the new platform is capable of doing once you get there.

That gives us a reason to go back through the business cases that didn’t work five years ago.

Not because AI makes everything possible.

Because the economics may have changed.

The question I’d ask about any legacy platform now is:

What did we decide not to build because the economics didn’t work?

And then:

Do those economics still hold?

Because the people who should be asking that question aren’t necessarily the people who own the legacy platform.

They’re the people accountable for what the business could do if it didn’t have to work around it.