NHibernate 5.x does still support SQL Server 2008, so there will not be a trouble about this with NHibernate 4.x.
NHibernate has no trouble addressing latest SQL-Server, even an old version like NHibernate 4. Using the SQL2012 dialect is needed only for benefiting of some improvements, like paging with fetch - offset instead of row_number().
NHibernate does not care about the OS version on which it runs, provided this OS supports at least the minimal .Net Framework required by NHibernate.
Running NHibernate on a newer Framework than the one it was released for does not cause any trouble. This is due to the .Net Framework high retro-compatibility policy, this is not a NHibernate specific feature. So running whatever version of NHibernate on .Net Framework 4.7.2 or 4.8 does not cause any issue. (But only NHibernate 5.1.x versions and above are able of running on .Net Core 2.0 and above, or other .Net Standard 2.0 compliant targets.)
I do not know of any NHibernate specific consideration to take into account with the GAC, which I have almost never used. I do not expect any exists. I looks to me unclear what you are asking about the GAC. Some way I may interpret it, I would just say it would not work due to how the GAC work, not due to some specificity of NHibernate.
About migrating, you should do it incrementally. NHibernate follows SemVer only since NHibernate 5.0, so to correctly spot any breaking change and deprecation warning in order to fix them upfront rather than discovering them by testing, fix any current deprecation warnings if your application already have some, then upgrade to the next GA (up to 4.1.1GA) starting from your current version, review
the release notes
for it, fix deprecation warnings (from compilation and preferably activate NHibernate logs and fix deprecation warning logs you may see while running the application), and then move on to upgrade to the next GA. When upgrading from 4.1.1 GA to a 5.x version, check release note for each 5.x releases up to your target version.