2025: A Year of Modern Salesforce Architecture - Why Legacy Structure Determines AI Readiness

I did not start working on modern Salesforce architecture because of AI.

I had already been deep into Modern Salesforce Architecture (MSFA) by early 2024, trying to make sense of increasingly complex Salesforce estates and the limits of traditional delivery and design approaches. But 2025 has been the year where the technology, the disruption, and the potential of emerging capabilities have finally converged. It is the year where those early explorations hardened into a clear, actionable framework.

And that framework did not start with agents, copilots, or automation.

It started with legacy.

Specifically, with the uncomfortable recognition that many Salesforce estates built over the last fifteen to twenty years are successful, valuable, and fragile at the same time. They encode how the business actually works, not how the business thinks it works. And they now sit directly in the blast radius of the next technology wave.

This article is a look back on roughly a year of that work. It is not a victory lap, and it is not a finished doctrine. It is a record of discovery: how a set of disconnected concerns gradually resolved into a coherent architectural stance, driven by one core question:

How do we modernise Salesforce estates without destroying the business value embedded inside them, at a time when AI-driven change is inevitable but still uncertain?

The Legacy Landscape and the AI Imperative

Every serious Salesforce programme I encounter today starts from the same place: a legacy landscape that was not designed for the world it now inhabits.

Over time, Salesforce orgs accumulate behaviour. Validation rules, flows, Apex classes, sharing models, assignment logic, pricing logic, territory logic, approval paths, exception handling. These things are rarely documented accurately outside the system.

The system is the documentation.

That matters, because AI disruption is not optional. The exact shape of the disruption may still be unclear, but the direction is not. Automation is becoming agentic. Interaction is becoming probabilistic. Delivery models are shifting. Expectations of speed, adaptability, and leverage are rising.

In previous technology waves, modernisation often meant replacement. That approach fails here. Replacing a mature Salesforce estate wholesale is not just expensive, it is reckless. You do not replace twenty years of encoded business learning without loss.

So the starting problem was never “how do we adopt AI”.

It was more fundamental:

How do we prepare Salesforce estates for radical change without erasing the logic that makes them valuable?

Phase One: Confronting What Legacy Really Is

The first phase of this work was about honesty.

Legacy is not just “old code” or “technical debt”. In Salesforce, legacy is often a business operating model expressed as metadata. That is why attempts to “clean it up” so often stall or fail. You are not refactoring software. You are refactoring organisational memory.

Two insights emerged very early for me:

• The most accurate representation of how a business actually operates often exists only inside the Salesforce implementation.

• The parts of the system that change most frequently are usually the ones most tightly coupled to the execution layer.

This is where many programmes stall. Every new market, regulation, product, or channel variation requires touching flows, validation rules, or Apex. The result is escalating fragility and slowing delivery.

Modernisation, therefore, could not start with AI features, DevOps tools, or new clouds.

It had to start with decoupling.

Phase Two: Discovery Through Extraction and Reformulation

The breakthrough came when I stopped asking how to “clean up” legacy orgs and started asking a different question:

What if we treated existing Salesforce estates as a rich source of structured business intelligence?

That reframing led directly to metadata extraction and reformulation.

Across design sessions, delivery work, and architectural experiments, a clear pattern emerged:

• Business rules are embedded everywhere, but not evenly.

• Certain rules change frequently: eligibility, classification, thresholds, routing.

• Other parts of the system must remain stable to preserve trust.

This led to the idea of extracting volatile business intent from execution artefacts and reformulating it into explicit, declarative structures. Not code. Not flows. Policies.

This was not about adding abstraction for its own sake. It was about creating architectural seams. Places where change could land safely.

Once I started looking at Salesforce estates through this lens, previously disconnected ideas aligned:

• metadata-driven configuration

• policy-based decisioning

• event-driven orchestration

• canonical data models

• modular packaging

Each of these had existed as a best practice in isolation. The insight was that they only reach their full value when treated as parts of the same modernisation strategy.

Phase Three: From Single-Org Thinking to System Architecture

