Lookup vs Master-Detail Checklist

Moving custom object data from a Lookup Relationship to a Master-Detail Relationship is no easy task. Having the ability to use Roll-Up Summary values on the custom object far outweighed the effort required for the data transition.

I was hesitant to make this change because it sets off a domino effect in the Org. However, the number of reports and inability to roll up a great deal of data, was starting to effect the ability of the team to prospect strategically and analyze results. I've put together a checklist below to help those that are considering making the same update.

First...PLAN, PLAN, PLAN!

I planned out the data migration for three months. I started by having an open dialogue with my users on all of the data they wanted to gather from the custom object and what would help them take that data to the next level of analysis. I call this 'The Give, to Get.' Identifying the reasons we needed to give up the old object and highlighting all of the new capabilities we would get with the new object, allowed users to embrace the change rather than fight it.

The next major step is logging a case with Support to enable Create Audit Fields. This allows you to migrate the CreatedDate of your old object to your new object. This can be done on the following objects: Account, Opportunity, Contact, Lead, Case, Case Comments, Task, Event, Idea, Idea Comments, Campaign Members and Custom Objects. Remember this is Insert only, you can't update the field if you forget.

Set up a timeline for the migration and alert/remind users. One of the biggest steps is to remove Edit and Create access to your old object, before you export the old object data. Sending a reminder to users that you are doing this so the team can plan ahead, is a best practice. Even doing so, expect a few to come to you wondering why they can't make changes. Remind them of the project and that you don't want them making changes that won't show up in the new object. Performing this data migration during off hours is another way that you can minimize the impact to your team.

Make sure that you save a full export of all the old object data with your SF Export logs, so that you can reference or recreate, should something go wrong. If you're not saving weekly export logs of all your Org data - you should start doing so now. It's very expensive to have SF roll back the clock, should a user compromise your data (revisit object permissions as well to determine when users should have Delete and Modify All access to minimize this situation).

I would highly recomment that if you are also updating some field names in the new object, that you save the mapping in Data Loader in case your insert contains any errors that need to be processed again. As a best practice, I include the word 'Date' at the end of any Date fields, so that there's no confusion on field type when reporting and it becomes easier to locate those fields when building a report by typing in 'Date' into search.

You will need to enable access to the new object for each profile. You can set this up ahead of time when creating your Tab. Hold off on making the Tab visible to all until you've tested and validated that all of the old data is now on the new object. I would recommend keeping the old object behind the scenes in SF for the next week-30 days before removing. That way if something does go wrong in the transition, you can temporarily open up access to the old object. Just remember that you will need to update any new data.

Other items to consider include any Validation Rules and Workflow Rules that you had in place for the old object. Those will need to be created for your new object. Optimizing the Page Layout, Search Layout fields and creating Custom Views on the new tab, will help ensure a successful rollout of your new object. Use this as an opportunity to review the fields that are being populated to see if there is any data that can be automated. Include help text whenever possible to help guide your users. Your new object can be a great opportunity to correct old mistakes. Take advantage of that and the result will provide users with a much improved UI and UX.

Creating new Reports and updating Dashboards with your new Object is going to be critical to the adoption for your new object. Remember, when you fully remove the old object, any reports relating to that object are no longer going to be valid. A best practice is to remind your users of this when alerting them that the migration is complete and include links to several template reports that they can customize for their needs. An added bonus, you can gather all of the impacted reports and remove them from your Org. Think of it as quality control and a little early Spring cleaning!

Lastly, if you are using any Apps like Conga, you will need to create new templates that map to your new object data. Identify any affected templates during the planning stage. Make sure that your rollout provides time to migrate the data and swap in the new templates on the same day. You don't want to create a situation where Conga templates are pulling in old data and a user can't understand why it doesn't match updates made to the new object data in Salesforce.

It's a lot to consider and it's a lot to update. Just as you remind your users of all the benefits, remind yourself. This project update will ultimately make reporting easier. It will create the ability to roll up data without the usage of Triggers or Apps. Most importantly, you only need to do this ONCE! After that, you're off and running with your new custom object.