This product is not simply about coexistence, its about getting the flexibility and best performance from two very different platforms. Sites choose Progress for many reasons, not least that the best product for them at the time was written on the platform. Also, Progress databases are relatively set and forget compared to the competition and I regularly come across sites (outside of the legal sector, which does exist!) running very stable and well performing systems with 400+ concurrent users on a 500GB database without any need for in-house Progress DBA support. Not many SQL or Oracle sites can boast that. The negative perception of Progress aside, all sites that reach a certain volume of data have to face the fact that they cannot continue to run their reporting suite against their production database regardless of what platform it is on. Sooner or later, medium to large sites want/wish to move some of the reporting overhead hitting their live database to another platform. Not just that, they may also want to create a data warehouse or web database that hosts a subset of data from multiple systems, not just their live Progress environment. If the site is after something close to real time replication (not just a dump and load) then the platform for hosting this breakaway data set generally has to be the same as the live environment e.g. SQL to SQL replication via clustering or log shipping....or Progress to Progress via AI shipping or Fathom for Management. Not being an Oracle DBA I am not sure what the choices are there, but I suspect all real time replication technology is based on Oracle to Oracle. But what if the breakaway data set is part of a data warehouse accepting data from other platforms not on Progress or needs to be in SQL so the site can mount a website on it or leverage the SQL reporting tools they just inherited from their latest acquisition? For that matter, what about mergers and acquisitions that find themselves with a Progress and a SQL or Oracle platform...does the new head office forgo any centralised reporting until a lengthy and costly migration is complete? My point is that there are lots of reasons why a site would want to replicate data from Progress to SQL, not just because Progress has fallen out of favour. Why migrate from Progress to SQL only to find that doesn't support high production & reporting volumes on the same database either when Pro2SQL can be setup in three days and costs a fraction of what it costs to migrate.