Now that you say it, that does sound like a viable solution. The issue with it is the duplication of code that would ensue. We did not want to transform class-to-class (that is config v1 class to config v2 class) because it would somewhat break the initialization of config v2 class as well as remove the validation provided by YAML::Serializable::Strict. Additionally I wished for this solution to be generic (just define the rule-set which is easily readable and transform from anything to anything), having the in-between type structure pre-defined would be somewhat problematic in case someone was going to create a new rule set in the future and had to do all that. There is also the issue with optional keys being unused and how to resolve that. I am well aware that this does not really make sense, but we just want to make the future extendibility as easy as possible.