I once faced a similar issue - I needed a CRM that could also manage the production of standardized proposals and track them from creation through sending and the client acceptance / revision / rejection stages and then create a project and assign resources dynamically.

All the systems at the time could handle some of that - but none did all of that. Building the entire thing from scratch was too expensive and rife with risk.

What I was able to do was find an open source CRM (SugarCRM) and then hired out the development of the additional features. By building on the backbone of a system that covered most of the needs, and still allowed us to extend the product ourselves, we got just what we needed - within a budget we could live with.

There may be an analogous opportunity for you to do the same.

Happy to discuss some of the pitfalls and challenges we encountered along the way.

Trying to match up your needs with available cloud apps is a common challenge, especially if you have hardened requirements that may be very unique or tailored to your organization. In that case, barring a 1:1 fit around each discrete app, you'd want to include configuration flexibility (to include solid APIs and/or integration add-ons) in your assessment of potential tools.

You'll definitely need to go through the grunt work of establishing a set of selection criteria and evaluate your potential solutions against that criteria, as well as factoring in the tradeoffs associated with loosening "requirements".

This can be a pretty complex exercise, so you may need outside assistance. But, I'd start by determining what your true critical requirements are and examining whether you can find any 1:1 fits for requirement categories. It sounds like flexibility in app configuration and the ability to develop modular extensions to the app would be important selection criteria (in order to accommodate tailoring options). For capabilities where you find no (or a very weak) fit, you'd want to be able to integrate with apps that you build on a solid, compatible platform-as-a-service offering.

I think Dave is right: first, you need to retro-specify your current system in order to identify what it the business logic that you want to retain. Even though it might be old and clunky, your current system probably embeds a lot of experience and best practices that were developed by your company over the years.

Once you have a clear picture of where you stand, the next step will be to identify what are the features you can improve (or maybe even remove altogether). Ideally, you would also identify the underlying processes and look for new solutions to them.

Let's take a specific example: business expenses. For a long time, people were expected to gather their receipts, fill in an Excel file with the amounts matching those receipts, printing that file, getting it approved and signed, and would be paid at the end of the month with their salary. All this can be replaced by a solution such as Expensify which allows you to take picture of receipts and manage everything online from there.

In summary, what I'd do would be to identify your core processes, then the key requirements for each process. Then I'd look for either a solution that includes most of what you need, or for SaaS applications of record that are interoperable and can help you manage each individual process seamlessly.