Microsoft FastTrack for Dynamics 365 – Lessons Learned

In this blog post, we will discuss in detail some of the lessons I learned while migrating CRM on-premise to Dynamics 365 online using FastTrack for Dynamics 365.


I can’t stress enough on the importance of planning because it is crucial to ensure a successful migration, from start to the end, including user training, adoption session and even a rollback strategy in case anything goes wrong.

In addition to this, you should ensure a smooth and seamless migration by performing several test runs before the actual production migration. It will not only give an idea of how long the actual migration will take but also, it’ll give everyone involved in the migration process the confidence by going through different steps and stages.

Plug-ins and Workflows

During the pre-requisite stage of FastTrack for Dynamics 365, make sure to review and run all the plug-ins and custom workflows through the validation service and fix all the identified issues. Since most of the Software Development Kits (SDK) related API calls have been the same since 2011, there wouldn’t be a lot of changes required.

The important thing to note here is that in Dynamics 365 online, all plug-ins and custom workflows/actions run in Sandbox mode which has an execution time limit of two minutes, so make sure that the execution completes before that time.

Also, this can be a great opportunity to see if some plug-ins or workflows can be removed or converted to out-of-the-box functionality or low code/no-code approach. Flows/Logic Apps and Azure Functions can also be evaluated for certain case scenarios.

Async Operation Table

Since the FastTrack for Dynamics 365 process requires uploading the actual database to Azure Blob storage, minimizing and cleaning the database can be very beneficial as it will certainly reduce upload time.

In addition, make sure that you enable compression during SQL Server Backup process. This will give an output of a smaller .bak file as compared to the uncompressed version and will shorten the upload time to Azure Blob storage.

SSRS Reports

SSRS Reports with SQL query are not supported in Dynamics 365 online, so during the pre-requisite phase of LCS process, make sure to evaluate potential options. Either convert them to FetchXML based reports or convert the reports to be used in Power BI.

If Power BI isn’t an option and due to limitations of FetchXML, the report can’t be converted, then some design changes in the method of data aggregation might be needed.

If having access to SQL data is a must, then consider using Data Export Service and enable change tracking on entities that needs to be available in a separate SQL database. This will require spinning up Azure SQL database and configuring Data Export service with it. This is another approach to still use custom SQL based SSRS report. However, in this case, you’ll have to use your own Reporting Server or better yet, use Power BI (which can also host SSRS reports).

2007 End Point and OData v2 Endpoint

Since CRM 2011, 2007 ASMX endpoint was deprecated and was removed in later releases of Dynamics CRM. In addition to this OData v2 endpoint was also deprecated and removed, so please make sure that these are replaced with 2011 SOAP (has also been deprecated) or OData v4 WebAPI endpoints.

Custom SQL Objects

Make sure to take note of any custom SQL objects including Tables, Views, Stored Procedures and Functions that were created in MSCRM database, as these objects will be dropped and removed during the Dynamics 365 migration validation process.

If these objects are valuable, then evaluate using Data Export Service to export data to an Azure SQL database.


Make sure adequate time is set aside for User Acceptance Testing (UAT), user training and adoption. FastTrack for Dynamics 365 process doesn’t end once you’ve gone live with Dynamics 365 online. Your implementation partner should have regular touch points with users and address any concerns they have, whether they are performance related or UX related.

There were many more lessons learnt that were implementation specific. If you want to know more about the process, feel free to comment down below or contact AlphaBOLD directly.