The SFSProjects table is not needed at runtime... neither are the foreign keys that tie the SFSProjects table to SFSUsers, SFSRoles, SFSPermissions, SFSRestrictionSets, and SFSPreferences. The SFSProjects is only needed at design-time for the security editor to keep the groups of objects together based on a "project." That's why the security script did not include the SFSProjects table. As for copying records from one table to another, that's perfectly fine... just make sure you turn IDENTITY_INSERT ON so that you can manually specify the primary key for the records... otherwise, the foreign keys will be broken.