Migrated from Scholarcy to Zotero with plugins - 5 months of feedback

I'm a technical architect for a 50-person cybersecurity consultancy, and my team has to manage and cite thousands of technical papers, RFCs, and threat reports. We've run both Scholarcy's team subscription and a heavily customized Zotero deployment in production for different client-facing research teams.

* **Total Cost of Ownership:** Scholarcy is straightforward at about $9/user/month, but the annual commitment adds up quickly for a full team. Zotero itself is free, but the real cost is labor. Setting up Zotfile and Mdnotes with consistent naming conventions and sync across 20 researchers took me roughly 15 hours initially. Your monthly subscription now pays for that admin time.
* **Control vs. Automation:** Scholarcy's auto-summary is decent for a first pass, but in my environment, it often missed key exploit details or misidentified CVE numbers in dense technical text. With Zotero/Mdnotes, we enforce a template where every highlight must be tagged with a custom field for the related attack technique (e.g., `ATT&CK:T1566.001`). This is manual, but it makes our literature database queryable for specific threats.
* **Long-term Maintenance:** Your "configured Jira" analogy is spot-on. With Scholarcy, maintenance is paying the bill and dealing with their support for bugs. With your Zotero setup, you *are* the support desk. You'll handle plugin conflicts (Zotfile can break after a major Zotero update), sync issues with the Zotero WebDAV storage, and training every new researcher on your specific workflow. We budget 2-3 hours per month for this.
* **Integration Depth:** This is where Zotero wins unequivocally if you need it. Scholarcy's output is largely locked within its ecosystem. Our Zotero library, via the better-bibtex plugin, feeds directly into a Sphinx documentation build. Citations and generated notes become part of automated client report generation. Scholarcy could never do that.

If your primary need is quick, individual summarization and you don't have internal admin time to burn, stay with Scholarcy. If you need to enforce a strict tagging taxonomy, integrate notes into other systems, and have the internal DevOps tolerance to maintain a custom setup, Zotero wins. For a clean recommendation, tell me how many people are sharing this library and whether your notes are for personal use or have to feed into another publishing pipeline.

That's a fantastic, real-world breakdown of the trade-offs. The point about the subscription cost effectively "paying" for that initial admin labor is spot on, and it's a calculation a lot of teams miss when choosing a free, customizable tool.

I'm really intrigued by your team's custom field for tagging highlights with ATT&CK codes. That's a perfect example of the deep workflow integration you can only get with a flexible system like Zotero. It turns a literature library into a genuine knowledge base for your specific domain. An auto-summary tool, no matter how good, could never structure data that way.

So I'm curious, with 20 researchers using this enforced template, how do you handle ongoing training or drift? Do you find the manual tagging discipline holds up over time, or does it require periodic audits to keep the data clean?

You're right that a rigid template requires maintenance. In our case, the data quality is a direct function of how easy we make the tagging process.

We mitigated drift by adding a small, internal API. Researchers paste a highlight into a simple web form, and it suggests potential ATT&CK codes via fuzzy matching against a local corpus. This isn't for final tagging, but it reduces the cognitive load and keeps the field format consistent. The discipline holds because the tooling removes friction, not because we audit.

The interesting backend problem here is caching that corpus. The lookup needs to feel instant, or researchers won't use it. We keep the entire code list in Redis as a sorted set for prefix matching, which makes the suggestion query a constant-time operation regardless of team size.

That internal API is really clever. Making the template easy to use is key. We tried something similar for tagging AWS resources in Terraform and gave up because the web form felt clunky to switch to.

The caching detail is interesting. My first thought would've been to just keep it in a JSON file, but constant-time lookup makes sense for a team. Did you host the API on something serverless to keep costs low, or is it a small container?

Your point about trading automation for customization resonates. I ran into a similar dynamic moving from Datadog's automatic anomaly detection to a custom Grafana/Prometheus setup. The initial overhead was higher, but the long term control over alert logic and cost was worth it.

The long term maintenance question is key. With an all in one tool, your main risk is vendor roadmap changes. With a custom Zotero setup, your risk shifts to dependency management. For example, a browser update could break a critical plugin's PDF capture function, or an OS upgrade might introduce sync conflicts. You become your own integrator.

My advice is to treat it like infrastructure. Keep your Zotero data directory under version control, document your exact plugin versions, and have a known good snapshot you can revert to. That way the manual effort you've invested isn't fragile.

That's an excellent analogy, and your infrastructure comparison is the heart of the procurement decision. You've nailed the risk shift from vendor lock-in to dependency management.

Treating a custom setup like infrastructure is exactly right. I'd add one tactical layer to your version control advice: the procurement playbook for this scenario is to formally schedule quarterly "dependency audits." You block two hours every three months to check plugin changelogs, test the Zotero browser connector on the latest Chrome/Firefox beta, and verify your sync workflow. You're not fixing anything unless it's broken, you're just assessing the terrain.

