lonlyspartakos, I feel your pain.
In the dark past I've done such a thing, just to have a similar event happen. Lesson I learned here, don't use the primary key for anything other than as a unique record ID.
The issue with the article given in
CW post (#4) is that the underlying autonumber is the stored value - hiding the true data, IMHO, not best practice.
To clarify.
In the article cited, for the autnumber field, the ["EMP"0000] format is given. The resulting displayed value in the table is EMP0001, EMP0002, EMP0003,... EMP9998, EMP9999... EMP(maxLng); however, the actual value stored is 1, 2, 3, ... 9998, 9999 ... MaxLng. Of course, when you click in the field, the EMP0001 becomes 0001; however, that may not be enough of a clue to for the unwary as to the true nature of the stored data. Thus, the unwary may attempt a query on [ID]="EMP0001" resulting in a data type mismatch error, when they should be building the query as [ID]=1. (Or in VBA, this will create the same error if one is trying to build on the perceived "String" when in fact the field value is the numeric portion only)
Jforb's link is certainly one option and is along the same lines I've used in the past. I would take his suggestion one step further by inserting a new field into the data table, if needed, set the indexed to "Yes No Duplicates" to store your new customer id then revert your primary key back to the numeric only.