Microsoft Dynamics AX (Archived)

Upgrade from AX2012 R2 to AX 2012 R3

(0) Share

Report

Posted on by Rohin

4,624

Hi All,

Can anyone please share approximate time or days taken from upgrade AX 2012 R2 to AX 2012 R3 ?

please give an approximate Idea?

Thanks

*This post is locked for comments

I have the same question (0)

All responses (23)

Answers (9)

Mea_ 60,284 on at

Like (0)

Report

Hi Visvash Walia,

It's hard to say and really depends on level of customization you have. It can take from couple of days to years if it's heavily customized.

Was this reply helpful? Yes No
Rohin 4,624 on at

Like (0)

Report

Hi Ievgen ,

Thanks for quick response.

My AX is not heavily customized. It has some of customization In USR Layers. So what are couple of days would it take an free idea for whole process ??

really appreciated if you provide some feedback.

Was this reply helpful? Yes No
Rohin 4,624 on at

Like (0)

Report

Hi Ievgen,

Any free idea ?

Was this reply helpful? Yes No
Verified answer

Rachit 4,015 User Group Leader on at

Like (2)

Report

Hi Vishvash,

As mentioned by Ievgen earlier, there is no calculator available to calculate upgrade time. You mentioned your application has few customization on USR layer but that is not enough to estimate any time for upgrade.

Some partners count the number of modified objects of each type and then calculate the upgrade time based on the total number of objects and multiply by a time factor like 15 minutes per table, 30 minutes per class and 2 hours per form. Forms eat maximum time as the desing needs to be refactored and lot analysis is required due to datasource links, queries and tables refactoring. This method gives you a very rough idea but in my view it is just a fake way of showing something to management.

What actually needs to be evaluted during upgrades is:

1. Is the upgrade really requred? Are there any features in the target version which will be used by business.

2.Which business processes are customised in source system and is the customization really required in the target system?The base functionality customized in old system might have changes/enchanced in target system and the customizations done in previous system might not be required anymore.

3. Technically also code needs to be analysed during upgrade and refactored to suit the target applications. Some methods/classes can take hours to upgrade and some can take less than 5 minutes.

Upgrades should be handled in an agile way as you never know when you encounter a impediement during the process.

Hope this helps

Was this reply helpful? Yes No
Suggested answer

guk1964 10,888 on at

Like (0)

Report

Forever. the challenge is whether you use the new WMS (in theory the only long term option) it introduced additional inventory dimensions and changing all of your posted inventory history with additional dimensions is not supported.

There are some new migration tools expected around July this year for the move to DMO365 which might ease the pain.

reality is reimplementation w ill be faster and cheaper and the investment in converting and reconciling past history would be better spent on adopting new features for the future..

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (2)

Report
You have to consider a lot for a larger update, such as RTM/R2->R3.

You have to gather and document all your possible business processes and flows, and how do they interact with each other.

Microsoft has introduced a lot of new functionality, such as Advanced Warehouse Management. They also redesigned the Credit card handling engine, and a lot more, which has impacted us greatly during our upgrade.

Make an impact analysis to see where does your business processes overlap with modifications in the system, and see if you can make it work in a demo environment by doing your setup changes, or not.

Check if you have made any customizations in the areas where Microsoft did any redesign functionally (along with the underlying code and metadata), to have a rough idea by how much your technical code upgrade might take

There are a lot of technical changes, which you need to read the documentation for and consider them. For example they have flattened out a lot of tables which used to be in a Table type hierarchy (extending each other). They also have removed a lot of ValidTimeStateKey settings on tables especially around Global Address Book (Electronic address for example), which made the application somewhat slower before. I had such changes in my system and during upgrade we had to do a lot of code and metadata refactoring, even had to change the ReleaseUpdateDB* classes responsible for the data upgrade cockpit in the ugprade checklist.

Once you are done with the code upgrade, you have to do multiple iterations of data upgrade and clean up any data discrepancy and bad data you have generated due to system or customization issues (you will have errors for sure). See if your customizations are working correctly and make data upgrade scripts for them as well if required.

Carry out a thorough, at least 2-round User Acceptance Test, to see if all your previously documented business processes are still fully functioning as expected, including inventory closings, master planning, financial year-end closings, etc.

