I would agree with the parent poster that game engines are more than frameworks. They often begin with a platform abstraction layer, contain a framework on how to structure your tools and data, often contain an embedded programming language, have custom data formats, and determine the syntax and semantics of how you build the rest of your game.
Then in order to move between one engine and another it is a far bigger task than just switching programming languages and frameworks (which in web development are very similar). You will need to do things like:
Re-import all of the external assets that you have created in external editors. Things like meshes, rigs, animations, textures, sounds, music, etc. These may require changes to adapt them to the new engine, and it assumes that you still have the original data for all of these (which is often binary and very large in size).
Then re-create all of the specific in-engine assets that you don't have external sources for. These are things that game designers often create and describe the elements in the game, like character, vehicle, item definitions, loot tables, experience curves, etc. In addition to these being engine specific they're also fairly manual to create.
This of course assumes that you can easily bring over the world/level data from one engine to the other. At best it will require sufficiently skilled programmers to write an exporter for the old engine and an importer for the new engine. At worst it will require designers and artists to recreate the levels by hand.
Then the last thing mentioned would be changing all of the automated processes to the new engine and educating everyone in the studio on how things are meant to work.
The web based analogy for all this would be rewriting the code in both a new language and framework, changing the frontend from HTML/CSS/JS to Latex (or something), moving the data in the database to another style of data storage, and converting all the images from PNG to JPG.