Don’t auto-convert. Think. Transform.

Why am I not a fan of auto converters which allow you to magically turn something old into something new? In the context of Dynamics 365, old Java Script into a new format, SQL reports into FetchXML, workflows into Flows etc. It’s because I believe that “new” is not just about tools, it’s about the evolution of the way we approach things, solve problems and design solutions.

Every single “magical” conversion tool I tried in my long developer life turned to be 80% magical. It really saves you that 20% of the time. The rest of the conversion takes…. you know the rule.

Dragging the old way of thinking, outdated processes and heavily customized solutions into a new world doesn’t look like a good idea to me. It still requires significant investments but it doesn’t offer any benefits in return.

Therefore, it makes more sense to focus on revisiting requirements and reviewing processes instead. Is the solution still valid for your business in general? Maybe it’s better to even put some bits and pieces in a rubbish bin because the old logic is not applicable any more or discovering a freshly built out of the box functionality which made the old customisation redundant.

If we remove an “auto” component and add a “human” component instead, in this case, conversion becomes a transformation with the support of change management, strategical planning and roadmaps. Even though it seems like we don’t have too much of a control, sometimes we don’t need much, really. All we need is just a courage to accept changes and drive the best business outcomes, finding and claiming all benefits.

Assuming our existing solution still meets all business requirements and we don’t expect it to change in terms of business logic, the other thing we have to consider is the internal solution audit.

I know they call it a “code refactoring’, but it is not just for developers and not just for a code. It’s real magic which allows evaluating the internal validity of the solution on every step of the way. Particularly for Agile projects. It’s fully applicable to the “functional” development and solution design as well. So when we are encouraged to accept the change, won’t it be logical to use it as an opportunity for this type of audit as well?

Sadly, nobody likes changes. But in the situation where we all, willingly or not, are invited to become a part of a change it’s very important for all parties to try to maximise its value for the business trying to make the whole transformation sensible and worthy. Let’s not count on the auto-magic!