Having a tool that does this kind of work correctly is, in my experience, very valuable. It may be slow but if it is fast enough, changing it to make it faster is not worth the risk of incorrect results.
Having said that, the current diff-procedure for each table lends itself well for multi-threading. The procedure probably loses most of the time in network latency when communicating with the (Sybase) database that might need to be updated. Having a couple of threads do this in parallel will help the throughput.
Let one thread read the records from a table from the input (MS Access) database and put the Access Pojos in a concurrent queue (e.g. ConcurrentLinkedQueue). Let a number of threads read the Access Pojos from this queue and execute the update procedure in parallel.
When there are no more records in the table, let the read thread put special "end of table" Access Pojos in the queue so that the update-threads know when to stop. Also, the read thread needs to pause when the queue gets too large (or use an ArrayBlockingQueue).
Repeat for the next table.
The idea here is that current source code is moved without being altered too much (which minimizes the risk of breaking stuff): the read thread gets a Runnable object with the current code for reading from the MS Access database and creating an Access Pojo (and does this in a loop), the write threads get a Runnable with the current code for comparing and updating the Sybase database.