Hi Bruce,

When you upgrade from APP9 to APP10, you have to separately uplift the customization to APP10. But, it is easy when comparing with previous versions. Because in both versions IFS use Layered Application Architecture (LAA), that means you don't need to worry about architectural changes like in previous versions. But, when you have more customization in current versions, your upgrade effort and scope will be high. Because, there will be a separate effort for code uplifting and testing.

But, it is normally recommended to perform a detailed analysis (before starting the upgrade) to decide number of CRIM objects (IFS Terminology: Configuration, Reports, Interface, Modifications) which you need to move in to new version. This analysis phase will help you to drop some CRIM objects, if the same requirement can be archived through standard functionalities in new version.

Further, it is worth to mention about IFS Aurena. Once you move into APP10, you will be exposed  to responsive and browser-based IFS Aurena user experience. If you have any client customization, you might need to uplift it to IFS Aurena client also (In addition to IFS Enterprise Explorer). Otherwise, you will not be able to use that functionality in IFS Aurena. 

Good luck!!

Thanks for your helpful reply. Probably a silly question but what do you mean by separately uplifting customisation?

Does that mean we will have to recreate the customisation? (Custom fields, events, tasks etc)

one other thing, will ifs apps 11 be able to handle our customisations?

BLLBrucemo,

In some upgrade projects I've been involved in, we checked per customization if a standard solution was available in the target version. If so, the user would be informed that current customization would be dropped in favor of the standard (as to lower the maintenance cost on the product it self).

If not available as standard functionality, we checked if it was really, really, needed as customization in the new version. If not: drop it.

So now you have a list of needed/wanted customizations. There are two types: those based upon standard settings of IFS (read: custom menu, custom fields, custom LU). These are part of the upgrade steps of IFS. You will need to test those when an upgrade has been performed.

Another type is that you or a partner has build in new APIs. These have to be brought over, compiled again (just for the check), tested and amended if not working.

Fact is: the less customizations, the better. 

Take special care for customizations that have been build but are now available, maybe, as a new module in IFS Applications.

Good luck with the upgrade,

Steve

Thanks, that is really helpful.

One question, would you say creation of lobbies and quick reports should be thought of the same as customisations?

Assuming they would also need to be considered when upgrading and included as part of regression testing.

Thanks

Bruce

BLLBrucemo,

Both lobbies (elements as well as data sources) and the quick reports are part of the upgrade plan (as all the material that is standard IFS).

Also for example the Application Configuration Packages will be upgraded.

Steve

Our Apps 9 environment did have a dozen or so customisations. We got rid of as many as we could when we moved to Apps 10, but the ones we kept we had to pay to uplift.

The less customisations, the better we think. We are in the process of trying to change our processes to remove the customisations and go back to as vanilla IFS as we can to simplify and reduce costs for upgrades, updates and the need for things like regression testing.

Lobbies etc. are considered Configurations not customisations I believe, but moving from Apps 9 to 10 you’ll definitely need to do testing on them as some fields have changed. For example with receipting purchase orders, the PO No. reference field changed to “Source Ref 1” in Apps 10, and there are probably a few others depending what you’re displaying on your lobbies.

Thanks for the response.

One thing am reflecting on after starting this thread, is what do you class as ‘customisations’?

When i refer to them, am thinking of:

Custom Events

Custom Fields

Custom Logical Units

Custom Menu’s

IAL’s

Am i thinking about it incorrectly? Are these in fact - configurations rather than customisations? 

I understand those to be Configurations because you as the IFS user can make them, whereas Customisations are things that IFS develop and get deployed e.g. via a Delivery or packages which change how IFS itself works.

Perhaps someone more experienced than me can clarify if this is correct 

No problem, its fairly new to me so still figuring things out.

So do you guys have a lot of configurations?

Yeah we do. We have a fair few custom fields/pages/tabs (Configs) which have made life easier, and we also have a handful of Customisation Mods too which are now making life hard (well, harder than they’ve made life easier IMO ).

Thanks Garak - am assuming even with the configuration changes you are making you still are having to regression test with each release? Or do you check bill of delivery and regression test depending on the release details?

Yes we basically regression test based on BoD details, in addition to a standard testing plan of things we check regardless of potential impact, which is just a list of business critical functions/areas.

Okay thanks for the info Garak - am a little new to IFS so big new world, but I am following the same procedure. Trying to limit the configurations a little as the risk of breaking something with new releases just gets greater, and regression testing becomes more time consuming each time.

We have very innovative users, who have had a taste of being able to make the system fit around their business processes, but i know it can cause more pain that way.

Trying to educate, and limit without hindering the business.. fine balance!

I’m still fairly new myself (using as end user for about 3 years, only learning config and management for the last year and a half of those 3) so still learning too.

The challenge you have with users wanting to “just” make changes to innovate is one we have to, and where we’ve found our Change Management process invaluable as a tempering and validation measure.

Our change management process outlines:

• The change itself
• Justification for the change
• The benefits of the change
• Consequence if its not implemented
• The risks of implementing it (both during and post implementation) - which can include the fact that it might make life harder down the track - and any possible mitigations (if any)
• The impact of the change
• Financial cost of the change

The above criteria is normally pretty good for us in most circumstances in ensuring the change is considered thoughtfully and safely by the parties requesting the change, management, and other affected areas, so that if the change does go ahead, the affected business areas understand the impact of the change.

Thanks Garak, its music to my ears as i have implemented the exact same process.

Have been there just over a year so completely new to IFS even as a user and previously there were no major ERP systems to lots of different pieces of software that was managed by the business themselves. I brought my experience from a pervious role that was similar in nature (completely different platform though!)

The business have come around to the new change managment process quite well, so am hoping using cost/benefit analysis and proper change controls i can temper the changes they ‘just’ (As you put it so well) want and find a sustainable way to keep with the latest versions without over-complicating things.

Curiousity, how many users are you supporting? Do you have a team or are you the sole owner?

We have around 150 users (approx.) that we support.

We have a team to support them, but currently I am the primary technical resource in that team (the others we had left the organisation). The other members of my team help with simple config changes. We also have a few “Super Users” in each department that provide support to their teams for day to day functionality, but technical changes come to my team.

My team is then supported by a couple external IFS partner consultants for things that are beyond our training/understanding.

Thanks for the info - we 250 core users. Similar setup in terms of super users, but they are fairly new to IFS also so trying to train them as best i can.

Unfortunately, for changes, day to day support, simple config changes, admin etc.. i am the sole person so its quite tough going. Am hoping to get more in my team to help cope witht he work load. We do have a developer within the business but not offically my dept so cannot call on as and when but the occasional favour!

Dealing with around 35-40 support issues per week, plus over 120 requests for change (most are simple config, custom events etc) with anything thats totally beyond my knowledge going via IFS partner consultants.

Cheers for sharing, trying to think long term on what the business will need.

Garak, you are absolutely correct.

Thanks for the replies, can I ask how IFS views customers creating their own API’s?

If we use PL/SQL to develop our own custom API calls, often copying IFS standard code from standard API. Is that okay? Or do we need an IFS developer license?

I recommend that you take a call with your IFS Account Manager to ensure that you are pursuing the optimum path for you and your business, and that avoids any risk of becoming painted in to a corner. My understanding is that yes, to do as you describe you would need a developer licence.

I hope this helps.