New Microsoft Dynamics AX aka 'Dynamics 365', has already been released and is making all kinds of buzz in the ERP market - for good reason. The recent Technical Conference showcased many new features and technical changes in the product, and record attendance was strong evidence that customers and partners are excited about the new capabilities it provides.
There are already many blogs about the new product version and its features. There is also an official new wiki page from Microsoft to learn new, changed, and deprecated features in Dynamics 365 along with other details: ax.help.dynamics.com/en/
Customers who are in process of implementing or just went live with Dynamics AX 2012 R3 and earlier versions - What options do they have? Can they switch gears and upgrade or implement Dynamics 365 instead? It's not as easy as it may sound - these are the factors that need to be considered:
Microsoft Dynamics Dynamics 365 is a cloud-based only version at the present time. Is the customer's organization ready to shift their on premises version to cloud ?
If the customer is planning to use AX 2012 features and these are not yet implemented in the current release of Dynamics 365, they have no option but to wait for these features to be released before making the transition.
The overall effort required to migrate code from AX 2012 to Dynamics 365 is high. Microsoft has build a LCS solution to upgrade your code from AX 2012 to Dynamics 365, but it may not be code-ready to deploy. You may have to re-do some custom development work to make it compatible with Dynamics 365. Also, consider the effort required for testing, dev team training, user training, and other associated activities to switch to Dynamics 365.
Last but not least - "early adopter's pain". Microsoft has done tremendous work this time to test and eliminate defects from the product through private, public preview, and ISV solution migrations, but fear still persists for many customers based on past experience.
Now let's assume that due to any of the above reasons, your project is not in the right position to switch gears and implement Dynamics 365. What should you do in your current AX 2012 implementation to make sure you are not drifting away from the technological changes in Dynamics 365 and thereby avoid future cost to adapt/upgrade when that time comes?
Integration with third party applications is one of the key changes that comes to mind when you think about the core technological shift in Dynamics 365 from AX 2012. AX 2012 - AIF document services are one of the key integration technologies and many customers/partners have heavily invested in using it. Microsoft has deprecated AIF, specially the document services, from Dynamics 365 and has replaced it with a single concept DIXF (Data Import/Export framework) for data migration as well as for integration. AIF custom services can still be used in AX for synchronous end to end integration but any recurring offline adapter (File System Adapter, MSMQ adapter etc) based integration has to be moved to the new integration framework.
There are very valid reason for Microsoft to shifting away from the AIF and SOAP based complex integration model to new, modern web integration technologies. A few reasons:
AIF framework has very high framework cost and is not good for performance
AIF services are SOAP based XML format. SOAP messages are bulky and inefficient for web and mobile devices. REST + Jason and Odata are new web service technologies which are commonly used for web and mobile devices.
AIF and DIXF are almost duplicating the business logic in AX 2012.
Now the question is what should customers do if they are still on AX 2012? Here are few bullets:
Avoid using document services, if possible, as they are going to be replaced with DMF.
Use custom services as they continue in Dynamics 365 and support Jason and Odata protocols.
Offline integration - using a file system adapter or any other offline adapter see if you can use DMF to automate these integration points.
Invest in DMF, it is a key integration method for recurring integrations in the future. It is not too difficult to enable DIXF for recurring integrations in your current AX 2012 implementation, as many concepts such as folder support, error handling, etc. already exists and can be extended for offline integration scenarios.
2. Customization vs. Extension
Dynamics AX has been known as a product that is easy to customize. This is one of the reasons why Dynamics AX is selected over other ERP systems. However, this also can cause a longer duration to implement and upgrade the product. The New Dynamics AX has introduced a new method to do customization called Extensions. Microsoft has enabled some of the extension capabilities in AX 2012 with the introduction of delegates for class and table methods. This concept is further extended to almost all other AOT objects (except Query and SSRS reports, but support to extend these objects will be added in future). Now you can extend the business logic, forms, tables etc. without over layering the Microsoft or ISV codes.
In new Dynamics AX you can create a model that contains only extensions, and the extensions compiles in its own assembly. Legacy concepts of customization using overlayering still exist, but their use is discouraged. The below example from AX wiki shows how final assemblies are built when using extension or overlayering.
Extensions is a very interesting and promising concept, but you might be wondering what you can do in AX 2012 so that when you upgrade to Dynamics 365, you can use this concept. The answer is "not much", but here are few pointers which can help:
Split your AX 2012 customization into logical groups and create separate models. For example, if you have customization in core financial, supply chain etc., use different models, as they are different packages in New Dynamics AX, and it would be easier to create separate extensions when you move to Dynamics 365.
Use current extension concepts, if you can in AX 2012 for business logic.
Create your customization independently if at all possible. Use standard business logic, but try to avoid directly customizing it. One simple example could be that if you have to customize a method in class, put your custom code in a new method instead of putting all the code in the standard method.
3. User Interface (Patterns)
As you already know, the UI in new Dynamics AX has completely changed to HTML5 in a web browser. Microsoft has done a tremendous job in keeping the design experience similar to AX 2012. For any UI element, you create forms, add a data source and design your interface by dragging controls onto the form. Everything is the same except the new concept on the form called patterns. Patterns are a form level property and determine what kind of form it is, such as a list page, detail page, dialog etc. Now the question is, why is it important? It is very important because the HTML5 UI form rendering on multiple devices and browsers needs to controlled by various CSS and java scripting. Microsoft has build various patterns and these patterns provide form structure, default control properties and determine mandatory or optional controls. In addition to top-level form patterns, Dynamics AX also has sub patterns that can be applied to container controls, and that also provide guidance and consistency for subcontent on a form (for example, on a FastTab).
When you upgrade the AX 2012 code base using the LCS code migration tool, you may have to apply appropriate patterns if the pattern is not identified automatically by the tool. What can you do about patterns in Dynamics AX 2012? Patterns in new Dynamics AX are an evolution of the AX 2012 form templates, style, and Form Style Checker concept which were optional to use. So if you use them in AX 2012 to create and validate your forms, the code migration tool should be able to identify patterns automatically.
The following wiki page describes the different Form.Design.Style values used in AX 2012 and corresponding patterns.
4. Enterprise portal /Customer portal / Vendor portal
There is no enterprise portal in new Dynamics AX, and obviously there is no need for it with the HTML5 client now.
However, if you are working on AX 2012 and have a requirement for a lightweight portal for activities such as employee self service, there is no alternative. The only advice here is to avoid costly customization in EP as code will be thrown away. Don't do an EP only solution - if you have your custom solution in both EP and the AX client, your client version code can be migrated.
5. Start using LCS
Microsoft Dynamics Lifecycle Services (LCS) has been there for quite some time now, and many customers and partners are using or have used it on their AX 2012 implementation to some extent. Using LCS is completely optional for AX 2012 but it is mandatory with AX 7 (yes, you heard it right). The new Dynamic AX story starts with creating a LCS project for deploying the environment, deploying code, deploying data packages, and monitoring the environment and troubleshooting is also done through LCS. In fact, if you want to use integrate task recorder with AX help, you have to associate task recordings with the LCS BPM (Business process modeler) library. Microsoft is continuously working on improving the existing/building new tool sets to manage the AX implementation story from LCS. One such example area is release management and integration with Visual studio online to manage the development to production application lifecycle via LCS.
If you are still working on an AX 2012 project, get your team familiar with LCS and see how you can utilize this on your project.
It may be true that new Dynamics AX is based on the AX 2012 R3 CU10 code base, but technically it is completely new technology and has many changes in the architecture, integration and development environments. It is tough decision for customers to decide if they want to continue implementation of AX 2012 or change course and implement Dynamics 365. We hope this article clarifies areas of focus if you decide to continue your implementation journey on AX 2012 and plan to upgrade Dynamics 365 later.
If you have questions, contact us at email@example.com