luis covered a couple important points i wanted to mention again: you'll need a new column for the ClientId in there somewhere.

we've done this in the past, and the way we tackled it was adding temporary columns to the end of the tables, that capture the old PK and FK values.

we insert into one table that has an identity() column for the new PK, and make sure the previously existing PK gets placed in the temp columns. with that in place, we can insert into child tables, by getting the new PK from the table and joining it against the migrating table(s) against the previous PK's;

our database didn't have data going deeper than three levels of PK/FK relationships, but we still had to migrate EVERY tables in FK hierarchy order, and also, comparing lookup tables(like user defined statuses) against values instead of PK, so the table TBCITY might have the value 'Miami' in two databases

but with different PK's assigned to them. those tables, and the values that reference them, need to point to a new combined table instead.

when it's all migrated, we can drop the columns that were holding old PK's.