Keeping private fork requires non-trivial design skills. In the ideal case, you'd add hooks as part of public improvements (item 2), and use only those hooks in your private changes. If you add appropriate tests to public project, this will increase the chances of your hooks staying unbroken.
I'm not sure that any of these ideas will be news to you, but a few suggestions:
- Add test coverage for your customizations, so that after you pull upstream changes, you can confirm that your software still works (or at least runs)
- Relocate and/or rewrite the custom code within your repository so that you are less likely to encounter merge conflicts when retrieving upstream changes
- If possible, fetch upstream changes on a regular basis so that you detect upcoming conflicts early
- If possible, petition the upstream project to add support for plugin modules, so that you could develop your own customizations in isolation (albeit still with some API-level dependencies on upstream)
Are your customizations definitely specific to your own company? (a gold standard could be to publish your own software as FOSS and attempt to build a supportive community)