Ask the expert: Preparing Dynamics CRM customizations for upgrade to Dynamics 365

Dynamics 365 and the Microsoft Power Platform are everywhere—whether you’re a CRM consultant or customer, it’s hard not be affected by this tsunami of emerging technologies.

Flows, Common Data Service (CDS), Common Data Model (CDM), Power Platform, canvas apps, model-driven apps and a plethora of wonderful new features have been ushered in through Dynamics platform over the last couple of years.

And yet there are thousands of customers who are still using Dynamics CRM, many of whom are not able to move their CRM data online due to various reasons.

It could be an issue of the costs involved in an upgrade, or maybe the customer wants to keep their CRM data on-premise for security or regulatory reasons. If you’re a Dynamics consultant working with an older version of Dynamics CRM, it’s likely that you feel as though you’re lagging behind in terms of technology. You may be itching to implement one of these features in your project, but your customer just isn’t ready yet.

But there’s no need to worry. With Microsoft’s “cloud first” strategy in full swing, and support for Dynamics CRM set to end in the not-so-distant future you may find an opportunity to upgrade your Dynamics environment to online sooner rather than later.

But wait! Are you ready? Are you following all the recommended guidelines when developing your customizations? If you’re thinking ahead to upgrading your Dynamics CRM platform, read on for a preparatory checklist to help you make sure both your existing and future customizations are up to scratch and ready to roll with the future of Dynamics.

In this article, we’ll discuss how you can optimize your Dynamics CRM customization techniques to allow you to easily upscale your developments to a cloud-based instance of Dynamics 365. We’ll also look at how to integrate Dynamics CRM on-premise with online applications in Microsoft stack.

So, are your customizations optimal and ready to upscale?

Seven rules to ensure your Dynamics CRM customizations are Dynamics 365-ready

Stick to Out of the Box (OOB) customizations wherever possible

The importance of this point can’t be stressed enough. While sticking to off-the-shelf customizations may seem mundane, it’s the eternal rule when it comes to readying a solution for upgrade, and one that every CRM consultant learns over time.

Why is it so important?

When you use OOB customizations like forms, views, fields, business rules, and OOB workflows you’re basically leveraging the features that Dynamics CRM as a platform has to provide. In other words, when you move your instance online, everything will work just fine as you’re using platform features they can be automatically migrated to an online environment without needing many changes.

For example, you have achieved a requirement using XRM script model that actually could’ve been done using business rules. When you migrate, chances are the API that you’ve used has been removed or deprecated in an online version, and in that case, you would need to re-do it. However, if you’d used business rules it would work without any further modification.

An added bonus to using OOB feature means if for any reason they fail to work in the upgraded version, you have Microsoft on your side to help since you’re using designated platform features. And what’s more reassuring than a guarantee from Microsoft that it’ll offer a fix in the event that something goes wrong? That’s why we should always be following this rule when we customize.

So remember:

In general, we should always be putting configuration ahead of custom code whenever and wherever possible. When a requirement for development comes in, analyze it first and check if can be done with OOB customization techniques. Coding for extensibility should be the last option for a Dynamics consultant.

Takeaway: Customization and configuration over code should be a consultant’s first choice.

Say NO to any unsupported customizations

Unsupported customizations have proved to be a bottleneck for upscaling so many CRM instances. In my experience, unsupported customizations are the bane of the “whatever it takes” approach to delivering CRM solutions.

While these customizations may get you an initial “WOW” from the customer, they’ll surely come back to bite you during the upgrade process.

Here are a few common examples of unsupported customizations:

Takeaway: Take a solemn oath not to suggest unsupported customizations.

Use Web-API instead of Organization Service

The Organization Service has now been deprecated, and Microsoft has stressed this in all relevant documentation. Plus, SOAP-based services are out of fashion almost everywhere, so it’s time for us to take the plunge.

If you’re fortunate enough to have Web API at your disposal (Dynamics CRM 2016 and above), always make sure to use the Web API endpoint instead of Organization Service, be it for your form scripts, web resource development, or integration of CRM with external applications.

Takeaway: Evolve and move on from Organization Service and invest in WebAPI: if you have something great, use it fullest.

Make sure your plugins work in Sandbox Mode

With Dynamics CRM on-premise, we have the ability to register our plugin assemblies with Isolation Mode = “None”.

Registering in Isolation Mode = “None” means at run time, our plugins are running in complete trust. That’s why things like accessing network file shares, using System.Security namespaces to deal with User Identities and impersonation, and making authenticated calls to external websites using DNS names or IP addresses is not uncommon.

However, these things that we take for granted in Dynamics CRM on-premise may come back to haunt you when you upscale your environment to the cloud. With Dynamics 365 online, your plugins must be registered in Sandbox—you don’t have an option to switch it to “None”.

So what does this setting mean?

Well, if your plugins are sandboxed, then none of the operations that I mentioned above can be undertaken.

Essentially we cannot:

How do we overcome this?

If you ask me, making HTTP calls with domain names instead of machine names or IP addresses always makes sense, and shouldn’t be any trouble. However, what may be an issue is not being able to use .NET authentication classes when you’re accessing local network resources.

For example, imagine you have a SharePoint Online instance and are trying to interact with SharePoint Online from your plugin. The simplest way to authenticate with SharePoint Online from Dynamics CRM Online plugins is to use the construct SharePointOnlineCredentials class.

While this may run just fine from your Dynamics CRM plugins, it won’t work when you upscale to online—your plugin will be sandboxed and you’ll get an exception when you use this Authentication construct.

In cases like this, preferably you’d need to take a REST-based approach instead of using .NET SDK classes. The ideal solution is to use Azure Service Bus features—queues, relays, etc.—or send the data to a webhook.

In short, while developing any server-side functionality in Dynamics CRM, think ahead and consider scalability for online scenarios too.