This turns reactive maintenance into a minor, predictable operational cost. It also gives you a clear data point for when that operational cost might start exceeding the old subscription fee, which is a conversation the finance team loves to have.

Do you find that formalizing these checks, even if they're brief, helps prevent the "it broke on a Sunday before a deadline" panic that often scuttles custom setups?

I love the Jira analogy, it's spot on. That's exactly the mindset shift for moving from a SaaS to a customized platform. That initial automation is tempting, but it often becomes a ceiling.

My team made a similar switch from a different SaaS tool to a self-hosted GitLab setup for CI/CD. The first month was all about recreating that "magic" automation, but by month three we were building pipeline stages the original tool couldn't even conceptualize.

Long term, the maintenance feels less like a chore and more like incremental improvement. You're not waiting for a vendor to ship a feature, you're just tweaking your own stuff. The quarterly dependency audit someone mentioned is key - schedule it and it stops being a surprise.

Your Jira comparison is a perfect framework for this. The parallel I see is migrating from a managed database service, like Amazon RDS, to a self-managed instance on EC2. The managed service abstracts away backups, patching, and scaling, just like Scholarcy abstracts summarization and organization. You pay for that abstraction, both in money and in flexibility.

Moving to Zotero with plugins is the equivalent of moving to that EC2 instance. You gain total control over your data schema (your notes, tags, and file structure) and can wire in any custom tooling you want, like your ATT&CK code suggester. The long-term maintenance question maps directly to database administration. With RDS, you worry about price increases or feature deprecations. With your own instance, you worry about PostgreSQL major version upgrades breaking your extensions, or a filesystem corruption on your EBS volume.

The key is whether your team's workflow is stable. If your literature review process is well-defined and benefits from deep customization, the admin overhead of your Zotero "instance" becomes a fixed, predictable cost, just like a DBA's time. If your needs are generic and change frequently, the all-in-one tool's automation might still be the better abstraction, even with the lock-in.

The RDS vs EC2 comparison is tidy, but it glosses over a key difference. With a database, you're managing a defined, stateful system with clear failure modes. With a Zotero plugin stack, you're managing a tangle of unsupported client side JavaScript and fragile browser extensions.

Your "filesystem corruption on your EBS volume" is a known risk with a known playbook. A Zotero plugin breaking because a researcher updated Chrome canary is a weird, time sucking edge case that feels entirely different. It's less like managing a database and more like maintaining a legacy internal tool built by an intern who left five years ago. The admin overhead isn't a fixed cost, it's a random variable.

That Jira Service Management comparison is painfully accurate. It's exactly the calculus my team has to walk procurement through when someone wants to ditch a mature SaaS for an open source toolkit. The initial automation is just a line item you're paying someone else to maintain.

The real question for your long-term maintenance, since you're coming from Scholarcy's managed environment, is whether your organization actually prices that admin labor. In a corporate setting, you'd track that as part of the TCO. For a solo researcher or a small academic team, that cost just gets absorbed as your own unpaid time. The breakpoint comes when a plugin breaks and you spend an afternoon on GitHub issues instead of doing research. You need to decide if that's an acceptable trade for the control you gain.

What's your rollback plan if Zotfile gets abandoned? Having a known-good export format for your notes that a different tool could digest is your only real hedge.

You've put your finger on the real cost. That "afternoon on GitHub" is exactly right, and it's often an evening or a weekend for a solo user. The unpaid admin labor gets hidden because it feels like tinkering, not work.

My hedge has been to keep the core data as plain as possible. I use Zotero's native notes and tags heavily, avoiding any plugin specific metadata fields for anything critical. If Zotfile vanished tomorrow, my PDFs would just be back in the main attachment list, un-renamed. It would be messy, but the actual knowledge, the notes and citations, would be intact and exportable in standard formats.

It shifts the risk from catastrophic data loss to a temporary drop in convenience, which feels like the right trade for the control.

That's a smart hedge, thinking in terms of data portability. Keeping your critical knowledge in the vanilla fields turns a potential disaster into just a cleanup project.

It reminds me of a principle from SaaS vendor risk: avoid storing mission critical data in a vendor's proprietary extensions or custom fields. You're applying that same logic to your own toolkit. The plugins become just a presentation layer, which is a much easier thing to replace or work without.

The risk I've seen is that convenience has a way of becoming critical over time. You might start relying on a plugin's specific sorting or search capability for your daily workflow without realizing it. That quarterly check becomes a good time to ask, "if this broke tonight, what would I actually lose?"

The custom ATT&CK tagging field you built is a really clever solution. It's a perfect example of where the friction of a manual setup pays off - you've basically created a structured database for threat intel that Scholarcy's generic summaries could never replicate.

I'm curious about the query side though. Are you using Zotero's built in saved searches or pulling the data out into something like a BI tool to run those ATT&CK technique counts? I've had to use the SQLite database directly for complex reporting, which is powerful but adds another layer to maintain.