Platform change Sun Solaris/Oracle to Windows/SQLServer

There are several items you must consider in this move:

1. Security change LAUA->LS. This can be done in version 9, if you'd like. If you have HR, and use HR security (e.g. HR09/10, some PA forms), you will need to consider migrating it to LS security as well.
2. Database change. Due to the differences in reserved words database object names may not necessarily be the same in MSSQL vs Oracle. Hence, any items (besides LSF) that point directly to a database (LBI, Crystal, Processflow, interfaces, scripts) may need to be looked at and modified.
3. User tracking change. Lawson tracks users in Windows in a different way than it does in UNIX. In UNIX most internal references to usernames (such as audit trails) are done by username. In Windows every user gets uniquely generated number (a.k.a. NTID), and many internal security items use that number. Lawson's primary LDAP in Windows installations also has "translation" records that link Windows SIDs (which correspond to usernames for users that run batch jobs) to the NTIDs. So, in general you cannot simply "copy" UNIX environment information to Windows and expect it to work. Moreover, simple copies will break audit trails, jobs and some other items. So, some (e.g. our group ) developed a series of scripts and procedures for such migration that "re-codes" user and security information correctly in cross-platform migrations.
4. Authentication. If you are not currently BINDed to secondary LDAP (such as AD), you may want to migrate passwords and other items (again, all possible to do, but only via third-party tools and scripts; this is not something that Lawson provides).
5. Other Lawson and Third-party products. You may have other products linked into Lawson (BSI, Essbase, EDI, DesignStudio, LSO/LES etc) that may require platform change or additional customizations when migrating from one platform to another
6. Processflow. Perhaps, the most common item that needs to be changed in LSF 9->10 migration is Processflow. Note that LSF10 does not support PFI, and requires IPA for processflow. IPA is based on Landmark technology, and requires staging a Landmark environment, possibly on a server different than the one that runs LSF environment. Note that IPA implementation will probably (that's no longer a requirement in most recent ESPs) result in federation between LSF and Landmark environments, which may require additional work if any custom login interface or external endpoints are to be used.
7. SharePoint/AD. While more recent ESPs of LSF10 no longer require each workstation to be a member of the same domain that contains your LSF server, certain AD security items need to be set for the actual servers in LSF setup. Moreover, the actual AD is required somewhere on the network. In other words, your LSF server has to be a member of some domain. It cannot simply be a member server in a workgroup (as far as I know that's still the case, even in recent ESPs)

Bottom line - there is quite a bit of planning one needs to do when migrating from the existing LSF9 to the LSF10, and platform change adds several important items that need to be dealt with.

Re: direct upgrade from 9.0.1.0 - if you do a cross-platform upgrade (from UNIX to Windows), you cannot simply upgrade by copying things from UNIX to Windows (especially GEN/LOGAN and primary LDAP). Most probably you will have a new installation of LSF10 on a different box, and will migrate items using custom third-party scripts and procedures. And in this case the version/ESP of your UNIX environment would not matter much.