This is very much a collaborative post. Leon had a first go at it, George threatened to rip it all apart if posted because of the tiny technical inconsistencies. The verbal abuse discussion ensued, links were cross-checked, and now we have this.

We have known for a while that the Dynamics CRM 2011 endpoint is deprecated and, if we are using it to access the Dynamics 365 organization web service, we need to update our code. The linked article says

The 2011 endpoint will be removed some time after the release of Dynamics 365 version 9

Given this is a little vague, Leon raised it at the CRMUG Summit EMEA in Dublin earlier this year. At that time it was confirmed by Microsoft that the 2011 endpoint will be around at least until the release of v10.

So when is v10 coming out? At the time we did not know. Now looks like we do! The October ’18 Release Notes are out. This means that, assuming Microsoft stick to their schedule, and assuming that October release will be, in fact, version 10, it will be out in October this year. What does this mean for your Dynamics implementation?

No one can express it better than Matt “Platform Deity” Barbour (this is somewhat abridged and modified version):

1. The deprecation does not mean that the endpoint will be removed AT version 10. Microsoft has a lot of metrics for various things including the SOAP usage and continuously evaluates the consequences of removing something as fundamental as the endpoint.
2. The Organization Service (the IOrganizationService Implementation), used in the CrmServiceClient and Plugin\Workflow system is NOT deprecated. For folks building plugins, using the IOrganizationService is the right way to go, and will remain so for the foreseeable future.
3. With regards to the CrmServiceClient, nothing changed since the deprecation notice.
   

   We plan to provide updates to the Dynamics 365 SDK assemblies and tools over the next several minor releases, retargeting them to use the Web API instead of the 2011 endpoint.

4. Which approach to use?
   • If you’re building plugins, build around IOrganizationService and other SDK assemblies.
   • If you’re building using the .NET framework, the CrmServiceClient is the way to go.
   • If you’re building on non-Microsoft platform or .NET Core\Standard [at the moment], the Web API is the way to go.

Note that Web API is not explicitly mentioned in #2. For new developments you may want to consider Web API as well but do not expect the same level of support as exists for .NET, e.g. strong type support, authentication wrappers, diagnostics and such.

Why? Because OData, as an industry standard, has many different ways and methods folks can adopt to do this. Each offering their own flavor of features and capabilities to support the needs to the technology that is implementing it.

I’m sure that with time we will see 3rd party Web API wrappers emerging (and they do already exists) that will make development easier, and purists and minimalists happier. 

Call for action

Check the code that is talking to the Dynamics 365. Ensure that the code is using either Web API or SDK assemblies. This does not mean just plugins but anything integrating to Dynamics. It may be integration to another system or a custom web form application. All interactions need to be checked and if they are explicitly replying on the 2011 endpoint, bring them up to standard. The clock is ticking.

(And as painful as it is for me and many others, we’d have to admit that George was rightalmost two years ago.)