The easiest way is to use generateChangeLog against an existing up-to-date database. That will get you new changeSets to get the database to the starting state. You will need a way to not have those changeSets run against databases that ran the old changeSets, though. Normally people will use changeLogSync or preconditions or just just a two-step liquibase update process depending on what works best for them.
You will want to go through the generated changesets and make sure datatypes and other details are all correct. Liquibase knows how to grab a lot of the standard object information, but there is some things it doesn’t know how to read.
I do also normally ask that people really make sure they need to go through the rebaselining work. The advantage with keeping your existing changelog is that is the steps you ran and tested before and you know that it works. If you switch it up it is introducing uncertainty. Updates with a lot of existing already ran changesets should not add a lot of overhead, and updates to fresh databases are often not done very often to justify the time and risk. Sometimes there are just a few changeSets that are unnecessary and expensive such as an index creation and then drop and you can just remove those changeSets from the changelog file individually. There are definitely times it makes sense to rebase your changelog file, but I always make sure to put in this caveat