How should I handle unknown primary keys? I'm working as a database-administrator at a school. Recently the school upgraded its pupil administrative software into a web-based solution. This works great, but this web-based solution is missing some features which we used to have. Thankfully the new administrative software enables the possibility to synchronize local databases with their online database through an API.

In my local database each pupil used to have a primary key like 2015XXXX where XXXX is some number. The online application uses a different system. As far as I see the identification number currently ranges from XXXX (number in the thousands) to XXXXX (ten thousands). I have no idea if there exists a logic in these numbers.

I prefer to use the new identification numbers, since it's a lot easier to keep pupils in my local database identical to the online system. However I wish to keep the previous pupils which don't have a new identification number. What kind of primary key should I give those, preventing a collision of primary key's?

I see some options:


(what I have done so far) I've changed previous pupils id's as a huge number. Pupil 20050123 becomes 1020050123. The school will not reach this number of pupils any time soon. But I have nog guarantee the online system won't construct big numbers?
Using negative numbers? Pupil 20050123 becomes -20050123
Other?
As you don't know if there's any logic in the keys you can't tell if a huge or negative number will lead to a key violation.
Without knowledge of the application I'd suggest importing the previous pupils in the new software to get a regular id is the way to go.