So the team decided to "upgrade" from Jira to Shortcut, citing "velocity" and "simplicity." I was, predictably, the one asking what specific pain points we were solving, given that Jira, for all its clunk, is a known entity. The migration was pitched as a two-week affair. It took six.
The main selling point was the cleaner UI and the promise of less configuration. What they didn't mention is that Shortcut's query language, while less verbose than JQL, is also less powerful for the complex, multi-team dependencies we actually have. Trying to recreate our critical "blocked by external team, awaiting QA, high priority" filter was an exercise in frustration.
Here's the kind of "simplicity" we traded for. In Jira, a saved filter with a JQL like:
```
project = PROD AND status in ("Code Review", "QA") AND "Blocked By" is not EMPTY ORDER BY priority DESC
```
In Shortcut, you're clicking through a builder that can't quite handle the "AND NOT EMPTY" logic for a custom field without workarounds. You end up with a half-dozen saved views that no one can remember.
The workflow automation is where the real friction hit. Our Jira automations, while built on spaghetti, moved tickets through review cycles. In Shortcut, the "rules" are simpler, which means they are also dumber. We lost the ability to have a ticket automatically move back to "In Progress" if a PR was rejected, because the rule only triggers on the "Reject" action itself, not on the state of the linked GitHub pull request. We had to write a clunky webhook handler to patch this gap.
```python
# A snippet of the "fix" we had to implement
def handle_github_pr_review(event):
if event["action"] == "submitted" and event["review"]["state"] == "CHANGES_REQUESTED":
shortcut_story_id = extract_story_id(event["pull_request"]["body"])
# Now we have to manually update Shortcut via its API
# because its native rules can't see this state.
update_shortcut_story_state(shortcut_story_id, "in progress")
```
The team buy-in evaporated during week three when engineers couldn't find their tickets. The "better" search is only better for simple keywords. Historical data migration was surface-level—comments came over, but attachment links broke, and all the subtle Jira ticket links became plain text, destroying context.
Is it better? For a greenfield team of five, maybe. For a 20-person team with years of process and history baked into Jira's crusty chassis, you're just trading one set of well-understood problems for a new set of opaque ones. The velocity boost was a myth; we spent two months just regaining parity.
prove it to me
The query language limitations are real. I ran a similar comparison for my team and found that while Shortcut's builder is fine for basic "status = open" filters, it falls apart for multi-condition logic.
JQL's explicit syntax actually becomes an advantage once you have more than five people touching a project. You can version control it, comment it, and reuse it. Shortcut's saved views just become a graveyard of forgotten clicks.
Did you hit any performance issues with large backlogs? I found their search started choking around 2,000 work items, whereas Jira's Lucene backend just kept grinding.
-- bb
Yeah, that workflow automation part is what I'm worried about. We're looking at a similar move for our small team, and our main concern is those little automations. Did you ever find a decent workaround for moving tickets through stages automatically, or did you just have to rebuild everything manually?
Your JQL example hits the nail on the head. That "AND NOT EMPTY" logic for blockers is exactly the kind of thing we need for deployment coordination. When we tested Shortcut, we had to create a separate "Blocked" label and a manual process to apply/remove it, which immediately introduced drift.
The automation gap you mentioned is critical. Jira's automation may be spaghetti, but it's programmable spaghetti. Shortcut's built-in rules feel like they're designed for linear, single-team workflows. Try replicating a rule that, after a pull request is merged, moves the ticket to "Staging QA" and tags the QA lead *only* if the "Deployment Type" field is "Standard." In Shortcut, you're looking at multiple rules and custom fields. In Jira, it's one messy but functional rule.
Commit early, deploy often, but always rollback-ready.