Takeaway: Think Sandbox, even when you’re not bound by it.

Use FetchXML for Dynamics CRM reports

With Dynamics CRM, you have access to Report Server and CRM Database Server, enabling you to build some really wonderful reports using SSRS. But unfortunately, with Dynamics 365 online, you don’t have access to either, meaning you’ll be limited to using FetchXML for reporting.

Throughout my years of experience with multiple CRM implementations, I’ve found that almost 60-70% of the reports developed in Dynamics CRM on-premise could have been created using FetchXML, but instead, have been developed using SSRS.

Whenever you get a reporting requirement, keep scalability to online in mind. If it can be developed using FetchXML use it instead of using SSRS. It will help you save time and effort in the future.

Takeaway: CRM reporting and FetchXML—the perfect couple for happily-ever-after customizations.

Follow development best practices

While they may not be enough to completely upturn an upgrade to Dynamics 365, poor development practices when customizing your CRM can definitely cause you a headache.

If any functionality is throwing up errors post-upgrade, you’ll certainly find it hard to debug them if your past customization practices have been less than stellar.

Here are a few best practices to stick to for client-side developments that are easy to upscale:

Instead of cramming all the logic into a single file called account.js, it makes more sense to separate it out as detailed above. It’ll make life hell lot easier for debugging too—if you’re getting an error while the account form is loading after your upgrade, you know exactly which file to look for. (No prizes for guessing which).

Similarly while writing plugins or custom workflow assemblies, we should take care to name the class files so that the name becomes the first clue as to its functionality. We should also avoid creating a class file for each plugin step, but also make sure that we don’t cram all the logic in a single class file. You wouldn’t appreciate a messy code file being handed over to you, so don’t create one like this for others.

Takeaway: A stitch in time saves nine, and so does well-maintained code.

Say goodbye to your dialogs

Personally, I love dialogs. But sadly, they’ve now been deprecated. To be clear, though, deprecated does not mean completely removed—dialogs still work perfectly well, even in the latest version of Dynamics at the time of writing.

Dialogs were popular with clients who had a requirement to show interactive dialogs to users and capture information step-by-step. However, it’s now time to start thinking of alternate designs for your existing dialogs, and similar new requirements for all your future developments.

So, what are the alternatives?

Essentially, a combination of workflow and business process flow is what you need to design a dialog. For really complex dialogs you might also need to use the next generation of workflows, Microsoft Flow. Either way, it’s best to start working with Flow now; you never know, by the time you’re ready to use it, dialogs could be dead and buried.

Takeaway: Let go of your dialogs before it’s too late.

Your CRM being on-premise does not have to limit your online reach

If you’ve checked all the above boxes, then you’re on track for a smooth upgrade. However, while upscaling your environment is something your customer will have the final say on, as a CRM designer you can certainly provide your customer with valuable input on how best to marry your CRM to other online Microsoft stack technologies your customer has in place. Being on-premise does not have to limit your capability to integrate with things like Power BI, Microsoft Flow, and Azure services.

Let’s explore some of these integration options.

Use Power BI, Microsoft Flow, and PowerApps using on-premise gateways

A gateway is software that you install within an on-premises network. It facilitates access to data in that network—it’s like a gatekeeper that listens for connection requests and grants them only when a user’s request meets certain criteria.

When used with Power BI, Dynamics CRM on-premise can act as an on-premise database to feed Power BI reports and dashboards. A gateway can be used for a single data source or multiple data sources, so you can combine your CRM data with other disparate data sources and prepare a final report in Power BI that’s basically an amalgamation of data from multiple sources.

With on-premise data gateways, you can even connect your flows with on-premise data sources. Here are the data sources that a gateway can support:

With your CRM acting as an on-premise SQL server data source, you can connect Microsoft Flow with your CRM data on-premise, so long as your customer has a PowerApps license.

It’s worth noting that currently, only the default Power Platform environment supports on-premise gateways. However, this feature will be available in all Power Platform environments very soon.

If your customer has a PowerApps license, you can even build wonderful canvas apps using your Dynamics CRM database as on-premise SQL data source.

Here’s an architectural overview of how gateways work:

Picture credit: Microsoft Docs

You can find more details about data gateways here.

Azure Relay services

Put simply, an Azure Relay service securely exposes services that run in your corporate network to the public cloud without opening a port on your firewall or making intrusive changes to your corporate network infrastructure.

If your Dynamics CRM is hosted on an intranet securely hidden behind a company firewall, Azure Relay services are the perfect way to expose your CRM data to the public cloud while maintaining security and control of the data you want to expose.

Azure Relays provide real-time integration of your on-premise data in which the sender and the recipient are connected over a conduit established from the on-premise data source. Since the request originates from within the firewall, the outgoing request is not blocked and the communication channel is established successfully, allowing data transfer to take place safely.

Here’s an overview of how incoming requests are processed using Azure Relays:

Picture credit: Microsoft Docs

In every Relay set-up, there are basically two components: one is the sender and the other the listener. If you want to integrate your Dynamics CRM with other business applications hosted in cloud, your CRM will act as the sender and the cloud application will act as the listener. Azure Relay service creates a gateway and establishes a communication channel through which the client sends and receives requests. Find out more about Azure Relays.

We’ve discussed how being on-premise does not limit your capability to access the latest online services, but how long should you wait to upgrade? The answer will largely depend on when Microsoft Support for your version is set to end.

Dynamics CRM support end dates

(All dates are mm-dd-YYYY.)

So, while your customer may take some time to make the move to Dynamics 365 online, there are many patterns and practices you can follow while you’re still working with Dynamics CRM that will allow you to integrate with other cloud-based Microsoft stack technologies, and help you prepare to make the leap when your renewal eventually comes around.