Regarding your questions.
Ports to be opened are mentioned in the installation documentation but I believe it is from 6000 to 6114 and may be additional ranges for specific functionality (I believe debugger uses ports somewhere in the 5000 ranges)
The file paths are by default configured on the integration service (processes tab) if you use the default parameter settings like $PMSessionLogDir, $PMSourceFilDir, $PMLookupFilDir etc. so you can easily switch this. to windows file directory.
What you definitely need to check is the use of command tasks etc since this needs to be recreated to windows commands e.g. if you use a command to create a file list for indirect source files.
Another important thing will be checking the sessions if there are hardcoded unix file paths configured on sessions etc (or maybe in parameter files.) instead of using the $PMRootDir or other parametrized file paths.
Hope this helps
This topic has been discussed numerous times before, so here are only a few very important points:
You don't have to change any path entry like $PMSourceFileDir\PRJDAC\ , just leave them as they are.
What you must check are absolute paths like /opt/u01/app/infa/infa_shared/SrcFiles ; these paths must be replaced by either UNC paths ( \\server\sharename ) or by paths pointing to "local" hard drives (like G:\Infa\infa_shared\SrcFiles ).
Unfortunateyl it's not really easy to identify all these paths. At one of my previous customers we have achieved this by exporting all workflows to XML files and then parse those XML files for absolute file paths. That works well.
Please also observe that the security context of a user ID running a Windows service (such as the Informatica Service manager, infasvcs.exe, Windows service name is e.g. "Informatica 10.4") is set up before any drive letters are mapped; this means that there's no chance to use e.g. a network mapped drive U: in any PowerCenter workflow, that can't work. You will have to use UNC paths here.
This holds true even for batch files / PowerShell scripts called from within some PowerCenter workflow.
Next point is that Operating System profiles simply don't exist under Windows. So if this a license option you're using, you can forget it under Windows, doesn't work.
Next point is code pages. If, for example, the Linux box works with UTF-8 as its native code page, then you'll have much "fun" setting up your Windows boxes in a similar fashion. In fact I have never seen a Windows machine running in UTF-8 until now (but then I haven't worked with more than app. 50 PowerCenter customers worldwide yet, so please take this statement with a grain of salt).
One potential critical point is shell scripts, operating-system commands in command tasks, and the like. Here you might have quite a bit of work if your organisation uses them heavily. Again, the easiest way to find them all is to scan XML exports.
Again, these are the most important points off the top of my head.
Are we need to change file path manually if we are not using the default parameter settings.
If we need to change manually is there any best way to do it as we have more than 100+ workflows running in Production.
Best way forward is to manage this prior to the migration, try to parametrize as much as possible which will make the migration itself a little bit less painful.