Are you considering a Dynamics 365 upgrade? We caught up with Adam Seaton, CEO and Nicholas Trumper, Solution Architect to discuss upgrades from Dynamics AX to Dynamics 365. In this blog, Adam discusses why an upgrade is like a house move, why everyone should have Bluetooth speakers, and Nick answers Adam very slowly.
Packing and Preparing to Move
I have made a major house move five times in my life, and there is probably another one in the not-too-distant future. Here is the routine: evaluate all your worldly goods; decide you can’t live without them; box them up; move them from house A to B; unpack toothbrush, kettle, chair and TV; leave all other boxes in the garage for 3 years; move again, taking the boxes that are still unopened from last time. Rinse, repeat.
Very rarely, you go looking for a random object buried deep, only to realise when you get there that times have moved on and it is no longer relevant or fit for purpose. In addition, somewhere in that journey, your unopened boxes are joined by other unopened boxes during a ‘merger’. And you thought you had some baggage! The new house is equipped with an instant hot tap, so I don’t need a kettle any more. Definitely don’t need two as a result of the ‘merger’.
Not to worry, I’ll box them (both) up in the garage – just in case.
The Move to the Cloud
So the point has come to move your ERP from its old safe cosy home, to a sparkling new residence in the cloud. Let’s skip past the ‘should we?’ debate and assume that decision is made to do a Dynamics 365 upgrade, for whatever driving reason. You’ve got stakeholder sign-off, strategy is aligned, business case built, outline budget approved, key vendors engaged. You now face one of the toughest calls – do you upgrade, or do you re-implement?
Even tackling the question is complex. There are financial elements, strategic factors, technical and architectural considerations. I’m going to tackle the first two, but one of our solution architects, Nicholas, has been drafted to help me on the technical side. Let’s start there, as Nicholas explains:
‘The two main factors are code and data, and you must evaluate each separately. In theory they sit independently. In practice, you will probably upgrade both or neither, but they certainly have their own factors that will add weight one way or the other. Even here, there are shades of grey. There are certainly scenarios where you could upgrade data and most of the application but may choose to drop some code elements (earlier modifications) that now reside in the standard updated application.’
Nicholas and I debated the nuances here for some time. Thinking I had my head around all the technical elements, I tried to summarise. ‘So I can upgrade the data but not the code, upgrade the data but only take some of the code, upgrade all the code but start with clean data, upgrade some of the code, and take some of the data, or start again with completely new application and new data, apart from core data which has been migrated rather than upgraded’. ‘Yes’. Although he said yes very slowly.
This blog could easily become a book, so at the risk of oversimplification, we tried to consolidate some key points into a table. Let’s set that out before we debate some softer elements. We’ve put them in a very unscientific ‘things that might likely influence you in that general direction’ structure:
|Lean towards upgrade||Lean towards implement|
|Data quality is good||Data quality is poor|
|Chart of accounts is fit for purpose and dimensions structures are still relevant||Chart no longer supports core business, and several dimensions are no longer used – new ones would be more useful|
|Drop dead dates cause time pressure||No obvious time pressure – reimplementation will take longer|
|Budget is smaller||Budget is bigger – business case of the differential is key|
|No obvious new features to utilise||Key new features to implement from the new version|
|Historical data is of high value||Historical data less important. Drive a critical assessment – do I really need it.|
|Volume of modification is low||Volume of modification is high|
|Modifications are key and must be transitioned, particularly if vertically focused||Key modifications can be deprecated and replaced with new standard functionality|
|Resource availability limited||Key resource good and able to leverage|
|Current business processes are satisfactory||Current business processes are not supported by the current configuration|
|Database size lower||Database size larger|
|Number of external integrations is low||High integrations that need re-work in any event|
We could have made that list longer, shorter, ranked them, added 100 other ‘it depends’ statements and caveats. Of course every single implementation presents different and unique sets of circumstances and factors. So it should prompt debate, but I acknowledge it won’t drop out a silver bullet answer.
The House Movers’ Opinion
Equally we don’t want to dodge the question, so in the interests of declaring a view, we did pick out a couple of factors that we feel will have a more significant impact on your strategy.
On the code front, Nicholas made a strong case for starting again. ‘When considering a new implementation or Dynamics 365 upgrade, you have the opportunity to review the latest features which may replace the need for any current developments to be upgraded. You therefore remove associated technical debt. Power Apps can be used in place of previous low-level developments, Power BI in place of custom SSRS reports and Power Automate in place of any scripted tasks. Even old code that has no comparable new feature and no obvious platform tool that will do the job, can often benefit from a ground up re-write to ensure it takes advantage of the wider horizontal improvements that the core application now contains’.
Finally, I asked Nicholas if there were any factors that would de-facto swing him one way or the other. ‘Well if you’re not on the latest version of pre-cloud, then you can’t even start the upgrade. In our world, if you’re on AX4, AX2009 or pre-R3 version of AX2012, you have an upgrade project on your hands before you can get to your upgrade project. In the other direction, perhaps if you have massive IP in vertical modules for which there is no obvious new-world replacement, that would make a strong upgrade case, but you can still separate the data debate too.’
As a finance consultant answering the same question, I view it more from the data and business process angle. For me, data quality is king. Five to seven years seems about typical for companies considering this move, and in that time I’ve never met a business whose needs have not changed, processes have not matured and analytical needs have not shifted. To miss the opportunity to re-align those elements during a new project would be an opportunity lost. Would anything drive me the other way? Well Nicholas makes a good point about large IP in vertical solutions, granted. On the data side, maybe a compelling need for historical traceability on product sales, perhaps due to compliance and audit (regulated industries), warranty and returns management, field service history / traceability of serial numbers, production build variants and such like….yes maybe. But I would equally challenge to ensure that we don’t bring 20gb of data over just because we really need two or three key entities that could reasonably be archived in history tables or a neat new data structure and give us what is needed.
The 80/20 Rule
All debate aside, we do have some hard facts on the reality of this decision within our customer base, and 80/20 rules apply in favour of re-implementation. Of the pure Dynamics 365 upgrades, I’d say they shared common factors: smaller implementation, near vanilla solution, core business processes and data still fit for purpose and a relatively large differential between the two cost options (because they were small and vanilla ergo the upgrade was easier). Even on those projects however, we had to do some notable rework on integrations to adopt new technology and frameworks outside the core application.
I like to start again. In a sentence, is there a compelling reason to upgrade old code or data, or both? If not, my default starting point would be to re-implement and drive all the business and technology advantages that the blank pages afford.
You might think you need two kettles boxed up in the garage, along with the other 27 boxes. You don’t. And I know you bought your stereo and vinyl collection with you and have spent a couple of days drilling walls and routing speaker cables around the house, but now the job is done you perhaps think it would have been wise to adopt the digital music revolution and some wireless speaker technology. A bit of Polyfilla, no-one will notice.
Why not contact the team today to find out how we can help with your Dynamics 365 upgrade and implementation.