We've used this pattern in an warehouse management system in a company I worked for years ago.<p>Old version had almost all the logic in PL/SQL, some Qt forms for high-level management, and C++ console apps (warehouse processes) running on portable terminals through telnet (so in reality these were running on the server, and portable clients were telneting to it to control it).<p>First we introduced XML-based protocol between C++ app and portable terminals, and a .net client running on these terminals to replace telnet. This allowed for a simple graphical interface instead of text-only, so there was a good motivation for customers to upgrade. Also it separated the parts clearly and allowed to mix and match new and old parts in the system.<p>Then we introduced J2EE application server, exposed the database through hibernate, and new processes were written in java (jbpm to be specific). They still used the same XML protocol and .net client, so old C++ processes could call java processes and vice-versa.<p>New processes required the possibility to call PL/SQL logic so the features that were needed were exposed through J2EE services to the java processes.<p>Finally we added a way to write new management forms in Eclipse RCP.<p>We also planned on moving the logic from PL/SQL to J2EE completely, and becoming database independent, but we never got to that.<p>The rewrite was never completed, there was a merger in the meantime, and we switched tech again, at which point most of the team left :)<p>But what we finished was working reliably, no features were lost, and as far as I know some customers still use the old system, some use both, some use the new system.<p>The thing that made it easy to do, but also hard to finish - was the logic in PL/SQL. As long as we left that be it made moving everything else easy. But at the same time it was a constant temptation to just call the old PL/SQL function instead of writing a new J2EE service, and finish the task at hand faster.