{"id":117,"date":"2026-08-06T00:12:49","date_gmt":"2026-08-06T00:12:49","guid":{"rendered":"https:\/\/oranovasolutions.com\/blog\/?p=117"},"modified":"2026-08-06T00:13:25","modified_gmt":"2026-08-06T00:13:25","slug":"what-happens-during-a-dynamics-365-discovery-phase","status":"publish","type":"post","link":"https:\/\/oranovasolutions.com\/blog\/what-happens-during-a-dynamics-365-discovery-phase\/","title":{"rendered":"What Happens During a Dynamics 365 Discovery Phase?"},"content":{"rendered":"
\n
\"\"<\/figure><\/div>\n\n\n

The discovery phase of a software implementation project actually kicks off before the client and their partner agree to an initial scope of work: ‘phase 1’, if you will. It’s often the case that some discovery gets completed before the Statement of Work is signed because a rough scope outline is critical to estimate the project cost (for time & material projects) or agree on a total price (for fixed price projects). Generally, this pre-signature discovery will be more detailed for Fixed Price projects because the scope of work is what decides the total contract amount. However, we’re a long way from done with discovery at this point. What comes next is arguably the most important part of the entire project!<\/p>\n\n\n\n

A poor discovery phase can ruin your project. We’ll be that blunt about it. Oranova’s team brings a lot of experience to the table. Along with that comes some lessons learned the hard way. A poor discovery phase is how companies can get 3 months into a project and ask, ‘so when does (insert critical step in the process) get built?’ and their partner just stares back at them like a deer in the headlights. This is exactly what we’re hoping to avoid with a thorough discovery session.<\/p>\n\n\n\n

Our opinion is that a good discovery phase is made up of the following components:<\/p>\n\n\n\n

    \n
  1. Understand your current process.<\/strong>\n
      \n
    • We need to understand how things work today to properly scope the project. This includes the ins and outs of the system we’re replacing along with some basic details about the systems it touches, and anything that is still done manually in excel or email. This is our starting point.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
    • Understand your pain points. Why are you migrating to Dynamics 365?<\/strong>\n
        \n
      • Why are you considering a migration onto a new CRM or other Dynamics 365 app? We most commonly see migrations occur because the current tool is not flexible enough, is too expensive, or is being retired (sunset). Recently we are seeing an increase in upgrades to Dynamics 365 \/ Power Apps because of the platform’s direct integration with Copilot\/Copilot Studio, and native AI development capabilities.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
      • Identify where we want to be at the end of this project. What should the end result look like?<\/strong>\n
          \n
        • Tell us your requirements and let us help solution. Instead of ‘We need a button here to send order data to finance’<\/em>, try ‘communication is not great between sales and finance once projects get closed. We would like to improve this’<\/em>. Dynamics 365 apps contain a lot of functionality out-of-the-box, and we can often utilize said functionality to avoid customization. The first solution that comes to mind is often not the most efficient of maintainable.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
        • Define the detailed scope. This can take a while.<\/strong>\n
            \n
          • We like to get pretty granular here because it’s so crucial. This is the step that is often skipped or rushed because it can be time consuming. At Oranova, we’ve found this is the most critical step in determining alignment between the client and partner.\n
              \n
            • Instead of “We know we need a one-way integration from our HR software into our new Dynamics 365 app”<\/em><\/li>\n\n\n\n
            • We would shoot for something such as: “One-way integration from our HR software that exposes an API we can connect through. We want a scheduled integration that runs once per hour. There will be 3 tables included in the integration. It should perform updates and creates but doesn’t have to handle deletes. Any errors should be logged so a system admin can review them. We expect to integrate roughly 25 fields in total.<\/em>“<\/li>\n\n\n\n
            • The latter allows us to measure cost and timeline impact of this task much more accurately, leading to better alignment between the teams.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • Build and prioritize the backlog in a tool such as Azure DevOps.<\/strong>\n
                \n
              • Oranova is flexible on the backlog management tool used. We prefer Azure DevOps, but we’ve also used tools such as Jira and SmartSheets.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
              • Estimate each backlog item.<\/strong> \n
                  \n
                • We want an estimate of how long each item will take. This falls more on the Oranova team than our clients because we know the platform inside and out. We also like to categorize the backlog here because some items need to be completed before others. For example, all configuration for a given table must be complete before data can be migrated into that table.<\/li>\n\n\n\n
                • Some common backlog item categories we use at Oranova:\n
                    \n
                  • Configuration<\/li>\n\n\n\n
                  • Data migration<\/li>\n\n\n\n
                  • Data integration<\/li>\n\n\n\n
                  • Security<\/li>\n\n\n\n
                  • Reporting<\/li>\n\n\n\n
                  • Custom Development<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                  • Identify risks and decide how to handle them.<\/strong>\n
                      \n
                    • What risks could prevent us from meeting our deadline or budget.<\/li>\n\n\n\n
                    • How can we mitigate these risks?<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                    • Given the agreed upon backlog and estimates, determine the Project timeline.<\/strong>\n
                        \n
                      • This includes:\n
                          \n
                        • When will the initial development<\/strong> be complete?<\/li>\n\n\n\n
                        • When will development unit testing<\/strong> be complete?<\/li>\n\n\n\n
                        • When will our Conference Room Pilot<\/strong> take place?<\/li>\n\n\n\n
                        • When will User Acceptance Testing<\/strong> take place?<\/li>\n\n\n\n
                        • When will we go live<\/strong>?<\/li>\n\n\n\n
                        • What is the expected hyper care<\/strong> support window<\/strong> after go live?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                          Sometimes we have an increase in scope during the discovery phase. For example: We agreed in the Statement of Work that we don’t need to migrate historical Opportunities into our new CRM. But during discovery we learn that historical Opportunity data is a critical prerequisite for downstream processes that are in scope. In this case, we may need to add a change order to bring the Opportunity migration into scope. We would rather learn this during the discovery phase than later on in the project. Sometimes we see the reverse happen too. Once a thorough discovery is completed our clients will determine that the project scope has grown too big for the initial go live. In this case, we can just as easily cut the scope down.<\/p>\n\n\n\n

                          At this point, a good thorough discovery has been completed. Now we move right on to the build phase!<\/p>\n","protected":false},"excerpt":{"rendered":"

                          The discovery phase of a software implementation project actually kicks off before the client and their partner agree to an initial scope of work: ‘phase…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,10],"tags":[2,3,9],"class_list":["post-117","post","type-post","status-publish","format-standard","hentry","category-blog","category-how-oranova-operates","tag-dynamics-365","tag-power-apps","tag-software-implementation-process"],"_links":{"self":[{"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/posts\/117","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/comments?post=117"}],"version-history":[{"count":46,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/posts\/117\/revisions"}],"predecessor-version":[{"id":166,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/posts\/117\/revisions\/166"}],"wp:attachment":[{"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/media?parent=117"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/categories?post=117"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oranovasolutions.com\/blog\/wp-json\/wp\/v2\/tags?post=117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}