Going from Oracle/DB2 to SQL Server specifically, there are a few unique issues (in addition to the very good ones Johann has already mentioned). Maximo's supported configuration of SQL Server is case insensitive, whereas DB2 & Oracle are case sensitive. So on fields that are standard ALN fields, you could have ABC in one, Abc in another, and AbC in another, and those all be allowed. In SQL Server those will be treated as the same thing, which can be a serious issue. To be clear, it's a bad practice to do something like that in Oracle/DB2, but in all of our conversions we've identified some records like that.
Another Oracle/DB2 to SQL Server specific thing to be aware of is that while SQL Server has support for sequences since SQL Server 2012, Maximo does not use sequences on SQL Server. They use a unique process for getting the next value, so make sure you set the proper maximum in the maxsequence table before turning on the application (it gets added to a cache, so updating after app is started will cause you to get sequence errors on startup). We see a lot of people load in the old values from DB2 or Oracle, where these values don't matter.
For this to be successful, the biggest piece of advice I have is to lock down configuration changes from the last test run to the production run. When the goal line is constantly moving, errors occur or data is lost. Schema related changes especially should be locked down. And if you go beyond that for reports, KPIs, etc. you can migrate all the metadata related records in advance of the outage which allows you to focus on the transactional records for the cutover.
------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH
------------------------------