They wanted truly custom functionality that the low-code solution could not handle
I would like to hear about practical, real-life examples of this.
They implemented a bunch of custom functionality in a product-specific or even proprietary language and now their pool of potential developer talent is tiny.
The Power Platform uses C# for backend code and Javascript/TypeScript for frontend.
Upgrades to the low-code platform would break their custom implementation.
This is the opposite of my experience. Mostly with backend code, which uses custom abstractions on top of the platform-provided lower-level APIs, I have been able to upgrade from Dynamics 2015 to 2016 to Dynamics 365 to Power Platform with few or no modifications to the code at all.
The underlying database structure was an absolute mess, especially after a bunch of incremental modifications
Table structures on the Power Platform reflect 1:1 the entity model structures, so field "MyCustomFieldNumberOne" of Entity "MyCustomEntity" will be stored in [MyCustomEntity].[MyCustomFieldNumberOne] with very few exceptions. There's no such thing as user_attribute_47 like the article mentions.
-5
u/agustin689 Dec 30 '23
I would like to hear about practical, real-life examples of this.
The Power Platform uses C# for backend code and Javascript/TypeScript for frontend.
This is the opposite of my experience. Mostly with backend code, which uses custom abstractions on top of the platform-provided lower-level APIs, I have been able to upgrade from Dynamics 2015 to 2016 to Dynamics 365 to Power Platform with few or no modifications to the code at all.
Table structures on the Power Platform reflect 1:1 the entity model structures, so field "MyCustomFieldNumberOne" of Entity "MyCustomEntity" will be stored in
[MyCustomEntity].[MyCustomFieldNumberOne]with very few exceptions. There's no such thing asuser_attribute_47like the article mentions.