I agree with RichardK: your strategy is not restartable. I, too, would add a status-flag ... perhaps a timestamp that is NULL if the record has not yet been moved. In a transaction (which is generally essential when doing anything-at-all with SQLite ...), select the records, move them, and UPDATE the record to show its new status.
Maybe you subsequently delete the records from the table, or maybe you never do. There’s something to be said for having a history, and for having data in more than one place. And not just in case the power goes out the midd0q9aw@Rq!afdz;@@@ ... ;-)
If you are going to multithread this process (and I’m not sure that this will actually be beneficial ...), you will need to make sure that both threads do not select the same records at the same time. To prevent this, you would need to somehow select-and-mark a group of records, COMMIT that change, then somehow be sure that you process only those records (even if a competing process has marked more). This competition, and the extra steps needed to avoid conflict, just might obviate the actual need for concurrency. SQLite is very fast ... provided(!) that transactions are always used, so that “lazy writing” takes place.
