3

My company has 2 Salesforce instances. We built our own instance, and then acquired a company that had a completely different set of nomenclature, routing rules, etc. Both have years’ worth of data in them. We have all the normal issues - duplicative license fees and routing costs, lack of sharing of leads and automation across instances, etc. In addition, both have different workflow with other third party systems (billing, custom scripts, etc.)

What steps should I take to avoid problems when conducting this merge?

  • Is your goal to end up with both instances running as they currently do in the one remaining instance or to rework all the data from both into one org and keep just one set of lead routing rules, workflow rules, etc... ? – Daniel Ballinger Aug 16 '12 at 23:50
1

One of the critical things that you need to do is go through a thorough data mapping exercise. You don't simply want to add all of their custom fields to your objects because you may already have appropriate fields for their data. Keep your database as consolidated and tidy as possible.

I would NOT simply migrate code and workflows over to your org. You run the risk of implementing incompatibilities that are hard to debug. Instead, map out their logic, see how it aligns with yours, then implement the deltas in stages using a sandbox. Push small changes to production over time.

Make sure you come up with some regression testing plans for your current org so you can continually verify that these new changes are not breaking your existing functionality.

Oh, and also, be patient and take your time. :)

1

You should consider different topics:

  1. Master-Data merge
  2. Extract-Transform-Load (ETL) processes from one org to the other
  3. Business process integration
  4. Integration of external systems
  5. User training

Master-Data

In general we can assume that the data model differs. Therefore the existing data models have to be compared and merged into a single model.

Suggestion

List all existing fields and objects (add a description) and create a mapping between the data models.

ETL

The extraction, transformation and loading of data from one system into the other is another topic to consider. You should make sure that the users can work with the “new” and merged system without shutting the system down for several days. Therefore you should plan the data migration upfront. It is crucial to test the migration.

Suggestion

Import the data into a full sandbox, use a tool which allows you to reproduce and automate the migration.

Business process integration

It is important for the users that they can execute their tasks with the new system. Therefore custom processes should be implemented in the new system as long as the process is used. This is a great opportunity to get rid of unused or rarely-used functionality.

The implementation of regression test and the documentation of functionality is another aspect of a successful project.

Integration of external systems

Existing integration with other systems might be the biggest issue. Be aware that new data and processes can affect salesforce and other integrated systems. Therefore the only chance to void issue is testing.

User training

Besides from the technical perspective, salesforce is a socio-technical system and the user is one of the most important part of the system. The merge of two orgs changes the way people are working. Therefore user-training and the distribution of information is important.

0

based on your description I would take the approach of migrating the data and code over from one of the orgs over to the other. For those workflows that you do not want to merge, create record types to differentiate the workflow per object between orgs and modify any trigger/apex code to recognize which record type is in use. You can use profiles to assign defaults to make the use seamless between the two different business units.

0

If the target org does not have Multiple Currencies enabled, make sure you turn that on first. In any case where you're planning to import a lot of data and you think you might want MC later, it's easier to turn it on first, since time to turn it on scales with number of records.

0

As the other respondents imply, merging salesforce instances is not a trivial exercise. We've done it 5 times for different customers. The most recent exercise involved 93K Opportunities and a lot of complex functionality and code that had to be ported across. It took 25 days of effort.

We've written a blog post, 10 Tips to Merge Salesforce Environments that you might find useful.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.