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.
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!