As the policy-driven perspective solidified, it became clear that modern Salesforce architecture cannot be defined at the org level alone.

Legacy thinking assumes the org is the system. Modern thinking treats the org as one deployment surface within a broader product ecosystem.

That shift led me to several non-negotiable conclusions:

• Application orgs should be deliberately thin.

• Core business logic should not be repeatedly hand-built in each org.

• Data gravity and intelligence belong in shared, governed layers.

• Orgs should be deploy targets for packaged capabilities, not places where architecture improvises.

This reframing unlocked a more scalable mental model: Salesforce as an engineered system, not a collection of customised environments.

It also created space for AI to arrive safely. Agents do not thrive in chaotic systems. They require clear boundaries, trusted data, and explicit intent. Policy-driven architecture and modular packaging are not optional prerequisites for agentic delivery.

They are enablers.

From Legacy to Policy to Execution: The Structural Shift That Changed Everything

One diagram ended up doing more explanatory work than pages of prose.

Not because it was clever, but because it made visible a shift in thinking that took months to articulate:

Modernisation is not about replacing legacy execution. It is about interposing structure between intent and action.

At a high level, the model looks like this:

Legacy Execution → Policy Layer → Modern Execution

Legacy: Business Intent Trapped in Execution

On the left sits the familiar Salesforce reality: flows, Apex, validation rules, sharing logic, assignment rules, integrations. All tightly bound together.

This layer works. That is precisely the problem.

Business intent is embedded directly in execution artefacts. Rules about eligibility, routing, classification, and exception handling are scattered across the system. Change requires touching multiple components, often owned by different teams, with unpredictable side effects.

In this state, every change is expensive. Every AI experiment is risky.

Policy: Making Intent Explicit

The centre of the model is where the architectural shift occurs.

Here, volatile business intent is extracted and reformulated into explicit, declarative policies. These policies do not execute logic. They express what should happen, not how it happens.

Examples include:

• eligibility rules

• classification criteria

• thresholds and limits

• routing decisions

• conditional entitlements

This layer becomes the system’s source of truth for decision-making intent. It is inspectable, governable, and changeable without rewriting execution logic.

Most importantly, it creates a stable seam. A place where business change can land safely.

Execution: Stable, Observable, Replaceable

On the right sits execution, now deliberately simplified.

Flows, Apex, integrations, and agents consume policy decisions rather than encoding them. Execution becomes more uniform, more testable, and more observable. Multiple execution mechanisms can coexist because intent is no longer hard-wired into any single one.

This is the point where AI becomes viable at scale.

AI readiness emerges here as an architectural property, not a tooling decision.

Phase Four: AI-Native Is an Architectural Property, Not a Feature

One of the most important lessons of the year for me was this:

AI-native is not something you bolt on.

AI readiness emerges from architectural discipline:

• separation of intent and execution

• stable contracts between layers

• observable behaviour

• governed change

In this context, AI becomes an amplifier, not a destabiliser. Agents can reason over policy. Automation can subscribe to events. Intelligence can be layered without rewriting foundations.

This is why the early focus on legacy extraction mattered so much. Without that work, AI adoption simply becomes another layer of accidental complexity.

Modern Salesforce architecture, as it has emerged over this year, is not defined by which AI tools you use. It is defined by whether your system can absorb change without losing coherence.

A CTO Call to Action: Structure Before Intelligence

If there is one lesson I would offer after the last year, it is this:

AI will not save poorly structured Salesforce estates.
It will amplify whatever structure already exists.

For Salesforce CTOs, the priority is no longer feature adoption or cloud selection. It is architectural readiness. That means treating legacy orgs as assets to be decoded, not liabilities to be replaced. It means extracting business intent from execution before change forces your hand. It means designing systems with clear seams, stable contracts, and explicit policy.

Modern Salesforce architecture is not a destination.
It is a discipline.

The organisations that succeed in the next phase will not be the ones that move fastest into AI. They will be the ones that add the capability to put structure where entropy has accumulated, so that intelligence has something solid to stand upon.