Dynamics 365 Portals vs Adxstudio Portals

The main goal was to see if the solution we are building on Adxstudio Portals is compatible with the new Dynamics 365 Portals and if a switch to Dynamics 365 Portals was appropriate before going live.

So we signed up for a Dynamics 365 Portals trial, a Dynamics 365 CRM trial and our journey began.

Backup and restore

First, we needed to transfer our data to the new CRM system, not wanting to recreate all the data. The existing websitecopytool from Adxstudio came in quite handy.

Almost all of the data could be copied to the new CRM system, only a few records needed to be created manually. Good news here is that schema names stay the same after upgrading to Dynamics 365 Portals.

Next step was to link our existing website to the Dynamics 365 Portals. We could select our copied portal in the portal manager so we were excited everything was going well.

When going to the home page of our portal however, nothing but an error message was showing. “We’re sorry, but something went wrong. We’ve been notified about this issue and we’ll take a look at it shortly.”

Okay, so something went wrong, apparently the backup of the Adxstudio doesn’t run on Dynamics 365 portals. Too bad. Let’s do some troubleshooting and make it work !


This was the point where the shortcomings of the new product started to pop-up. In Adxstudio we have the trace.axd we can enable to debug our portal application. Unfortunately nothing like that exists on the Dynamics 365 Portals, when going to the /trace.axd path on the website, it throws a server error.

‘Description: The current trace settings prevent trace.axd from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.’

Data transformation

So, straight line backup and restore from Adxstudio Portals to Dynamics 365 Portals doesn’t work. We didn’t gave up that easily. Next step, was using the default ‘Customer portal’ you can choose when deploying a new Dynamics 365 Portals instance and add our existing web pages and components to it.

This approach was quite successful and we managed to get most of the pages up and running after providing the required data on the imported records (most of the records have an additional lookup to the website record in Dynamics 365 Portals which need to be filled in when linking them to a page).

Dynamics 365


Entities below have an additional website field in Dynamics 365 Portals:

  •           adx_entityform
  •          adx_entitylist
  •           adx_entitypermission
  •           adx_webform
  •           adx_webtemplate

Most of the entity metadata was picked up nicely (labels, validation messages, …). However when some JSON data is generated, not all configuration could be converted to the new format and some of the configuration needed to be redone. All Liquid code was picked up without any problem so most of the custom layout and features did not need any adjustment to work on Dynamics 365 Portals.

Cache Invalidation

Editing portal configuration records in CRM led to another shortcoming of the current Dynamics 365 Portal application: ability to refresh caching.

As you might know, Adxstudio Portals and therefore Dynamics 365 Portals heavily caches data on the portals side of the application. So changes made in CRM are not immediately displayed in the portal. In Adxstudio we were able to refresh cache on demand by using a bookmarklet. Using this bookmarklet all changes were reflected on the portal within about 30 seconds. In Dynamics 365 however, this bookmarklet is no longer available and we are advised to restart the portal from the portal admin page (discussion on dynamics community).


Which leads us to the most important limitation of the current Dynamics 365 Portals application: it’s performance. Or should I say: the lack in performance.

The current Dynamics 365 Portals application is slow. Very very slow. Load times for some pages over 30 seconds are not an exception. To make it even worse these load times are very unstable. Sometimes a page may load in 3 seconds, next time it may load in 15 seconds, other time in 30 seconds.


The last part (performance issues) was what made us decide to not go for the Dynamics 365 Portals application at this moment. We feel it is too unstable to be able to run any production (or development) portal on at this moment. We know Microsoft is aware of these issues and they are putting some portals on faster servers, even though submitting a support ticket, like mentioned in the comments, did not bring us any help.

What we did learn from this journey is that there is some kind of compatibility between Adxstudio Portals and Dynamics 365 Portals, most of the schema still remains, although it will always need a revision and some tweaks of all its features when migrating it to Dynamics 365 Portals.

We will continue to lookout for all developments being made on the Dynamics 365 Portals and as soon of some of the issues mentioned above are fixed, we strongly believe in the future of Dynamics 365 Portals.

If you should have any feedback or questions, please don’t hesitate to contact us !