I don't have too much experience in software development, but I've worked in small companies which had a good product but was suffering with implementing the new user requirements to the old systems, or reskin the old product with fancy stuff that are common and easy to do with the latest Javascript frameworks.
I have been thinking about this, and if the management decides that they need the product to be viable (and lovable) for many years more, they need to invest to the process. As I see it, most users of these companies were way more understanding (provided bug fixes are priority) and flexible than the management thinks. They were tolerant to UX I totally hated from the moment I saw the product. So informing them and asking their understanding for the reduced developer capacity and rollout of new features during the transition period would not stop them from using the product (most of these doesn't even have a competitor, so they don't really have a choice).
I would put the two most junior developers of the team on the task. Why? Because the newly joined colleagues are better in the new tech, since as they apply for jobs, they research what the current market requirements are, and the senior coders often don't know these stacks, either because they aren't interested in them, or they are working on the current code overtime which burns them out from reading IT news, experimenting with new frameworks or do anything related to coding in their free time. Senior coders who spend time with the above during their working hours are few and far between.
I would change the scrum meetings. Would not remove these two developers, because during the ceremonies they are kept up to date with the work the others do, but have a separate section on every ceremony to talk about the new stack. As a start I would setup a roadmap, and define these:

• decsion about stack (frontend and backend)
• servers
• major 3rd party services that need to go with the app eg. payment service,
• user authentication
• frontend design (preferably following the current one with less possible alterations. Any improvement ideas that come up can be registered in the backlog under a new epic called frontend improvements) probably with mock data (that helps define the payloads that are required from the API endpoints) and components, or create a complete corporate style guide. I am not a frontend dev, but I'd build something that has all of the reusable components and their variations (buttons, checkboxes, etc) and a guide how to customize them and add JS functions eg. Vue slots.
• backend define API endpoints with time scheduling for API documentation writing and then development (after the fiddle with the mock data on frontend, it should be quite clear what data tables and structure needed)
• connecting frontend to backend replacing mock data
• start adding new features or changes parallel with the old system
• define when to start moving the dev team members one by one into the new stack
• Invite key customers to start using the new platform
• Move every customer to the new system.

I'd say it can be done in 2 years, I wouldn't put too much pressure on the devs. As usual the roadmap has to be adjusted so if the team is just as good as it should be, they finish earlier and everybody's happy.
I am fully aware what it costs to pay 2 full time software developers for 2 years "doing nothing". But I also participated on the roadmap meetings where management stated that they want to increase the number of developers (in spite of the annual fluctuation of 2 people), and trying to force them against their will to work on a code that is full of errors and nobody of the seniors wants to touch, afraid it might collapse. As it often does. So the juniors say "there's nothing to learn here" and leave. On the other hand, the juniors are eager to understand the old code so they spend time to read it, and often delete hundreds of lines of unnecessary code without breaking anything. So hire them, put them on the new stuff and watch with awe what they come up with.
What do you think?