Further correspondence on tackling this:

ISC:
> Our operational advice for handling this situation would be something
> along the lines of:
> 
> - comment out the to-be-differently-failover-paired subnets from the
> server configurations that they're currently in
> - restart/stabilize
> - un-comment/edit to re-add the subnets as they now need to be
> - restart/stabliize
> 
> The servers on the first restarts will discard any leases that don't
> belong anywhere in their configured subnets.
> 
> On the second set of restarts, when clients renew (versus discover),
> they should be re-granted leases in the reconfigured subnets with the
> new failover pairings in action.
> 
> Almost certainly there will be some operational 'nits' floating around
> depending on how the clients behave etcetera, but the above would seem
> to be the course of least disruption - particularly in a large-scale
> deployment environment.
> 
> It's better than faulting the database entirely on the secondaries,
> which could be quite time-consuming to recover.  We also know,
> operationally, that it will work to establish the new failover
> pairings correctly.
> 
> Could someone manipulate the leases files to retain the existing
> leases through this?  Possibly - but I would not like to be that
> sysadmin.  Safer would be to discard the leases and let dhcpd take
> care of things itself.
> 
> Let me know what you think - and apologies that there aren't any
> quick-fix answers to this one, although I doubt that you're too
> surprised?

Re: operational fix - I'll pass that along but I'm not sure if that is usable in our situation.  With the config file generation and dhcpd restarts being handled by the grid master it adds another layer between the admin and the server.  Normally this is good but it makes it harder to do something like your suggestion.