If you had an application that is that old, then the likelihood that you'd ever archive data is pretty limited.
First off, many applications of that age have no viable archive process to begin with. They simply weren't written with longevity in mind. As such, the end-user would need to be crafting this process himself.
Second, even if you archive, you are likely to archive off the OLD data, not the NEW data. This would leave you in a state where the records physically remaining in the file have all the highest numbers. There is no way to change the AutoInc field to "roll over" back to 0 again. Therefore, the only solution would be to manually "renumber" your records starting at 0. While this can easily be done by dropping the key, setting all values to 0, and recreating the key, this change does NOT impact all of the other records that are pointing to that data. So, if I have a Customer record where the ID is 2000000000, and I renumber that to 4, I have to find all of my invoices linked to that customer and change the values from 2000000000 to 4 at the same time. Then, I have to find all sales reps and change from 2000000000 to 4 at the same time. Then, I have to find all my sales rep commission history records and change them from 2000000000 to 4. This continues for every record that points to the customer record, ad nauseum.
As you can see, the problem is not with the number of records, but with the record value. It only takes ONE bad insert to mess with an AutoInc field. (I knew of a user once who wanted to "test" his app with a fake Customer, so he used Xtrieve and manually put in a new record with an ID field of 999999999. He forgot to remove the test record, and another customer was added the next day as 1000000000. From that point forward, all of his Autoinc values were abnormally high.
By the way, Pervasive has the exact same issue with their X$Field.Xe$Id column in the DDF's. This field is NOT an AutoInc field, but rather is a regular two-byte integer field with values from 0 through 65535. If you keep dropping and recreating tables, the database creates new field ID values with a simple logic: GetLast key value, Add one, Insert. The problem comes in when the maximum of 65535 is exceeded. Instead of rolling over, the engine enters another loop like this: Subtract one, try insert, Loop until successful. The net result is that once you have reached the "last" Field ID number (because the DDF's have been around for many years), creating a new table can take minutes of processing time as the engine must search for an available Id number. The only solution is to recreate new DDF's, move all of the records over, an drenumber the ID numbers as you go. We actually wrote a tool to do this, for this very reason!