Practical guide to managing Salesforce upgrades, Apex customisations, integration sprawl, and platform optimisation for Australian businesses.
IT leaders, sales managers, and RevOps teams running Salesforce who need to manage tri-annual releases, Apex customisations, and integration complexity.
How do we manage Salesforce's release cycle, keep customisations stable, and control integration sprawl?
Salesforce is the dominant CRM platform globally and in Australia. Originally a sales CRM, it's grown into a massive platform ecosystem covering Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud, and the broader Salesforce Platform (custom apps, Apex, Flow, Lightning).
For Australian businesses, Salesforce is often the CRM of choice for mid-to-large sales teams, but the platform's complexity grows fast. What starts as a clean Sales Cloud implementation can become a sprawling ecosystem of custom objects, Apex triggers, Flow automations, AppExchange packages, and integrations within a few years.
The challenge isn't whether Salesforce can do what you need — it almost certainly can. The challenge is managing the complexity that comes with a mature Salesforce environment.
Tri-annual releases. Three major releases per year (Spring, Summer, Winter) introduce new features, deprecate old ones, and can change platform behaviour. You can't opt out. Sandbox preview periods are available, but you need a structured process to use them effectively.
API version deprecation. Salesforce deprecates old API versions on a rolling basis. Apex code, integrations, and AppExchange packages that reference deprecated API versions will eventually break. Staying within 2-3 versions of current is best practice.
Governor limits. Salesforce enforces strict execution limits (governor limits) on CPU time, SOQL queries, DML statements, and more. As your org grows and processes become more complex, you can start hitting limits that didn't matter when the org was smaller.
Licence cost escalation. Salesforce licencing is per-user, per-month, and adds up fast. Enterprise edition, add-on clouds (Marketing, CPQ, Einstein), and AppExchange packages compound the cost. Many businesses are paying significantly more than they need to.
Release management process. Establish a testing cadence: review release notes → identify impacted features → test in sandbox → validate integrations → approve for production. Assign release ownership to a specific person or team.
Edition optimisation. If you're on Enterprise or Unlimited edition but don't need all the features, consider whether Professional edition plus targeted customisation could reduce costs. Conversely, if you're on Professional and hitting limits, evaluate what Enterprise actually gives you.
AppExchange rationalisation. Audit all installed AppExchange packages. Are they all still used? Are they compatible with current API versions? Could any be replaced with standard Salesforce features or custom development?
Platform extension. Rather than building everything inside Salesforce, build external applications that connect via API. Customer portals, partner portals, complex reporting, and high-volume data processing often work better as separate applications — and don't cost per Salesforce user licence.
Apex code debt. Mature Salesforce orgs accumulate Apex triggers, classes, and batch processes written by different developers over years. Common problems: overlapping triggers, unused code, hardcoded IDs, missing test coverage, and deprecated API references.
Flow governance. Salesforce Flow has become very powerful, which means Flows can now be as complex (and as fragile) as Apex code. Without governance — naming conventions, documentation, version control, testing — Flow automations become a maintenance nightmare.
Integration sprawl. Each integration point adds maintenance overhead:
Data model complexity. Custom objects, custom fields, and relationships proliferate over time. Without a data architect reviewing the model periodically, the schema becomes increasingly messy and queries become slower.
Untested, undocumented Apex is a liability during every release.
Ungoverned Flows create the same problems as ungoverned code.
Each integration is a potential point of failure during releases.
Per-user costs add up. Regular audits prevent overspend.
The more you build in Salesforce, the harder it is to leave.
Three major releases per year (Spring, Summer, Winter), plus continuous patches. Each release can introduce new features, deprecate old ones, and change API behaviour. You get a sandbox preview period, but the releases roll to production on Salesforce's schedule.
Apex governor limits, API versions, and platform behaviour can change between releases. Well-written Apex usually survives, but code that relies on deprecated APIs, hits governor limits, or uses undocumented behaviour can break. Test in sandbox before every release.
It depends on what you're using. If you're paying Enterprise or Unlimited prices but only using basic CRM features, you're likely overpaying. Conversely, if you're using the full platform (Apex, Flow, custom objects, integrations), the value is usually there. A licence audit can identify waste.
Flow for straightforward automation and business logic that non-developers should be able to modify. Apex for complex logic, high-volume processing, and integrations that need precise control. Most environments use both. The mistake is using Apex for simple things or Flow for complex things.
We can help in two ways. First, by auditing your licences and usage to find waste. Second, by replacing expensive Salesforce add-ons with custom-built alternatives where appropriate — some AppExchange packages add thousands per month when a custom solution would cost a one-time development fee.
Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.
