I will give you our experience refactoring LedgerSMB. We made a decision to do things differently early on and are still doing exactly what you describe but without a lot of glue methods (we have a few glue methods btw, just not a lot).
Life with Two Codebases
LedgerSMB has survived with two codebases for about 5 years and it will be several more before the old codebase is eliminated. The old codebase is a true horror to behold. Bad db design, Perl constructs like
IS->some_func(\%$some_object); along with code which shows exactly why the spaghetti metaphor is sometimes used (execution paths meandering between modules and back, and between languages, with no rhyme or reason). The new codebase avoids this by moving db queries into stored procedures, having a cleaner framework for request handling, and much more.
The first thing we decided to do was to try to refactor module by module. This means moving all functionality in a specific area into a new module and then hooking the old code into the new module. If the new API is clean, this isn't a big deal. If the new API is not things get hairy and that's an invitation to work a little harder at the new API....
The second thing is that there are plenty of times when new code has to access logic in old code. This is to be avoided to the extent possible because it leads to glue methods that are ugly but one can't always avoid it. In this case the glue methods should be minimized and avoided to the extent possible but used when necessary.
To make this work you have to commit to rewriting all functionality in a specific area. If you can, for example, rewrite all customer information tracking code at once, that means that the code which calls this from the old code is not hard to work with, and dispatching to the old code from the new code is minimized.
The second thing is that if you have reasonable abstractions in your place, you should be able to choose which level of the API to call and how to keep that clean. However, you should think about rewriting the portions that are calling your API so that they are quite a bit cleaner as well.
There are many areas of business tools that are irreducibly complex. You can't get rid of all complexity. But you can manage it by focusing on clean API's which specifically do what you need to do, and modules which utilize that API constructively. Glue should be a last resort only after considering that rewriting the rest of the calling code may be faster.