I have a good deal of AX 4.0 to AX 2009 upgrade experience and AX 2012 upgrade is definitely different. From AX 4.0 to AX 2009, you basically did three things (not exactly this order):
- Merged all of your customizations against the new sys/syp layers
- Extended the ReleaseUpdateDB41* classes if needed to upgrade data
- Ran the upgrade scripts to upgrade fields and move data around
With AX 2012, there are much more pre-upgrade validation steps where your business data is prepped and validated more closely. This can make more up-front work, but ideally it will be a more seamless upgrade. The downside is that it is much more of a team effort initially to upgrade, involving financial decision makers in your organization and a few developers. I do see the benefit of reducing the potential for error. The upgrade to 2009 did more blind, data dumping, while 2012 validates/examines what its doing.
I've been working for about 6 hours now hitting a few bumps, mainly because I don't have the answers to some of the financial bits of the upgrade. Some helpful upgrade whitepapers that were recommended to me can be found here. My environment is Microsoft's Refresh 3.5 with no layers other than SYS/SYP and a dash of USR. I just added a couple modifications to see how the new process would work. The demo data however is not perfect, and because it's a demo company, a good deal of the business inputs required for the upgrade will be guesses by me.
The first steps of the upgrade have you import a giant XPO (9.43 MB) into the USR layer that prepares the system for upgrade. The first step is a "Check upgrade readiness", which is essentially a bunch of batch jobs that do all sorts of validation on your system. I had 1228/1229 complete with one erroring. The results of the completed jobs seemed a little daunting. Be prepared to have your controller handy.
This step is not required, but let's face it...if you don't get past most of this stuff, it's almost guaranteed you will face issues down the road. The issues it brings up are for the most part, legitimate issues with data that do need to be fixed. I chose to ignore most of the errors as I didn't want to spend a long time guessing my way through fixing them, when I don't really know the answers.
The next step "Initialize preprocessing", I think just creates or fills these "Shadow_*" tables in the AOT used to store upgrade data.
Then you have 22 steps to complete, with varying difficulty. Some of these steps seem like they could have had a "best guess" option. For example, I had to setup country/region code mapping. AX 2009 was on ISO 3166-1 alpha-2, and AX 2012 is going to be on ISO 3166-1 alpha-3. Meaning 2 letter country codes to 3 letter country codes. This seems like something that can auto-populate. You also must configure it for each company. For me, this was 54 country codes such as "US" that I had to map to "USA" across each company. Just a little time consuming. Better safe than sorry though.
Other parts of the upgrade require the DAT company to have a number sequence, ledger account, and other small bits of data filled in to proceed.
The errors can seem cryptic, and if you have any bad data in your system, the errors will easily lead you astray. They are pretty easy to determine via code and the debugger what is causing an error to be thrown. For example, the demo data had some strange unit conversions for a specific item in one of the companies setup. The company had 0 items, so the conversions were just bad data. The errors were just catch-all type messages. Some quick debugging and it was pretty easy to track down.
I've put in a few long nights after work, so I'm taking breaks in between so I don't wear myself out. My next steps are:
- Preprocess data on live system
- Run live preprocessing scripts
- Country/region upgrade
- Run delta preprocessing scripts
- Preprocess data in single user mode
- Enter into single-user mode
- Run single-user mode preprocessing scripts
The single user mode stuff I believe basically bulk copies the prepared data from AX 2009 to the AX 2012 system and finalizes it.
The perk of this is supposed to be a shorter downtime to actually go live. Stay tuned!
I feel your pain . Did same thing and I was swearing all time :) Looks like the 2009 team left and 2012 it's built by new people .
ReplyDeleteCan you contact me regarding this post at arijit[dot]basu@gmail[dot]com
ReplyDeletedoing a test upgrade for a customer using a CRM module only (2009 -> 2012).
ReplyDeletePre-upgrade check list kept rambling about some project posting profiles that were missing.. while the customer doesn't have the project module. Nice one :)
not to mention that the database is full of records related to non-existing company accounts deleted ages ago (but that's 2009 issue). used a stored procedure to get rid of those.
Most important, don't skip the errors related to the Enterprise Portal! if you have any modifications there, don't forget that the Title web part is gone now, and you cannot reference application proxy in .Net code of the pages. We have EP modifications for that customer, so it took me some time to get through.
The current frustration is when I finally hit the code upgrade phase, the upgrade guide is quite cryptic about importing AOD files. I imported SYS and SYP alright, but as soon as I move on with importing VAR and USR, it doesn't let me select anything other than USR.
Looking through the classes that do the import. Code is heavily commented, but most of the comments don't make sense.
To be continued..
@offenmeier: did you solve the problem with the usr-layer-only import? I've got the same situation here with usr and var layer, and only the option to import the usr layer...
ReplyDeleteTo import into the different layers (VAR, CUS, USR) you need to set your AX Client Configuration to those layers with the appropriate development code. The Upgrade Checklist will only upgrade AODs into the current layer.
ReplyDeleteDear Alex,
ReplyDeleteGod helps you in your experience, but i have one question about the following stage..i hope you can help in it..
1. Run live preprocessing scripts
I started doing it with no problems till i had 4 problems with duplicate data (Records already exists, and can't be inserted) in the following tables:
a. PurchLineHistory.
b. MarkupTransHistory.
c.HCMWorker.
d.DEL_VendPurchOrderJourSplit.
So, i could not continue doing the steps till to solve these issues.
So, i decided to change the indexes in these tables to continue doing the upgrade process.
Unfortunately,i'm waiting this process since two days on the LedgerTrans Transformation at 99.84%. and i had to stop it because i did not get any response.
Note: this upgrade for Live customer and he has almost 300,000 records in the ledgerTrans table in whole companies.
Any advice will be appropriated.
Regards.
Hamza
Dear Alex K,
DeleteI went through your blog, wherein you have upgraded almost more than 1229 jobs from AX 4.0 to AX 2009 [Please corretc me if i am wrong].
We are upgrading from AX 2009 to AX 2012. I have around 910 jobs to be executed during "preprocessing upgrade checklist" on AX 2009 for upgrade.
Its been almost more than 4.5 days but the batch is still in the Waiting state with no job being completed off 910 jobs.
Following are my precise queries:
1. How much time is the step-"preprocessing upgrade checklist" going to take to get over for the data of size around 80GB.
2. Won't the status change to "Executing" from "Waiting"considering the fact that almost more than 4.5 days are over.
Can you please through some light on the above queries since i am clueless whether the batch is executing or not.
Thanks & Regards,
Muneeb
dark.illusion007@gmail.com
I'm having the same problem where it never changes from waiting to executing. How did you get around this?
DeleteHello Alex
ReplyDeleteIs your upgrade finnished?
How long did it take to complete?
/Henrik
@Henrik,
DeleteI did manage to finish the upgrade, but I wouldn't trust the quality of *my* upgrade for a production system, as there were some hurdles I had with the bad contoso data where I would just drop a table to move past a mostly senseless error. It took me around 40 hours with no validation. I'd say you could easily do 10x that or more for a live company to do a real upgrade. Mine was just a sandbox run at it.
For Jobs Still WAITING status : Please check ur batch Job History/Batch Schedule, to run the waiting batch job there, there must be some batch jobs which are in executing or waiiting state which needs to be first cancelled so taht the upgrade batch job runs !!
ReplyDeleteIf batch jobs are in waiting state that means the start time has not arrived yet or the batch framework is not setup correctly. There are 2 important things to look at for batch jobs, server configuration (which servers are batch processors) and batch groups (this is where you assign the batch group to the server). For each batch group that you want to use, you need it assigned to a server that is flagged as a batch server. If you make any changes then you need to restart AOS.
ReplyDelete