Salesforce.com Org Consolidation
For large national and international clients, we often find companies with multiple instances of salesforce.com. In salesforce.com "speak" each instance is referred to as an "org" which is short for "organization". These independent orgs arise most often as a result of mergers and acquisitions where one company using salesforce.com purchases another using salesforce.com. In other cases, large organizations will deploy separate orgs overtime for each country, divisions or business functions. This article addresses briefly some of the considerations for clients with multiple instances on whether to combine orgs or leave them as independent. If you are considering create an incremental instance of salesforce.com, this article is also for you.
Pro's of Maintaining Separate Orgs
- Less time is spent seeking "agreement" from one country or department to another to make changes
- More rapid initial deployment
- No risk of impacting another group when you make changes
- Can be on different editions (e.g., One group could be on Professional Edition and another on Enterprise Edition)
Con's of Maintaining Separate Orgs
- Potential for duplicate license costs if users need to access both orgs
- No ability to run consolidated reports
- No ability to assign tasks across groups
- Duplicate data and inability to keep data consistent across orgs
- Greater costs to set up similar processes/fields in both systems
- More difficult to manage
- Why are the orgs being combined? What are you hoping to gain from doing this?
- How many orgs are you consolidating?
- What are the editions of each org? (Professional, Enterprise, Unlimited, etc.)
- What UIs are in place (Classic or Lightning Experience)?
- How many licenses are in each org?
- Is the sum of the licenses the correct number (including by license type)?
- Will there be any changes (additions/subtractions) to the number and types of licenses?
- What third-party apps are installed in each org and which will continue to be used? (include expiration/renewal dates)
- Will there be adequate data and file storage? (we will do a storage evaluation as part of the org inventory)
- Does client have a pre-determined "surviving org"?
- Will all data be consolidated or only certain objects and records?
- What duplicate issues will arise (are there similar or same records in both orgs)?
- Are there integrations or workflow automations in place with either org? (we will need to understand to avoid unintended results)
- Is client satisfied with current levels of user adoption or are we using this project to improve results?
- Will all users (all orgs) need training, or only users from org being moved?
- Will stage histories or changes histories need to be preserved?
- Considerations for private views, reports and dashboards
- Will system audit fields (created date, created by, last modified, last modify by) need to be preserved?
- How will we treat inactive users in the project as far as assignment and system audit fields?
- Are the sharing models the same or do we need to update sharing rules for the combined entities?
- How will special features like multi-currency, territory management or multi-language be deployed if at all?
- What is the desired timetable for the project?
- What people resources does client desire to have involved in project?