I don't think this is as intractable a problem as some of the doomsayers here make it out to be. It just takes work and tedium. Working for small businesses, I've had to do this several times and it wasn't a huge deal, just a few weeks of work. If you're getting paid to do it, why not do it, and then brag about it on your resume later?

Here's how I would approach the problem:

First, evaluate the source content (your big zip file). Did the old CMS output relatively clean HTML? Are certain sections (header, footer, main menu) etc. relatively consistent and thus easily templatized? Is the body text all in one div that can be parsed out? If you're lucky, the CMS was structured to begin with, meaning the title is always one field that produces one consistent HTML output, the hero image is another field, etc. If you're NOT lucky, the old CMS might've allowed rich text fields which become custom HTML. That may be trickier, but still not unsolvable.

Once you understand the source content, investigate your use cases. Who needs to be able to edit this stuff, and how often? What's their level of technical expertise (e.g. can they work with raw HTML, or do they need WYSIWYGs)? Do they need a proper publication workflow (drafting, user roles, previous versions, etc.)? You know, of all the stuff a good CMS does, what is mission-critical to retain during this "temporary" period -- but keep in mind that chances are likely that new CMS will keep getting pushed back, because if it's not a priority now, it never will be. So basically, you're being asked, despite what they say, to design a system that will likely BE the new CMS.

Here's the fun part. Now you get to compare and choose a new architecture for all this content. Your options, in no particular order:

* A bunch of flat HTML files that only devs can edit, by hand, with no modularization or templatization. Bad idea if you want to maintain any sort of consistency between pages. And you have to really love regex if you ever need to do bulk updates (e.g. updating a broken link, or changing a sponsor logo, across all the files).

* Move it into ANOTHER, cheaper cloud CMS. It would be dirt-cheap to host a Wordpress instance, for example, especially if you were coming from an overpriced "enterprise" CMS. If your bosses can't afford $1000/mo, can they afford $80/mo for a good Wordpress host (Pantheon, WPEngine etc.)? There are also headless options like DatoCMS, GraphCMS, Sanity, Prismic.io, etc. Headless means you get to design the frontend to your spec, and importantly for your use case, it means you detach # of visitors from the CMS costs (because you're caching the frontend with a CDN, and the backend CMS never knows or cares how many hits you get). Prismic, Sanity, and Graph offer free plans up to thousands of records; if you do a static frontend against that and cache it, you may be able to keep using that headless CMS for free or very cheap. Even if you have to upgrade, the starter plans can be affordable. There is a LOT of variance in CDN pricing, from ridiculous ripoffs targeting enterprise managers to very reasonable options targeting small-time devs who know such things shouldn't cost so ridiculously much. Negotiate with the wallet people to find a good balance between dollars and hours.

* If they really won't spring for that, how about a self-hosted CMS like Strapi, Ghost, Grav, Pico? Some of these use databases, others use flat-file Markdown folders, but in general they cost zero dollars (just a lot of time to configure and deploy)?

* If you really can't use a CMS in the meantime, you can make your own "janky CMS" by templatizing the reusable parts of the HTML code (headers, footers, etc.) into plain ol' PHP serverside includes, like the 90s. Then process all the other pages to replace those parts with the new templates, such that each individual page only has its unique content and not all the site structure boilerplate around it (now handled by your includes).

Next is the hard part. Once you decide on an architecture, you have to do the semi-automated extract-transform-load work, bulk processing your flat HTML files and either stripping them down to unique content and/or importing that content into your architecture, but it a cloud CMS (repeated API calls) or a self-hosted flat-file system (lots of new files, possibly HTML to Markdown conversions). But either way, you will end up in a much better place than with a billion flat HTML files. In other words, even if you don't CALL it a CMS, you should make yourself a CMS of some sort.

Assuming you get all the data in someplace, then you have to build a new frontend on top of it, reusing those HTML headers, footers, etc. that you previously stripped out. If it's Wordpress, you're building a Wordpress theme. If it's a headless CMS, I'd recommend using Next.js along with Vercel or Gatsby or Netlify. If it's a flat-file CMS, it's entirely up to you... whatever language or framework you're comfortable with. Symfony and Laravel are still good choices, if you like PHP. Other languages have different frameworks.

Eh... that's a simplified overview of the workflow. Feel free to ask for more details. This really isn't an impossible problem, just an annoying one. I'd also do it for/with you if you pay me...