Anyone out there who feels there instance has too much customized code to even attempt an upgrade to LN?

I just want to know how too much customisation would affect to upgrade baan to LN?


Viplov

...although I've spoken to many people who THINK they run uncustomized :D

Any upgrade has its own set of challenges. It is a good time to get rid of redundant customizations and to rethink your business processes.

...although I've spoken to many people who THINK they run uncustomized...

I think there are a couple of issues with customisations:
(1) Where a customisation is required to match the business process requirement (alter the processing logic to provide the required outcome) without extensive workaround
(2) Where a customisation yields labour savings through ease of use, linking of processes and/or reduction of errors, improved controls etc (exception and summary reports etc)

In the case of (1) this is a must have in case of (2) simple cost benefit analyses provide the answer.

As to what is too many, again it will depend on cost benefit analyses. Perhaps another package would provide a better business fit.

What I was actually trying to say is that customizations are a part of life. They are what they is and they should not be preventing an upgrade.

Having said that, one of the benefits of upgrading your software is that it should offer more ou-of-the-box solutions that make current customizations redundant.

And having said that, I would think that the main benefits of upgrading to LN are in things like web-based solutions, better planning engine, integration with other packages, etc. etc. None of these are typically customized on site. Instead, the vast majority of customizations that I've seen in my carreer are mainly done to make Baan behave more like the legacy system it replaced.

If you calculate solution maintenance in a customization cost/benefit, then very few would make the cut.

We did a c3 to c4 upgrade last year and managed to go vanilla after discovering that many of the customisations we'd had written in the first place we no longer being used. We also discovered that for customised reports we now had the skill to write inhouse just using Baan reports without customisation.

Cheers
Neal

We recently did a Triton to Baan IVc4 upgrade. The issue for us was not if there were to many customization, but rather how do we handle migrating from the customizations to native Baan code.

1. Do you replace the customizations during your upgrade?
2. Do you migrate the customizations and replace them later?

We chose the latter option because it would give the users more incremental changes. Right now Baan IV looks very much like Triton to the end users. As time goes on we will replace the customizations as we can.

You can't let the customizations stop you. We had a lot. For example, the item group field grew from 3 to 6 characters between Triton and Baan IV. Every single script that had something like "where tiitm001.citg='123'", and every form and report that used the domain, was broken (and there were a lot of them). We just had to spend weeks slogging through them and fixing each one.

You can't let the customizations stop you from moving your business forward.

Customisation required additional work.