It sounds as though the table that you want to copy the data into, has an identity column assigned to it. For the situation that you have described, there are two solutions available, each depends on how this secondary table will be used.
If the new table will be used in a transactional environment and it must maintain correct relationships with other tables, then you will need to maintain the same list of primary key values. To do this, we need to understand how your values for the primary key column is generated. I'm assuming a non-composite (single column) key for your system.
If it's an identity column, then you will want to maintain this property for future inserts directly into the new table, but you will also need to insert existing rows from the current table with the correct ID values. This situation is common and can be solved elegantly using the identity_insert option.
Using identity_insert, you can override the SQL Server automatic generation process of the column value for the identity column of table, and explicitly supply your own values. Once you have finished inserted these values, you can turn the identity_insert column off, to allow the column to behave normally and generate sequential identity values. You will have to research this particular aspect of behaviour to understand exactly how the identity column will respond after you turn identity_insert back off, and having inserted a random series of values. From experience a few years ago mind you, I don't believe there is any problem here and that SQL Server just resume the identity column counter by adding one to the maximum integer value in the column.
If on the other hand your table will be used in a more static context, for example bespoke data analysis, then I would suggest creating a table without the identity column. The corresponding column in the new table will have the same data type as the source table and will maintain a foreign key relationship back to the source column to ensure integrity throughout the lifetime of the table use in analysis.
Using this approach, without the identity column, you can copy the data using a simple multiple row insert operation. A example of this is below:
It's important to remember that there are no restrictions, or very very few, that apply to a select statement when used as the source for a multiple row insert. Therefore, you should not hesitate to use any conditional constructs any other elements of the SQL language to ensure you insert only the data that you want. Often this feature is overlooked and people forget that the select statement need not be a simple one set query.
insert into destinationTable
Bessie Braddock: Winston, you are drunk!
Churchill: And Madam, you are ugly. And tomorrow, I'll be sober, and you will still be ugly.