Having done a fair few of such upgrades in the past, I'll chip in with my own view as well.
And it will probably not be entirely without controversy.
Scrap and rebuild
My advise to you would be: scrap it. And rebuild. And since you indicate you've already received a "very high" quote for the work, my guess would be that this is more or less what the vendor who quoted, has in mind. This remains speculative though.
But I'll sum up the reasons why - just keep in mind, I have nothing to base this on but own personal (anecdotal) experience, and what you've shared with us.
It's old, and it's costing you money
IT was put into place about 3 or 4 web developers ago. I'm currently without a dedicated web developer, though I've got someone I'm training (I also develop, but have really no time for a project this size). Due to a number of developers working on it over the years, there are a number of varied forms, styles, etc. The last guy worked hard to make it all look cohesive, but there are still forms that are used that are less than ideal.
And you have now come to the (right) conclusion.
Anyway, it has become a pain to work on
Paraphrasing what you outline here is; would be something like the maintenance cost of this beast is killing us, and it's no longer worth it.
Upgrading won't solve your problem (alone)
Nothing in what you say tells me, that you and your users are in any particular way unhappy with the Sitecore version as such. With the Page Editing experience, with the limited OMS/DMS capabilities (or if they are even used). All the problems you describe point to an aging codebase and the aches and pains associated with it; and the increased maintenance hassle in keeping it airborne.
Also; 4-5 different developers have been involved over the years - each with their unique coding approach, each with their own Sitecore background (or perhaps even lack thereof). I've seen codebases like that. They are what they are.
Just be clear; none of these problems will get fixed by an upgrade. Those require a rewrite.
Difficulty of this task
Nowhere near as bad as you might fear. The initial reaction - especially from non technical managers - tends to be: "But we've invested 4 years of development hours into this. No way we're scrapping it". Reality is however; code I've spent maybe 2 weeks to create for a custom solution, I could usually re-do in 1-2 days were I to scrap it and do it again. If you're just rebuilding without actually changing everything around, functionally, the task is much less cumbersome than one might be inclined to think.
In your case; you're also looking at .NET framework upgrades; possibly a shift from the soon obsolete Webforms to MVC; maybe take a look at that dated and likely not optimal HTML and CSS that's been clogging up mobile phones for years - add all that up, and the benefits of a rewrite become more apparent.
How to estimate the workload
I'll tell you this; it has very little to do with the amount of pages you have. Usually, content can be scripted across in one form or another - and the only thing that changes when a script runs through 100 or 1000 pages, is the time it takes to execute.
These factors influence the price, both to upgrade and to rebuild:
- Number of unique components. You may refer to them as "renderings", "sublayouts", "stylesheets" (shudder). Any way - unique building blocks that make up the framework of your site.
- Number of integration points, to any and all third party systems
- Information Architecture. If done really badly (and there was a lot of that going around, back around the time your solution was originally crafted) - then it might need to be completely redone. This has the potential to make your content migration significantly more difficult.
- HTML crafting; actually does affect how easy it is to componentisize. Again; the world has come a long way with HTML and frontend developer tools since the turn of this decade.
- Functionality. If for instance there's ecommerce functionality on the solution, this will significantly increase development time AND (more importantly) testing time.
And yes, find a trusted partner.
I simply cannot stress how important this is. Find one of the core partners in your region, the ones that live and breathe Sitecore, and have the right people around to get things done right. The worst thing that can happen in your case, will be to get another team of inexperienced developers on board to rewrite the solution, only to end up pretty much back where you are now - only shinier and with lighter pockets.
In summary
Your solution is upwards of 6-8 years old. Financially it should be written off by now; but the amount of technical debt (a term not chosen by coincidence, at all) is still crippling your platform. Likely taking up so much time, there is no room for new development. As you also state:
I also develop, but have really no time for a project this size
Get it re-done. To make it an easier sell to management (or whoever foots the bill); you might want to re-term this slightly differently; use maybe car analogies like "we're going to keep the frame and bodywork intact, but all the electrics and most of the engine parts need to be replaced" or some such. Whatever works.
But rebuilding is, in my opinion, your best course of action here.
I bring 12 years of Sitecore experience to the argument, since we're dealing with a highly subjective question here.
A few additional resources
