Logo

Considering a Dynamics 365 Upgrade? Here’s why you need Bluetooth

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.

Scene from a house move with boxes.

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.

Confused arrow directions.

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 upgradeLean towards implement
Data quality is goodData quality is poor
Chart of accounts is fit for purpose and dimensions structures are still relevantChart no longer supports core business, and several dimensions are no longer used – new ones would be more useful
Drop dead dates cause time pressureNo obvious time pressure – reimplementation will take longer
Budget is smallerBudget is bigger – business case of the differential is key
No obvious new features to utiliseKey new features to implement from the new version
Historical data is of high valueHistorical data less important. Drive a critical assessment – do I really need it.
Volume of modification is lowVolume of modification is high
Modifications are key and must be transitioned, particularly if vertically focusedKey modifications can be deprecated and replaced with new standard functionality
Resource availability limitedKey resource good and able to leverage
Current business processes are satisfactoryCurrent business processes are not supported by the current configuration
Database size lowerDatabase size larger
Number of external integrations is lowHigh 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.’

Picture of old computers stacked.

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.