Data quality is determined by 3 key factors: Accuracy, Completeness and Relevancy/Validity. Data Quality is the most important aspect for any enterprise as it enables a business to make more informed decisions, better audience target, effective usage, and better user experience.
As an enterprise, any opportunity to improve on Data quality should be leveraged and Data Migration is one the best time to do a reset and clean the data. So let’s look into what are a few common data quality issues and how we deal with them when using Dynamics 365. Continue reading “Data Migration Part IV : Data Cleansing”
As Antoine de Saint-Exupéry said, “A goal without a plan is just a wish.” In terms of Data migration that is so true, according to Gartner, 83 % of data migrations fail outright or exceed their allotted budgets. A lot of this failure is attributed to a lack of planning.
Analysis of data migration projects over the years has shown that they meet with mixed results. While mission-critical to the success of the business initiatives they are meant to facilitate and support lack of planning structure and attention to risks causes many data migration efforts fail.
— Gartner, “Risks and Challenges in Data Migrations and Conversions,” February 2009, ID Number: G00165710
In the last blog, I mentioned about Data Migration stages. In this blog will do a deeper dive and look in the first 2 stages, So let’s talk about what planning and Evaluation look like.
- Data Sources: Identify all different data sources for Data migration, often time Dynamics 365 implementation replaces more than one applications as such you might be migrating data from multiple applications.
- Data Quality: it’s important to analyze the quality of data at the source to avoid Garbage In, Garbage Out. Some of the common quality issues are
- Inconsistent and incomplete Data: inconsistency is a big indicator that there’s a data quality problem. When data has not been entered in the system correctly like missing zip code, province or other information remaining data could be of less value.
- Duplicates: In many circumstances, the same records might exist multiple times in a database, Common culprits are Account, Contacts.
- Inconsistent Formats: if source application did not have much validation the data will have more typos of errors, Address is the most common place to find with City and provinces being named differently.
- Obsolete Data: Every day, people move, marry, and change their names. Since Peoples’ information is rarely static, obsolete data is a common challenge which is hard to rectify as well.
- Data Volume: Volume of Data could be a key factor in determining Data migration Tool/Process and the Deployment Plan.
- Operational Data vs Archival Data: Legacy applications when replaced will often have a lot of historical data, you might not want to bring all of this data into Dynamics 365 as this data might be not be used for day to day operation but useful for Data Analytics and Reporting Purposes. Identify what data needs to be in Dynamics 365.
Continue reading “Data Migration Part II : Evaluation & Planning”
Data migration is often overlooked in Project implementation primarily because the project team is focussed on application development and customization which takes away the priority of data integration and data migration. As data migration is planned to be the last activity on the project it also gets most impacted from any budget cuts and application scope increase.
Talking about the budget, many implementation’s approaches to data migration is for data migration to be done using the Import and Export feature of Dynamics 365 CE over the weekend before Go Live, this works sometimes but is a recipe of disaster in most cases.
When implementing Dynamics 365 Project, configuration and customization to meet the users need is only half the battle. Data migration is key to getting the right head start for users to start using the application. In this blog series, I will focus on data migration, the challenges, strategy, Process, Tools and my own learnings over the years. Let’s start with what is Data migration?
Continue reading “Dynamics 365 : Data Migration demystified-Part I”
It’s been a more than a month since legacy Adxstudio portals support officially ended. Many customers and partners are still using Adxstudio Portals and yet to migrate to Dynamics 365 Portals or its short-term alternatives( Microsoft Open Source Portals, xRM Portals Community Edition).
As there are multiple Portals available, there is always a question on which one to migrate to, we currently have 4 different versions of Portals:
- Dynamics 365 Portal Capabilities is the only viable long-term option, it’s Dynamics 365 Online dependent and only available as Software as a Service solution. This is the version you want to be using.
- Microsoft Open Source Portals is the 8.3 version of Dynamics 365 Portals, it’s completely open sourced and released under MIT license. This is a one-time release and no future bug fixes, updates or patch will be provided. It is suited as a stepping version before upgrading to CRM Portals. I wouldn’t recommend being on this version unless you and your team has an in-depth understanding of the Portals and can self-support.
- xRM Portals Community Edition is the githubbed version of Microsoft Open Source Portals, it is hosted by KPMG Adoxio and supported by Adoxio and Portals community, This is the version for customers or Partners who need sometime before moving to Dynamics 365 online or are waiting for new releases/features on Dynamics 365 Portals. This is not an on-premises option for Dynamics Portals but a short-term interim self-hosted option.
- Adxstudio Portals, Though the support for Adxstudio Portals has ended, if you happen to have a perpetual license you may continue to use the product knowing it’s not supported.
The only long-term option is to upgrade to Dynamics 365 Portals. Dynamics 365 Portals and AdxStudio Portals don’t have same Portal website offering, some of the key differences are:
Quite often we run across a Dynamics 365 implementation where not much thought was giving to Document Management while implementation, resulting in user using Notes(Annotation) entity for document management.
Notes do offer a lightweight solution for managing and uploading documents to related record but it lacks the capabilities of a full-fledged document management capabilities. Notes are also stored in CRM database, storing documents as notes could easily become a costly endeavor considering Dynamics 365 storage cost. Jukka Niiranen has written a great blog on file storage and disadvantages of using Notes/Annotation.
The first step to transition from using CRM Notes to SharePoint for document management is migrating existing documents from Notes to SharePoint. This may seem like a daunting task but could easily be accomplished using SSIS package for migration.
I have an SSIS starter project on GitHub which illustrates the migration for notes related to Case entity, It could be easily configured to migrate notes related to any other entity.
SSIS by itself doesn’t provide capabilities to connect with Dynamics 365, for this, we use a third-party connector like KingswaySoft or CozyRoc, in below example we are using KingswaySoft connector, license and pricing details could be found here. Kingsway does provide the developer license free of cost.
Continue reading “Migrate Dynamics 365 Notes Attachments to SharePoint”