How would you design Apex code for an org that may be acquired and migrated to a different Salesforce instance?

Org migrations (M&A, divestiture, consolidation) are major events. Code that's designed with portability in mind survives; tightly-coupled code becomes a rewrite cost.

Portability principles:

1. Avoid hard-coded record IDs. Use Custom Metadata or a setup utility to look up Ids by Name or DeveloperName at runtime.

`apex // BAD String hardcodedId = '0H012000000RecordTypeXYZ';

// GOOD Id rtId = Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName().get('B2B').getRecordTypeId(); `

2. Avoid hard-coded usernames or User Ids. Lookup by Federation ID or by an Integration_User__c custom setting.

3. External Id fields on every business record. Use a stable external identifier (provided by source-of-truth system) rather than relying on Salesforce Ids. When you migrate, external IDs translate; Salesforce Ids don't.

4. Configuration-driven endpoints. Custom Metadata for integration endpoints, not hard-coded URLs.

5. Generic schema where possible. A "Tags" custom object generic enough to be recreated in any org, not deeply intertwined with proprietary objects.

6. Avoid managed package references that won't follow. Acquiring org may not have your packages installed.

7. Documented integration contracts. When integrations resume in the new org, the contracts (events, schemas, endpoints) must be re-pointable.

8. Source-control everything. Git repository with the org's metadata is the migration starting point.

Migration playbook (high level):

1. Inventory — list every customisation, integration, automation in the source org.
2. Categorise — what migrates as-is, what needs adjustment, what's deprecated.
3. Data migration — define the External Id mapping. Plan the order: parents before children.
4. Sandbox stage — deploy code + load data into the target's sandbox; validate.
5. Cutover — coordinated event: freeze source, migrate data, deploy code, validate, route users to target.
6. Rollback plan — for the cutover, define what triggers rollback and how.

Longer-term resilience:

• Avoid org-Id-encoded magic in code (if (UserInfo.getOrganizationId() == '00DXXXX')).
• Test in clean orgs periodically — catches drift toward "only works in our org".
• Modular packaging — Unlocked Packages for portable modules; reduces "will this even compile elsewhere" risk.
• External orchestration for cross-org workflows — survives an org migration because the orchestrator persists.

The senior insight: write Apex as if the org might be rebuilt from scratch tomorrow. Most of these principles are good practice anyway; portability just enforces them.