Even Certik brought up the same issues as Rugdoc. This was the recommendation by Certik when it comes to the migrator function: We recommend to either removing such functionality on migrate; or having a timelock as the controlling party with enough delay for such privileged function invocations. The project shall also make clear statement or documents on how they plan to leverage the migrate functionality for proper usage.
Biswap did add a timelock but I'm not sure 6 hours is enough of a delay. There is also no clear statement on how they intend to use this functionality. The likelihood of a hard rug at this stage seems very low in my opinion but since the possibility is still there then it is fair to classify them as high risk according to Rugdoc's standards.
I have been part of rugdocs "group" for a while now and I can say that biswap is not looking like a rug pull type of deal to none of the people there. Are there some problems that needs to be resolved? Should it be a lot better coded? Could it be a lot better done? All yes to those but that doesn't mean that just because something is not perfectly made that doesn't make it a rug pull neither, those are very two different things.
I mean pancakeswap literally had a migration in it that was not keen on by any investor but accepted just because they are pancakeswap but definitely enough reason not to invest into anything else that had the same thing, while we are there we also seen pancake do an update on their token and now they have no migration. Does that mean pancake had a chance to rug pull people? Of course not but there was a mistake? Same logic with biswap.