We are upgrading our Dynamics AX 2012 R2 to R3, we have customization on the ISV Layer, the ISV supplier does provide an upgraded model of the ISV (R3) but it has many changes from the R2 version, some tables are deleted and functionalities have been changed.
These changes can effect our system as we are using some of the deleted objects in integrations with third party software and we have many customizations on top of these deleted objects.
Is it okay to move all the ISV customizations to a clean VAR Layer and upgrade it? will that cause any issues for the future? or is there a better way to achieve that?
Thanks a lot.
I'm not sure that I understand what you're trying to do, so let me at least explain how upgrades normally works.
Let's assume that you have customizations in VAR layer only. You'll get an R3 environment (with changes in SYP layer) and the R3 version of the ISV solution. The baseline database contains R2 version of all layers.
Then you'll run conflict detection. It'll look at which objects you've customized and whether they're modified by Microsoft or the ISV (e.g. whether ClassA in R3 version of ISV layer has different code than in R2). You have to upgrade these conflicting objects.
If R2 version contains a certain object (that you're using) but it was deleted in R3, you must look at what the new solution uses instead and upgrade your extensions accordingly.
Thanks a lot for your reply,
The issue is that the ISV supplier has done alot of changes on the functionalities which our customer didn't approve to use, the customer want to keep these processes as they are on R2, and it requires to rebuild some integrations with third party software, and it's a critical changes which has to do with customer online payments.
so I was thinking to move the ISV customizations to a clean VAR, and perform the upgrade, you think that this is not a good idea?
If you don't want to use the R2 version of the ISV solution in R3, your first step must be upgrading the ISV solution to R3 by yourself. Then you'll upgrade your customizations.
Note that I know don't know in which layers you have your customizations. If it's in VAR, than you'll upgrade VAR in addiiton to ISV. But then I don't see why you want to move something to VAR layer and from where. Maybe it's because you didn't explain what you mean by "ISV customizations".
Sorry, Maybe I wasn't clear enough about the situation that we have, let me explain as best as I can.
We have Dynamics AX 2012 R2 and we are planing to upgrade to R3. We have a customization on the ISV layer provided by a different partner (independent software vendor). We also have customizations on the USR layer, most of these customizations that on the USR Layer are using objects that on the ISV.
We got in touch with the supplier (Partner) of the ISV model, and they have an upgraded ISV version of the R3, but they have done a lot of changes, deleted tables, change of the functionalities, etc.
We don't want to apply these new changes because there's an integration is built (On USR) which using some of the deleted objects and a lot of other things that has been created based on objects and functionalities that as been deleted or changed.
To maintain everything on the R3 as it is right now on R2, I'm planing to upgrade the ISV from R2 to R3 by myself and to not apply the R3 ISV that the supplier sent me. To be able to do that, I will need to run the process of code upgrade which requires to assign the running layer to the layer that I'm planing to upgrade from higher to lower (ISV ---> USR). In my case I don't have the development code for the ISV so I can't run the AX Client with the ISV assigned. So I'm thinking to export all the customizations from the ISV Layer, then remove the whole layer and import the exported customizations (xpo file) on the VAR and perform the upgrade.
But I'm not sure if that will cause any issue with the ISV supplier or with the ISV license. Also, Is there a better way to achieve that?
Thanks again for taking time to help me, much appreciated.
All right, now I understand your situation.
To be able to use code conflict detection, I think you should first move ISV code to VAR layer and only then start the upgrade. Using .xpo will work; you can also utilize TFS/Azure DevOps synchronization for this purpose.
What you're allowed to do with the ISV solution depends on your agreement with the ISV. It's also possible that they're using a new license for R3 and your license for R2 will expire. You should check it with them.
By the way, you'll have to be careful when deploying your upgraded code, because you don't want to change object IDs. First install VAR layer and only then remove ISV, because this means that objects in VAR layer will reuse objects IDs originally assigned to objects in ISV layer.
Thanks a lot Martin, this is very helpful, really appreciate the time that you took to help me out.