Updating the solution is part of the normal maintenance of the solution. This can be done by the company using the solution (if they have their own Level 1 support teaminternally) or this can be done by the integrator company as part of a dedicated contract (Manages services). I have seen too many customers loosing time solving anomalies that were already fixed but not installed... I am convinced that on the long term this saves time.

If the customer doesn't perform regular update the gap will get bigger and bigger and possibily the current release will no longer be supported. Then you face an even more complex upgrade project.

Now I don't underestimate the effort this represent for the customer as an update should be approved with a testing phase (on a dedicated test solution) and change management should be done to help the users transition to the new release (UI change, new fields, new functions, etc.). And the effort is quite large as well on the integrator side especially is there are numerous customizations impatcing standard screens / objects / functions. To get the full benefit of the new release, ideally the new features are presented to the customer to see if there is an opportunity to improve the solution.

Note: for the integrator having managed service contracts including update for multiple customers allow to save some effort

To be pragmatic, I would recommend to group multiple releases in 1 jump (maybe once or twice a year). Including the database update in the same jump will allow the customer to have only 1 test phase for both. Ultimatly this update process will become a sound and familiar process.

Dear Julien,

I am V12 user. I have customized some screens. Not IT person, just doing some little stuff to help myself.

Standard Fields or Custom Fields has Activity Codes from the Standard : 80% I hide them or 5 % take out some unwanted actions or 15 % added spe actions to them ?

I am also scared on Upgrading the solutions due to those fields, I modified (Standard) / created (Custom).

Is there a way to maintain those changes upon upgrading

Or Do you I need to keep them on a "paper" + recustomize all over again at each updgrade ?

We never Patch, no experience. 

Little stuff by little stuff I added fields. I run my personnal Activity Codes search  : today I have a number of 907 in Screens / In Tables of 162 fields. I wrote abt 40 spe + entry point. I don't know if that's much...

I didn't take any note of what I have done. I just did it. I need a field, I add a field.

I am scared to run into error by patching + to loose time customizing screen again.

I would like to do stuff in sustainable way for long term. I would prefer to patch regularly every 6 months or 1 year.

Thank you in advance,

Did you add activity codes to all of your customizations? This is essential to make sure don't lose them during upgrades. 

Also, have you identified the business cases for immediate reasons that you need to upgrade right now?

The way you customize Sage X3 can have more or less impact on the patching process. 2 examples:
1/ If you want to hide a field: modifiying the related screen in the screen dictionnary will have an important impact (lower if only the field hidden is protected with an activity code and not the entire screen) but using the 'Customize page' feature will have very low impact (if not at all).
2/ If you want to add your own custom fields on the product record: you can add them in the table ITMMASTER and in the existing ITMx screens. This will make both the table and screen difficult to patch. But if you create your own customer table (ZITMMASTER) with the same index and your own screen (yet linked to the OITM window) you have almost the same result but without having to use activity code on he table ITMMASTER and in the existing ITMx screens.

Of course in some cases, you have no choice but to modify the standard elements but the less activity codes you have the less error you will get when patching.

Upgrade is a general recommendation, but at the end you have to respect the business constraints. If you have not much employee then maybe Sage X3 cloud or hosting can be a better option (not available yet in all geographies). To take the same example you did: this is like paying an insurance on the wheels of your Ferrari. 

I hope this helps.

A question along these lines can anyone describe the patching process if the client is using the Sage cloud version of X3 versus the on premise X3 solution?  What does the patching process look like when the client is using the Sage cloud?  Does Sage take care of the patching process and if so what does that patching schedule look like?  Do X3 cloud clients still have test environments into which the patches are initially applied for testing before the patches are applied into the production environment?  Also what are the limitations as it relates to customizations for X3 cloud clients?  Are they still allowed to have customized crystal reports are they allowed to have SPE's associated with the various functions in the system?  

Thanks,

Kevin

Kevin,

There will be slightly different processes depending on if it's a single tenant or multi-tenant cloud solution. It depends also on if you're using Sage's internal AWS hosting or it's done through Net@work X3 cloud hosting. Generally speaking, Sage will patch up the multi-tenant environments with plenty of notice ahead of schedule. I don't think that the patching only to a Sandbox environment process is in place yet. I know that Netsuite follows this process, patching in a Sandbox several months prior to the actual live upgrade in the Production folder. 

If you have single tenant you will have more flexibility on SPE mods, but there are still limitations. 

Hi Rafael thanks for the insights!