Research Saved on Early Bound OrganizationServiceContext from CRM Answers

Just spreading the love on this great explanation about Early Bound entity use. I am working on the creation of a xRM portal and was having trouble with the maintenance of the data between pages, and across the site, then realized I was not using the OrganizationServiceContext. Which does this automatically for us. A great YAY, but Duh moment for me.



Just wanted share what I found. This post says better than I could. I recommend anyone to follow Guido Preite. There have been several times I am searching for an answer and find something good, just to look and see it is coming from Guido. (No I do not have a man crush). Have a wonderful day!



Get the Id of records created using Early Bound OrganizationServiceContext ~ CRM Answers

Data Migration Migraine

Who's your Data?

While the focus of this article comes from Microsoft Dynamics CRM experience. I believe these tips are very useful for any data migration. I have applied these to Kentico, Dynamics SL, SharePoint and other business system data migrations. However, I have been fortunate to go through data migration into Microsoft Dynamics CRM Online four different times.

• Oracle to Dynamics CRM 2011
• CRM 2011 to CRM 2013 Re-implementation lateral shifting of data
• SalesForce to CRM 2013
• CRM 2013 to CRM 2015 Split off business unit components in xRM Re-implementation

The beginning of any CRM data migration is knowing where your data is coming from. Success in data migration comes from Careful Planning, Complete Testing, and Continuous Validation post go-live.

Careful Planning

Break out the excel spreadsheets and exports of metadata from the system. Throw out assumptions of what the data is intended for and open up to the variations in what the data actually is and how the system displays the data. Quick tips for this stage.

1. Listen to the business requirements. I mean really listen for key words that give insight to how the business applies that data to their work.
2. Question the business requirements. This comes up when trying to determine the relevance of old data, or the necessity of current field mapping complexity. With an earnest desire to understand ask "When was the last time this data was used for a business decision?" Once you understand data from that angle your migration planning will take shape and allow you to make better judgement calls in the design. 
3. Get the facts on the data. Just because the business uses this one field for Money values does not mean it is a decimal, it also does not mean it is a Money field in CRM either. Use the XRM Toolbox to export metadata from CRM.  Use other tools to get to the metadata in other systems. 
4. Leave some breadcrumbs. Duplicating some fields to track legacy values, especially unique ID's in the other system are essential to validation and troubleshooting after the dust has settled. It may seem less is more, but in data more is more, and storage space is cheap, especially when compared to the man hours needed to find legacy data without a matching KEY. 

Complete Testing

This can not be stressed enough. Every mistake I have made I can trace back to incorrect testing, or assumptions that were not clarified during testing. 

1. Fake Test data gets you fake results. Several times we have tested using data we made up to represent opportunities, or accounts. But we failed to realize we knew what fields were needed and values accepted, so we created records that would pass. Of course we made variations to try different expected scenarios. However, real data does not care what we think it should have or not have. Real data has '*' symbols in the phone number, and option set values that have symbols in them, or blank values on that field that has "always" been required and will never be empty. Of course run the first tests with fake data to get close, but run majority of your testing through the migration of real data into a test environment. 
2. Involve the users early. The business will know what an account should look like, or what relationships they expect to see on an opportunity. Use their skill and experience to speed up the testing process. Create documentation to make it easy for them to review without taking them away from their duties too long. Gather them together in one meeting to avoid multi-tasking and incorrect assumptions to what is wrong. 
3. Be thorough and do not skip a field, or entity believing it to be insignificant. I have found entities that were believed to not be used, but were actual cross references required for other functionality to work. 

Continuous Validation

Initial validation may look like reports are verified matching in new and old system, and the business stakeholders sign off that all records are there and essential requirements are met. After all this is the time to keep pushing with the admin team to spot check and monitor those high impact relationships. Having legacy fields as placeholders for data is helpful to perform these checks. 

1. Set the legacy fields to be open strings that accept any type of data, then run reports comparing the legacy field with its system/db field counterpart. This will show where data was in the legacy field but not in the new field, or the data that was in legacy field shows decimals and the new field rounded them
2. Create new don't modify. When validation shows errors in field formatting, make sure to create a new field and move the data again for that field. Or check with SQL admin to verify the change will update existing content. Do not assume because the field changes from Decimal to Integer that the trailing zeros after the decimal will be trimmed off. We want to avoid having some data formatted incorrectly, and some correctly. 
3. Don't throw the database out with the schema. If your mapping shows incorrectly for a few fields take a breath and find out if you can just change those field, and remap only that segment. Validation is a living breathing process that must continue for some time after go-live, so do not think because one or two fields are wrong the whole migration went wrong. (But don't think it didn't either)

I am sorry this is longer then I planned. The true purpose of this article is to provide encouragement and clear direction to areas that tripped me up in the process. Above are hidden parts that take time and experience to uncover.

Below, I posted the links where I found useful information in the CRM projects. So I am hoping to save you time in searching, and offer tips along the path.

• Of course start with the official Microsoft CRM Implementation Guide and the CRM SDK. If you are not migrating CRM Data most business systems have implementations guides refer to those. They have basic data maps that can help get started. These maps help save time when creating the data mapping documents. (Do NOT skip the data mapping documentation process.)
• Microsoft offers a CRM Online Data Migration Tool.
• An older post from Power Objects but still relevant for data migration tips.
• Setting up easy to use Data Import Templates which you can manage in Excel.
• I have used both Scribe Insight and Scribe Online. Scribe main website
• Webfortis has a great blog on deciding on Insight vs. Online. 
• I have used SSIS for integrations but I have not used this for CRM or migrations so I will leave that one alone. If you are looking to go that path, here is a good place to start; Data Migration/System Integration by Andre Margono.

Please reach out if you have any questions or feel stuck. I find luck is directly proportionate to my attention to detail. Have a wonderful day!