Upgrading Old Solutions

They exist everywhere: solutions whose foundation was laid in Dynamics CRM 2013 or 2016. Since then they have moved along through version jumps and into the cloud. The basic functions work, otherwise they would have no reason to exist anymore. But under the surface they carry constructions from another era. And at some point the question arises how to modernize something like that.

Assess first, then touch

The most obvious mistake is starting without an inventory. Modernization without an inventory becomes an endless task, because new things keep turning up. The inventory from the solution export answers the dimensions in advance: how many classic workflows, how much legacy JavaScript, which deprecated component types, how many forms in legacy design, and how documentation and naming consistency stand.

These numbers give you the most important fork in the road. Is modernizing the existing solution worth it, or is a rebuild with data transfer the more honest option? The analysis before a Dynamics migration covers the same numbers. As a rough guide: if more than half of the logic runs on superseded technology and the documentation is practically missing, the rebuild is rarely more expensive than understanding and rebuilding every single legacy construction.

The order for an existing solution

If you decide for the existing solution, the same basic order applies as for any refactoring. First measure, then remove legacy items, then re-cut and consolidate. Modernize last of all. Every component that is thrown out beforehand does not have to be modernized.

With old solutions one point moves to the front: everything with a shutdown date. Deprecated endpoints in scripts and components for which Microsoft has named a concrete end are the part with real deadline pressure. The large mass without a deadline moves as occasions arise. This includes classic workflows and Xrm.Page scripts. If you rebuild a form functionally, you modernize its scripts at the same time.

Two pitfalls from practice

Old solutions often contain components that cannot be recreated anymore, for example dialogs. Dialogs only worked in the old web client, which was switched off at the end of 2020, and they do not start in the Unified Interface. They are still in the export. Their steps are often the only description of a process that users used to go through in a guided way. So read them before deleting, and clarify whether and how the process is covered today. A deleted dialog cannot be recreated.

And: old solutions are often unsegmented. On the first export from a modernized development environment, more therefore often comes along than expected. Re-cutting into segmented solutions belongs early in the plan, not at the end.

As a working environment for all of this, a copy restored from production is recommended. Old solutions often behave differently against empty test environments than against the real data. This applies especially to processes that react to existing data. This copy makes experiments risk-free and only costs some time.

With such solutions, modernization is less a project than a way of operating. A solution that has grown for 12 years will not become young in one quarter. But from now on, it can become a little younger with every change instead of older. That is the realistic ambition.