Generally, the older it is, the harder it is to redo. There's a lot of undocumented bug fixes that accumulate as a project gets older. Some things are so bad that you just can't do anything with it and it's easier rebuilt than done.
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.
More details?
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?
Most of the time, old projects just work.
I would migrante it
An existing code base, even one as recent as 4 years old, gives you something to test against. You haven't specified why you have to abandon it, especially as it's practically brand new.
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.