Modernising Salesforce - From Platform Sprawl to Platform Power

Originally published on LinkedIn, 25 April 2025

Even in the cloud, legacy creeps in, and it’s time we talked about what that means for Salesforce.It’s not just technical debt in the classic sense.  Of course, overloaded Apex classes, spaghetti Flows, and object limits maxed out are part of it.   The legacy challenge is broader. It’s about how complexity accumulates over time, often in response to urgency rather than intent. Every quick fix, every one-off solution, every undocumented process adds up.

And while I admire the platform for its flexibility (I really do!), too much ungoverned flexibility becomes a liability.

What started as tactical problem-solving eventually becomes a strategic bottleneck.  Labelling these issues as mere technical debt can mislead stakeholders about the real investment required to fix them, consequently another budget-friendly tactical solution is often implemented which compounds the problem.

This Isn’t Just Cleanup — It’s Capability Building

Modernising a Salesforce org isn’t about spring cleaning. It’s about rebuilding your digital core to be more agile, scalable, and innovation-ready.

That could mean:

• Migrating legacy Apex and Visualforce into modular, testable Lightning Web Components and Flows

• Implementing event-driven or headless architectures to support decoupled experiences

• Adopting package versioning, DevOps pipelines, and observability tools to reduce release friction and increase velocity

• Redesigning data models and integrations to enable AI, analytics, and real-time orchestration

The goal is a platform that works with, not against, you in this new age of AI.

From Quick Wins to Sustainable Strategy

We’re all guilty of taking a quick win, sometimes they’re necessary. But sustainable, scalable systems come from intentional design.  In the Salesforce ecosystem, the bar is rising.

Teams need to think like platform engineers: balancing low-code productivity with pro-code principles, treating metadata as source, and embracing architectural governance as a default.  In my experience, the most reliable documentation is what’s actually in the production org.

Why This Matters Now

Let me be clear on the scale and sprawl of the Salesforce applications that I am referencing, they were not built at a moment in time and then left unchanged.  Salesforce customers have invested 5, 10, sometimes 15 years of elapsed time expanding their Salesforce based applications.

Salesforce applications will remain mission-critical.  In the current climate the pressure to sell and serve effectively and efficiently continues to grow. The platform is expanding in capability almost weekly, with innovations in AI, data, automation, and industry solutions which have the potential for customers to adopt quickly and sharpen their competitive edge.

As products like Agentforce and Data Cloud evolve there is a lot of business value to be harnessed.  But, if the foundation isn’t modernised, the majority of teams will encounter blockers which limit which new features they will be able to use.

We’ve seen this pattern before in previous technology cycles, AI is just the latest catalyst to revisit and restructure our system landscape.  The common thread is that before you innovate, you need to understand what you’ve built so that you can evolve it.

Let’s Open the Conversation

I’m not claiming to have all the answers—but I believe we need to talk more openly about legacy in the Salesforce space so that we can build the future.

What does modernisation look like in your world?

Where are the blockers - people, process, technology?

What tools or approaches are helping you move faster?

I welcome your comments and to hear how others are navigating this journey. Share your thoughts, let’s shape the future of Salesforce delivery together.