Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Salesforce Architect
hard

How do you architect Salesforce so it survives an organisational acquisition?

Acquired companies are common — sometimes you're acquired; sometimes acquiring. Architecture should be adaptable.

Resilience principles:

1. Avoid hardcoded org-specific assumptions.

  • No hardcoded org IDs.
  • No hardcoded user IDs.
  • No hardcoded record types.
  • No hardcoded picklist values in code.

2. External Id strategy.

  • Every important business record has External Id.
  • Migration to new system uses External Ids, not Salesforce Ids.

3. Configuration over code.

  • Custom Metadata for business rules.
  • Easier to migrate / re-configure.

4. Standardised integrations.

  • Use standard patterns (REST, Pub/Sub).
  • Avoid proprietary cartridges of older systems.

5. Version-controlled metadata.

  • Source-controlled in Git.
  • Reproducible org from source.

6. Documented architecture.

  • Architecture diagrams.
  • Data model documentation.
  • Integration map.

7. Decoupled custom features.

  • Modular Apex / LWC.
  • Easy to extract or migrate components.

8. Avoid over-customisation of Industry Clouds.

  • Heavy customisation locks you into the Industry Cloud roadmap.
  • Plain Sales/Service Cloud + custom = more portable.

Acquisition scenarios:

You're acquired:

  • Acquirer may want to consolidate Salesforce orgs.
  • Or keep yours separate.
  • Architecture should support both.

You acquire someone:

  • Their Salesforce org may consolidate or stay separate.
  • Integration architecture matters.

Both stay separate (multi-org):

  • Mulesoft / iPaaS for cross-org.
  • Shared customer data via Data Cloud or warehouse.

Common acquisition patterns:

  • Consolidate over 12-24 months — typical.
  • Keep separate forever — when business units autonomous.
  • Run parallel during transition — full sync.

Architectural moves:

1. Reduce hardcoded dependencies.

When refactoring, swap hardcoded assumptions for configuration.

2. Maintain documentation.

Acquirers / integrators need to understand quickly.

3. Use Unlocked Packages.

Modular distribution; easier to migrate components.

4. Standardise on Salesforce best practices.

Common patterns are easier to integrate / migrate than custom approaches.

Senior architect insight: architecting for acquisitions is mostly architecting for portability. The same practices that survive acquisitions also survive technology shifts, M&A, regulatory changes.

The senior framing: good architecture is rarely about the current state; it's about adaptability to future state.

You don't know what the future holds, but you can build to absorb change.

Why this answer works

Senior architecture. The portability principles and "adaptability over current-state" insight are mature.

Follow-ups to expect

Related dictionary terms