The business I’m currently working at is going through the process of upgrading from Vantage 8 to Epicor 10, using the cloud converter, with our close to 300GB SQL database taking around 6 days to complete the upgrade. With it taking 6 days our window for upgrading is at the moment only over a Christmas holiday.
There’s the possibility that if we archive data / reduce the dataset of the database we could upgrade quicker, however I was wondering if anyone here has come at this from a different direction or has technical knowledge of the underlying architecture of the cloud conversion?
I understand that, but please correct me if I’m wrong, the cloud converter is hosted within Microsoft Azure and not directly using Epicor’s own infrastructure? I’m also assuming that when a conversion occurs resources within Azure are assigned to the task on the fly as required. If Microsoft Azure is being used, and if the cloud conversion process is multi-threaded, is it possible to dedicate a larger than normal amount of resources to a specific conversion to expedite it or is there a defined
maximum?
My last conversion was from V8 to E9, conducted on-premise, and the speed of the conversion could be substantially improved with fast storage (for example a large RAID 0 array using SSD’s, the amount of CPU’s had diminishing returns). As an Epicor customer does anyone think it would be possible to reserve in advance substantial Azure resources to improve the conversion speed?
That’s interesting, however I suppose without the context of the conversions (were they V8 to E10, or E9 to E10, what tables did the majority of the data reside in etc.) it’s difficult to know if our own could match that sort of speed.
I’ve been working with Epicor since late 2018, and multiple conversions have occurred, and so far no one has passed comment that our conversion is “slow”. I’ll pose the question to them, however I’d have assumed that they’d have been a bit more pro-active
what tables did the majority of the data reside in etc
… for the quick and large conversions he’s heard of as I was under the impression that large amounts of data surrounding certain functions / tables negatively impacted any conversion (even back when just going from V8 to E9).
I’ll double check where our data is and come back to this thread…
Hi I was looking at your conversion pass 5 run from Feb and it seems there are a few areas we can improve. One simple example is where conversion cvtm0001 takes over 15 hours a quick look at this progress logic it is not optimized and easily could be reduced to 10 minutes. The code works well on progress but takes a long time with the 10M laborDtl records joined to their headers. With a Progress DB it is fast, with a SQL one at a certain level it gets very slow.
There is also cvjc0092 at 9.04 which takes around 19 hours again I suspect we can optimise for SQL this to around 30 minutes.
Please reach out to me on email and I will connect you with the team that can refine these aspects.
@Edge, this is why I point people over to the Cloud Upgrade. It’s these kind of changes that make this the best option (and IMHO the only option) to upgrade. A couple of years ago, a few of my clients didn’t want to go through days of conversion time to get to the latest version. When they heard it would be hours and they would be able to download the 2 versions of the DB (or even use an RDP session for a while), they started budgeting immediately.
Thanks!
