Some time ago I moved my document archive from DevonbThink to Paperless.NGX. I have Paperless running as a Docker container on my Synology disk station.
4 weeks ago I started working more with DevonThink again and saved the PDF files stored on the NAS as indexed files in DevonThink. In addition to the indexed PDFs, there are already a number of notes in MarkDown format in the DT database.
After archiving a number of PDFs in Paperless NGX and updating the indexed folders in DevonThink, I’m wondering whether Paperless is ultimately an unnecessary detour and what the advantages are. OK, Paperless automatically saves the files in the right folders. All PDFs are first read in with ScanOCR and saved as searchable PDFs. This works better for some PDFs than with Paperless’ own OCR recognition.
The advantage of the solution is that the files are only saved once (on the NAS) and not on the MacStudio and the MacBook Air when I import them directly into DevonThink. And the structure of the folders and files can also be used without DevonThink in an emergency.
Do any of you take a similar route? Or does it make sense to actually rely completely on DevonThink again here? And maybe work more with automated rules when archiving files.
What was your motivation to move to Paperless NGX? And/or problem with DEVONthink? That’s not really clear to me from your post.
I haven’t really looked into Paperless NGX, but from a quick glance my impression was that it’s a nice option for people who don’t run macOS – and therefore don’t have access to DEVONthink.
My motivation for using Paperless was that the files are only stored once (centrally on the NAS) and I can access them from all devices (Mac, MBA, iPad).
Paperless can learn the keywords of the files and then automatically assigns the document type, tags, etc. And then automatically stores the files in a folder structure.
When imported into DevonThink, the files are on the Mac and via Syncstore on the NAS and the other devices.
I have to admit that when I was using DevonThink, I got bogged down with too many databases and simply wanted too much too quickly.
