I too have put together SQL which will pump stuff out of Recorder (2002 in my case) in the tab-delimited text file format required for import by Mapmate. It is easy enough to do and works fine. The big problem is that there is no mechanism to transfer the unique NBN keys so that they are used or recognised in some way by MapMate!
The Recorder Importer DOES handle this and it means that records imported from MapMate get a key derived from MapMate's guk. If the record gets imported into Recorder more than once, Recorder will identify it as duplicate and allow you to update the Recorder copy with any changes made in the MapMate original. Also, because it is stored under a SiteID derived from the MapMate CUK, Recorder won't allow you to change it. This mechanism isn't perfect, but it does work pretty well.
What is needed is an equivalent mechanism in the Recorder to MapMate direction and this is something only Teknica Ltd. can do!
Without this, if stuff is pumped out of Recorder into MapMate it essentially becomes new, independent records and if, in due course, it makes its way back to Recorder, it will just be duplicated. Also, if changes are subsequently made to the original observation in Recorder, there is no automated way to update the MapMate copy. Finally, because MapMate will simply assign new keys to the records on import, that copy of MapMate will now "own" the record and will allow them to be changed.
So, yes, the mechanism that Les suggests works fine to get data from Recorder into MapMate, but you do need to think about the data-flow management issues it will create.