As stated in the article Avoid Forking the Code:
Any time you find yourself about to make changes in mojoPortal code you should stop and try to think of a creative way to accomplish your goal without doing that. Remind yourself that "All of your custom code should be in your own projects", this should always be your goal so that you can always pull the latest mojoPortal code from the repository without losing any custom code or getting any merge conflicts. The solution will vary from case to case depending on what you are trying to accomplish and you are free to ask in the developer forum and explain what you are trying to do and we "may" be able to help you come up with an idea. If not, then at least by understanding what you are trying to do it may help us think about new extension points we could add into mojoPortal to make it possible or easier to do what you are trying to do.
Also the article Cloning an Existing Feature provides another way to customize some features of mojoPortal in a way that still allows upgrading, because you can safely fork a CMS plugin feature into a new feature that is not sharing anything with the original feature. But forking the core of mojoPortal or directly modifying included CMS plugin features should be avoided completely.
Beyond that if the end result is that you cannot find a way to do what you want without forking the code then you should guide your customer to the right decision, it is not in your customers best interest to run their site on a forked version of mojoPortal that can never be upgraded. My advice is don't just be a "yes man" who never says no to your customers, as a professional it is your job to guide them toward a good decision and make them fully aware of the negative consequences of a bad decision. In the end I would rather that you and your customer use another platform instead of forking the code because eventually that bad decision will make the customer think badly of mojoPortal and it will hurt the reputation of mojoPortal.
Hope that helps,
Joe