If you have to migrate to a new platform, try to get buy in from everyone that you're going to only match feature for feature, until the old one is turned off for the last time.
You can make decisions with upgrades in mind, but just push to get it moved completely first. You don't want to end up paying technical debt in 2 places forever.
Often it's best to have high test coverage when migrating. You can push this to be part of the current project if it's not there and it's some productivity anyway. I usually skip things that test/mock the code and just do things like UI or API tests.
Migrations may take much, much, much, much longer than anticipated. If you have a gantt chart of some kind, make sure it's not reliant on the migration.
This can be so different between some small company's website vs an enterprise SASS, for example.
What is your project? Who are the stakeholders? Who are the users? What are your resources and budget? What are your goals and constraints?
10 to modern Next is a pretty big leap, especially if you're also going to move to the app router. The code mods might help a bit but not completely. Do you have older React code (class components etc.) or libs (old redux) and huge state trees?
If so it might be easier to rewrite the whole thing.
I've had to do a few rewrites like that and would typically do an exploratory investigation of each approach for a day or two, trying to better estimate the difficulty of each by partially starting a migration and partially starting a rewrite. Along the way I'd come up with a list of must haves vs nice to haves vs nice to get rid of, and use that to make a final decision.
But realistically, IMO a rewrite is inevitably cleaner (maybe with some functions manually ported over) and more maintainable over the long term.
Partial migrations for something like this means a lot of technical debt in the future. Next and React move too fast to keep up with piecemeal migrations like this cleanly. It's a very unstable ecosystem.
I'd probably end up extracting out the parts into modular components wherever possible, separating the business logic from the Next stuff (routing and caching and building) and the state stuff (meaning keeping components as pure as possible so state can be easily provided via whatever framework is popular that year)
