My team is tasked with merging three different Salesforce instances into one global org. It sounds like a nightmare, and I am worried about data collision and user permission silos. What are the architectural red flags I should be looking for before we start moving anything?
I am particularly worried about sharing rules and how to unify disparate custom objects that serve similar purposes but have different fields. Any war stories or tips for a smoother consolidation would be great.
Successful multi-org Salesforce consolidation requires a rigorous audit of metadata dependencies, a transition to permission-set-based security, and the establishment of a canonical data model before any record migration occurs.
6 answers
You should address the following architectural risks systematically before migrating any data records to the target instance.
- Document every dependency between custom objects and existing record-triggered automation.
- Standardize your permission sets by moving away from profile-based object access entirely.
- Identify shared objects and establish a single source of truth for the field schema.
- Evaluate the impact of sharing rules on existing apex managed sharing records.
- Audit all hard-coded references to record IDs or specific object prefixes in your codebase.
The primary architectural red flag in a multi-org merger is failing to perform a comprehensive metadata impact analysis before attempting to unify disparate custom objects. When objects serve identical business functions but possess divergent schemas, you must prioritize a canonical data model design rather than forcing a simple lift-and-shift of fields. Neglecting to map these technical intersections invariably results in brittle integration points that collapse under the weight of global user permissions.
I once saw a project fail because the architects assumed they could just rename custom fields to fit a unified object model without remapping the underlying Apex and Flow dependencies. We spent three months in a recovery sprint after the first pilot because every single automation triggered a field-level security error. It was like trying to perform a heart transplant while the patient was running a marathon.
By the time we got the permissions synced, the business had lost all faith in the platform. Do not underestimate the hidden technical debt living in your existing validation rules and hidden dependencies.
Choosing between a clean-slate global schema and a merged aggregate approach involves distinct trade-offs. A clean-slate design is superior for long-term scalability and reporting consistency but necessitates heavy refactoring of legacy business processes. Alternatively, an aggregate approach allows for faster migration timelines but forces you to maintain technical debt in the form of unused fields and overly complex sharing rules. You should opt for the clean-slate route if your organization plans to support cross-functional business processes within the next two years.
Stop worrying about the mechanics of moving data and start worrying about the logic of your access control. If you do not standardize your security architecture into permission sets before you even touch the object schema, you are walking into a disaster. You will end up with security silos that make global reporting impossible and audit compliance a nightmare. Just fix the security model first, or do not bother with the migration at all.
To approach this effectively, you must first define a clear migration strategy that treats metadata parity as the foundation of your global org. One of the most dangerous oversights during consolidation is failing to reconcile the divergence in custom field definitions across the three source instances. When three teams have built similar functionality with different validation rules, required fields, and picklist values, you cannot simply merge them into a single object without first harmonizing the underlying data requirements. If you attempt to migrate data directly into a unified object without standardizing these definitions, you will immediately trigger validation errors that are nearly impossible to resolve in a post-migration state.
Furthermore, you need to conduct a thorough audit of your security architecture. Multi-org environments often have disparate profiles and sharing models that do not translate cleanly into a single unified security policy. You should prioritize the transition to a permission-set-based access model, as this allows for greater granularity when managing users who previously operated in siloed orgs. Relying on legacy profile structures will only deepen the fragmentation you are trying to solve. By standardizing your security protocols and object schema before you migrate a single record, you minimize the risk of collisions and ensure that your consolidated environment is stable and maintainable from day one.
