You have to take care when doing this. Remember to rename all your constraints and triggers if applicable after the switch. Non-simple Case First, recreate your BaseTable with the same name under a different schema, eg clone. Using a separate schema will simplify the rename process later. Include the clustered index, if applicable. Remember that primary keys and unique constraints may be clustered, but not necessarily so.
Include identity columns and computed columns, if applicable. Include your new INT column, wherever it belongs. Do not include any of the following: Defaults don't make much of difference, but we're trying to keep things minimal. If everything appears in order: This will take a while, but not nearly as long as an update. Once it completes, check the data in the clone table to make sure it everything is correct.
Recreate default and check constraints, if applicable. Recreate each constraint, index or trigger in a separate batch. BaseTable to a backup schema and clone. BaseTable to the dbo schema or wherever your table is supposed to live. Needless to say, this is ideally an offline operation. If you have people modifying data while you perform this operation, you will have to perform a true-up operation with the schema switch.
I recommend creating a trigger on dbo. BaseTable to log all DML to a separate table. Enable this trigger before you start the insert. Then in the same transaction that you perform the schema transfer, use the log table to perform a true-up. Test this first on a subset of the data! Deltas are easy to screw up.