I understand the problem.  For this specific deployment issue, you might 
consider whether it would work to alter the krbtgt DB entry such that the 
kvno in the key data 1 but the keys are the same, then wait for all of 
the tickets to turn over.

Further confounding the issue, we use a kvno of 0 to represent an omitted 
kvno field in the ASN.1 marshalling of krb5_enc_data, both incoming and 
outgoing.  So, for instance, I understand that Active Directory KDCs 
generally omit the kvno in a cross-realm TGT, and we have code in the 
current kdc_rd_ap_req() which handles that by checking the last few 
kvnos.  That code relies on the omitted kvno translating to a value which 
means "the most recent kvno" to the search function.