You've mentioned a 'new server' so I'm guessing your migration consisted of dumping from 12.5.4 and loading into 16.0 (ie, you did *not* do an in-place upgrade of the dataserver).
In the case of copying a user database between dataservers it is up to the dba to address likely system table mismatches between the target dataserver's master database and the newly loaded database.
Primary mismatches of interest (these ensure a users's server login/role get mapped to the correct user/role in the database, which in turn affects the correct permissions assignments):
syslogins.suid <--> sysusers.suid , sysalternates.{suid|altsuid}
syslogins.name <--> sysobjects.loginame
syssrvroles.srid <--> sysroles.id
The prescribed (by SAP/Sybase) method for fixing these types of mismatches is to drop/delete all login/role/group/permissions records from the newly loaded target database and recreate all users/roles/groups/permissions via the appropriate system stored procs and/or T-SQL commands.
Alternatively you can directly modify the system tables in the newly loaded target database, though a) this method is typically not supported by tech support and b) it is up to the dba to understand the nuances of the various tables (eg, sysusers stores user/group/role data, with references to the local sysroles/sysalternates tables and the master..syslogins table).
For a discussion on patching roles in the newly loaded user database see: Cross database permissions problems | SCN . Keep in mind however that that discussion assumed the same ASE version for source/target. With a move from 12.5.4 to 16.0 you'll have to make sure you address old user-defined roles that may be sharing a server role id with a new system role (ie, you'll need to decide on how to go about re-assigning the server role id such roles); for this scenario take a look at how any new system roles have been added to other databases in the target dataserver.
-----
For other potential mismatches take a look at the ASE System Table ER Diagram and look for links that cross the boundary between the master database (top area) and user database (bottom area).
As for potential system table mismatches between user databases:
<db1>..syscolumns.encr* <--> <db2>..sysencryptkeys (when column's encryption key resides in separate user database)
<db1>..sysreferences <--> <db>..sysreferences (when RI constraints reference objects in a separate user database)
NOTE: There are several other ... shall we say esoteric mismatches ... that entail the master and/or local sysattributes table (eg, cache bindings, tempdb assignments, role hierarchies, remote servers referenced by proxy definitions), and while it's possible to copy these raw records (and update accordingly), the recommended approach would be reverse engineering the details from the source dataserver and submitting via normal commands/SQL in the target dataserver.
-----
As for the issue with the master..sysusers record(s) ... *shrug* ... I'm in agreement with Jeff ... no idea why the other person is referencing master..sysusers ... would need more details as to what issue the other person is trying to address ...