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.
I will move all the objects from ISV to VAR on the R2 and remove the ISV.
xpo file import will maintain the same ID's. then I will start with the upgrade, so I will not have any objects on the ISV anyway. I should not face an issue with objects ID's
I'm not sure if we're on the same page, because the statement "xpo file import will maintain the same ID's" is true only under certain conditions.
.xpo files don't contain actual object IDs, just origins and legacy IDs. If you export an object from one environment and import it to another environment, you may get different IDs. The same applies when you export an object from ISV layer, delete it and import it to VAR.
You may ignore changed IDs during code upgrade, but you mustn't ignore them when deploying your upgraded code to other environments, most importantly the production.
Setting legacy IDs would be another option.
This is a new information for me, I thought the .xpo has the actual ID for the objects, thanks for the new info
Anyway, I moved all the ISV objects to the VAR as we discussed yesterday, but for some reason the License for "Partner feature sets" is not working, I imported the license again without any look. it's a valid license as I tried it many times on another instances and it's working fine, but having the ISV moved to the VAR Layer, made the issue.
I debugged the issue, but the error is coming from a system documentation class "Dictionary.testcode".