To customise or not to customise...

[danlee73]

..that is the question.

I have been using Sugar OpenSource since version 3 and I am coming to the conclusion that the cleanest way to run it is to run it "out of the box", as it is. Others in NZ I have talked to have said the same.

I have found that whenever I have customised (either through the admin interface, through code changes, or both) that whenever I have come to upgrades the changes I have made either do not work, or require largish amounts of work to get to work.

I'm interested in seeking other peoples' views about the degree of customisation. Our current incarnation is an "out-of-the-box" install. For those that successfully customise, and can easily manage the upgrade process, I'd be interested in hearing how you do it.

Many thanks in anticipation....

[george_bbch]

Hi danlee73

Well, if you need a feature which is not available in the standard OS and will not be implemented in the next one or even the one after, or you simply cannot afford to wait until then, then you can a) use another OS or commercial flavour that has that feature out-of-the-box, or b) customize your system, either on your own or by using a skilled company / developer. Do you have other ideas?

Let me give you an example: we need automatic discount handling for our customers, e.g. a customer has a fixed discount level that must be applied by default on all its quotes and orders, and that's not implemented in Sugar Pro 4.2 and AFAIK will not be in 4.5 either. Of course, if you need not one but several new features it's more difficult, if not impossible to find another out-of-the-box solution.

In case a) you very probably get sticked to the company who provides you the custom system (which in most cases is the same that develops it, even if the development can be actually outsourced), at least for support and update purposes, and this drastically limits your freedom of choice on the long run. Actually, most of us will probably look for a reliable long-term partnership and not move to another one every now and then, but don't like to be forced to choose it (only) because it's the only one who can offer what we need.

In case b) you or the developer must update the system each time you decide to make an update for the standard code. I suppose this is not trivial, but with a skilled partner you can handle it. Probably the best choice would be to use the services of SugarCRM itself for these customizations, if you want to minimize the risk and of course your budget is prepared for this, otherwise you'll find other offers with better price/performance ratio.

Ultimately, when your custom feature becomes available in a (future) standard version, you can move back to this one, provided you find the way to migrate the required data that's already stored in the system (e.g., if your customization extends the database structure, relationships, etc.)

We've opted for b) and another partner than Sugar, who reacted much faster and gave us a much better offer. Will soon try an update and let you know of this experience

Cheers,
George