The way user logins are handled and stored has changed in iMIS 15.1
In this new version of iMIS, all your users (logins in the Name_Security table) will have matching records in the UserMain table. Importing all these users into UserMain can have a snag though: it's possible for there to be the same login ID in Name_Security as one already specified in UserMain. That is, two separate logins could exist with the same login id. This is no longer the case.
To help you identify if you have this issue up front, the following SQL will detect any problems in this area, and alert you to clean up these issues. Please note that having this problem will not cause a failed upgrade, but the users affected will not be able to log in, and the only way to notice it would be to look through the DB Upgrade logs for notification messages (warnings) of which users are a problem. This SQL will enable you to know which users are a problem prior to upgrading.
This SQL will work on any iMIS 15.0.3 installation:
-- List out all logins that conflict between Name_Security and UserMain
SELECT a.[ID], a.[FULL_NAME], e.[UserId], e.[ContactMaster] as [Conflicting ID], f.[FULL_NAME] as [Conflicting FULL_NAME]
FROM [dbo].[Name] a
INNER JOIN [dbo].[Name_Security] b ON a.[ID] = b.[ID]
INNER JOIN [dbo].[ContactMain] c ON a.[ID] = c.[SyncContactID]
LEFT OUTER JOIN [dbo].[UserMain] d ON c.[ContactKey] = d.[UserKey]
LEFT OUTER JOIN [dbo].[UserMain] e ON b.[WEB_LOGIN] = e.[UserId]
LEFT OUTER JOIN [dbo].[Name] f ON e.[ContactMaster] = f.[ID]
WHERE b.[WEB_LOGIN] <> ''
AND c.[IsInstitute] = 0
AND d.[UserKey] IS NULL
AND LEN(b.[WEB_LOGIN]) BETWEEN 1 AND 60 AND e.[UserId] IS NOT NULL
ORDER BY a.[ID]
The best way to 'fix' the problems is to go to each conflicting user (ID) and change their login to something that isn't already in use.
For most people, the above query should have no results. If you get any results, fix them up by assinging new login IDs, and then run the query again until you get no results.