I can't comment on this specific implementation, but it depends on your tolerance to risk. If you're going for a backwards compatible change to some thing that

I can't comment on this specific implementation, but it depends on your tolerance to risk. If you're going for a backwards compatible change to some thing that is quite complex, it's not unheard of to create a suite of tests that fully describe the features of a piece of software (if they don't already exist) and then compare the 'old' and 'new' results. This then allows you to understand if you've changed anything, and can even highlight where you've fixed bugs in the old codebase. I've done something similar before when refactoring a reasonable sized portion of legacy code that had no unit tests (code was old + organicly changed over the years), plus a good number of configuration options that all had to be backwards compatible (work like it used to, or have a good explanation why it doesn't).