Once the business signs off that both functionally and data-wise your upgrade is a success, you can start preparing for the actual Production in-place upgrade.

Measure the time on how much it takes for multiple runs of the whole installation and upgrade process to see if you could fit in an acceptable window for carrying out the actual in-place upgrade.

Prepare a fall-back scenario in case you would encounter an error at any stage of the upgrade. Believe me it does happen even with the most experienced people that the "sh*t hits the fan", and you need to have an established recovery scenario where you could get back to your old system in a reasonable timeframe.

Test the system post-upgrade with some prepared scenarios, before finally handing it over to the business.

As you can see, there are many points to consider here. To be able to tell how much time it takes for your upgrade, it depends based on the above that how prepared are you to do it? If your developers know their code inside-out, you have all the business processes and technical designs documented up front, you have in-place disaster recovery scenarios like system backups and VM snapshots, and you have people who have done at least one full-scale upgrade, then yes, it is possible to do an upgrade in lets say 3 months.

If you do not have any of the above mentioned met, your typical upgrade time is around 6 to 9 months depending on how much resources you have available to carry out the upgrade.

Also as part of a major upgrade the better companies tend to do an audit and revise their processes for simplification, do code cleanup to get rid of warnings/best practice errors/LCS code impact analysis errors, archive some of their data, and a lot more, which can also extend the whole upgrade process.

Was this reply helpful? Yes No
Rohin 4,624 on at

Like (1)

Report
Good write up Vilmos, thank you.

I would like to mention some points here so it would be easy to understand:

My client is not using all AX functionalities. He is using very limited modules i.e. AP modules (Vendor Invoice Journal by AIF service, Vendor Payment Journal), AR Module (FreeTextInvoice, AR Payment Journal), General Ledger module (General Journal by AIF service), Budgeting Module, System Administration and Organization Module.

There is very few customization only in AR and AP module (USR Layer).

Now can you please suggest me your experience on this?

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (0)

Report

AP and AR modules rely on the Vendors and Customers, which is the Global Address Book - see my comments on normalization changes there. Also Finance-related modules have also been changed in the metadata. I would say most of the points I've raised still apply for your case as well, and the upgrade could take several months still if you want to do it properly.

If you do not have heavy ISV solutions, multi-layer customizations, the code upgrade part could be done in a couple of weeks tops depending on the documentation and experience of your team.

We typically approach it in a way that we do a "dry code upgrade" first, where we do not really care about new functionality, just resolve the compilation errors or data type conflicts due to redesign. Once the application is error-free, we try to run the data upgrade in a new environment and see if it goes through. Do a quick fix for the errors, and let functionals test the dry-upgraded code. After that if they find that some business processes are not working as expected, then you can start looking into overhauling and redesigning the system to use new business processes/functionalites that Microsoft has brought in, and also try refactoring the code which is broken.

Once those parts are done and you have a final upgraded codebase, you can fine-tune the data upgrade and do several iterations on those, to make sure after the ugprade you are not missing anything, transactions, postings, integrations, everything is in order.

Was this reply helpful? Yes No
Rohin 4,624 on at

Like (0)

Report

Thanks Vilmos for your suggestion. I am here for some guidance so that I don't end up with some confusion.

Here i am getting confused with below mentioned your comments :

"If you do not have heavy ISV solutions, multi-layer customizations, the code upgrade part could be done in a couple of weeks tops depending on the documentation and experience of your team."

How can i get to know my ISV solutions is Heavy or not??

Please suggest

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (0)

Report

If you for example you have used Blue HorseShoe solution for warehouse management and shipping which is worth several hundred thousand dollars like at my previous workplace which changes your whole inventory handling impacting most supply chain modules, and then later on the ISV solution got acquired by Microsoft to become the new Advanced warehouse management module in R3, that is how you know if you have heavy ISV solutions :)

In case you have any ISV solutions at all, you need to contact those vendors if you have software assurance/solution level agreements with them to provide the upgraded version of their modules, which you need to install instead of your current ones. If you do not have a license or the vendor has not upgraded it themselves, you might have to do that task yourself as well. If you do not have ISV solutions, which you have not mentioned yet, then you have nothing to worry about and just upgrade your own customizaitons on USR.

Was this reply helpful? Yes No