Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I need to convince the client to upgrade from AX 3.0. What are the security risks if they keep using it, and potential benefits of upgrading?
Oh yeah, that will be a long list...
Start with the fact that it's not supported anymore (not even by extended support) - forget not only new features, but also changes necessary due to changed law, security fixes etc.
Obviously Microsoft added many new features in last 10 years, but it's always useful to focus on what would help the particular customer.
To mention at least a few general features, they'll get DIXF, workflows, support for Unicode, office add-ins, many new options for reporting (although they might be rather scared by upgrade), improved security setup, much more powerful financial dimensions. much easier integration with other applications, LCS and so on and so on.
There are some considerations like:
- AX 3.0 is not supported anymore
- Newer server software is not supported with AX 3.0
- Actual localizations of country specific features
- Possible other new features which can be used or can replace current customizations
The problem is that the current AX system is highly customized, and to port it all on to the latest AX version would cost a lot. So they are looking for significant improvements to even consider upgrading.
We can't tell which feature would be "significant" for a customer completely unknown to us. What's a must-have feature for one company is irrelevant for another and vice versa.
Nevertheless the problem with many customization won't resolve itself; it will only become worse and worse, therefore it's not an argument against upgrading. Sooner or later, they'll either upgrade to a new version of Dynamics AX or implement a different ERP system from scratch (which would be much more expensive).
Would really appreciate some pointers on security issues for older AX versions.
If I’m not in mistake, Microsoft terminated extended supported back in 2012 for AX 3.0. Therefore, any error including the security related ones, are no longer solved by Microsoft.
I don’t think there is any public security vulnerability that wasn’t solved by Microsoft in the support lifetime.
I’m not saying that don’t exists any security issues in AX 3.0, most vendors when they stop the support for a product, conventionally also they stop disclosing security leaks on a product.
I’ve face this question many times.
It sounds to me as though right now there is no compelling argument to upgrade.
Yes new features are nice, but if your current version meets your business needs today and in to the future, then the business motivation to upgrade is not great. It’s all about cost to your business. If there is no strong business case then it is not likely to get up as a project.
Perhaps you should look at what your business 5 year strategic growth plans are. You can then assess if your AX 3.0 system is going to meet them.
To move to a new version would not be a simple upgrade process. It would be a full re-implementation and very costly.
You are exposed with your version being out of support, but this is easily mitigated by a robust and regularly tested disaster recovery strategy and a knowledgeable support crew.
The thing that will force you to upgrade would be your hardware and / or system performance degradation.
You need to determine when your hardware is going to reach its end of life or the system reaches a performance tipping point. You then need to start planning.
To be honest, at this point, you might as well go out to the market and assess else what is available.
I strongly disagree that AX can't be upgraded and it's necessary to do some costly re-implementation. It's simply not true. There is an upgrade process for both code and data. Only some isolated pieces must be reimplemented (e.g. security in AX 2012). Usually the main problem is in upgrading customizations, especially if they're poorly designed and people didn't follow the recommendations how to write easy-to-upgrade code.
Sure, people sometimes have customizations that conflict with new features they have to rethink and reimplement them from scratch, but that's not the usual scenario.
I also see people with old versions of AX developing many things that already exist in newer versions - ledger dimensions linked to existing tables, sharing items across companies, workflow, integration... The fact that they spend resources for designing, developing, testing and supporting these unnecessary customizations must be added to the equation.
To upgrade from a heavily customised AX3.0 to AX 2012 or probably later, I believe would require a similar effort to a re-implementation or deliver a better outcome.
I don't believe there is a direct upgrade path, so you would have to incrementally upgrade. Each time you would have to ensure customisations are migrated, or replaced by features offered in newer versions. This would involve detailed analysis and extensive testing. Each time.
A reimplementation would offer the opportunity to not carry forward mistakes made and to properly make use of new features.
I just cant see how upgrading is going to be easier, cheaper or better for your business than reimplementing.
If upgrading is simply giving you the same functionality that you have today, then what is the point?
By the way, I didn't say it couldn't be upgraded. What I am driving at though is you need to weigh up the cost of upgrading versus reimplementing, taking in to account the opportunity and business benefit that both approaches will give you.
I agree that if the code is full of mistakes, it's better to rework it. But that's true even if you don't do any upgrade.
If I can simply upgrade 90% of my code and rework 10%, it must be more efficient that throwing away, reimplementing and testing all 100%.
Business Applications communities