How to track a feature request across a renamed or split Jira epic
The issue key is what survives. Renaming an epic changes its summary, splitting it moves child stories under a different parent, and closing it as won't-do changes its status and resolution. None of those three actions touch the key. OAK-88 is OAK-88 before and after. If you wrote down the key when the request came in, you can always find the issue again, no matter what happened to it since.
What you can't do is search your way back to the key once you've lost it. Jira doesn't let you query "what was this epic called before" or "what epic did this story used to live under." Both questions come up naturally, usually when a customer asks about something they raised months ago and the epic name they remember doesn't match anything in your backlog anymore.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat Jira actually tracks, and what it doesn't
Jira's JQL has two operators built for exactly this kind of question, WAS and CHANGED, which let you search a field for a value it used to hold, not just the value it holds now. Only some fields support them, though. Per Atlassian's own JQL fields reference, Reporter explicitly lists WAS, WAS IN, WAS NOT, and CHANGED as supported operators. Summary, the field an epic's title lives in, lists all four as unsupported; you can search its current text with ~, but there's no way to query what it used to say. Parent, the field that links a story to its epic, fares no better. It supports only =, !=, IN, and NOT IN, with WAS and CHANGED explicitly listed as unsupported.
That's the asymmetry the whole problem sits on. Jira keeps a searchable history of who reported an issue, because Reporter is a people field and people fields get this treatment. It keeps no queryable history of what an epic was called or which epic a story used to sit under, because those are structural fields, and structural change is treated as normal housekeeping rather than something worth indexing. Atlassian's own description of an epic backs this up. An epic is "essentially a large user story that can be broken down into a number of smaller stories," and as a team learns more, "some user stories will be added or removed" as routine behavior, not an edge case Jira expects you to need to reconstruct later.
None of this means the information is gone. Jira's issue history panel on the epic itself still shows every summary edit and every re-parenting, in order, with a timestamp and who did it. It's just not something JQL can filter or search across your whole project. You have to already be looking at the right issue to see its own history.
What changes under each of the three events
- Rename. Only the
Summaryfield changes. The key, the description, the linked children, and the reporter all stay put. The only cost is that anyone searching by the old title, in Jira's UI search or in a saved filter, stops finding it. - Split. One or more child stories get their
Parentfield pointed at a new epic. The stories keep their own keys and their own reporters. What's lost is the epic-level framing. A theme like "eight customers asked for this" was implicit in "eight stories under one epic," and that count doesn't travel with any single story once they're spread across two or three new epics. - Closed as won't-do. Status and resolution change; the key doesn't move and doesn't disappear. The issue is still findable by key or by a JQL search on
resolution, but it drops out of any board or filter scoped to open work, which is usually where people were tracking it.
Five months, one webhook request, two epics
In March, a support engineer at Fenwick Ops flags a complaint from a warehouse customer whose integration keeps missing webhook deliveries during peak load, with nothing retrying automatically. Callum Vance, who triages the integrations backlog, files it as OAK-410 and folds it into an existing epic, OAK-88: Webhooks reliability, where two similar reports already live.
By June, OAK-88 has grown to eleven stories spanning delivery retries, signature verification, and a rate-limiting complaint that turns out to be unrelated. At a planning session, the team splits it. Retries and rate limiting become OAK-140: Webhook delivery guarantees, and signature verification stays behind under a renamed OAK-88: Webhook auth. OAK-410 gets re-parented to OAK-140.
Five months after the original complaint, someone at the same account asks their account manager for an update, still calling it "the webhook retry thing, OAK-88." Nobody on the team remembers OAK-88 is auth now. OAK-410 still exists, still points at the right work, and is one JQL search away. parent = OAK-140 finds it instantly. But that search only works if someone thinks to look under the new epic rather than trusting the old number a customer-facing teammate wrote down back in March. OAK-88 never disappeared. What went missing was the paper trail connecting a March complaint to whichever epic ended up doing the work.
The same gap opens if an epic gets closed as won't-do instead of split. The key still resolves and still turns up in a search by number, but it drops off any board scoped to open work, and the requester line goes quiet unless someone remembers to check closed issues too.
The convention that covers most of this
The fix most teams land on doesn't require new tooling. Put a fixed line in the ticket description, filled in at filing time, something like Requested by: Fenwick Ops / Callum Vance, from support thread [link], and treat it as text nobody paraphrases or drops during a rewrite. Because it lives in the description rather than in Summary or Parent, a rename or a re-parent doesn't touch it. Pair that with a habit of pinging the requester's channel with the current key whenever an epic is split or renamed, before anyone has to ask.
This holds up only if three things stay true. Everyone filing tickets follows the convention, nobody strips the line during a description cleanup, and someone remembers to do the re-notify step every time an epic gets reorganized. In a small team filing a handful of requests a week, that's realistic. Once multiple people can file issues and epics live for months before shipping, the line gets dropped under deadline pressure often enough that it stops being reliable, and the re-notify step is the first thing anyone forgets, because nothing in Jira reminds you to do it.
The discipline this depends on
That's the point several of our related guides land on too. A request tracked through a Jira epic's Reporter field and description, or typed into a ticket at filing time, is only as durable as the discipline of everyone who touches that ticket afterward. A rename or a split doesn't erase the request. It erases the thread connecting the request to whatever the current key happens to be, and that thread lived in a free-text line that any edit can quietly break.
This is the gap Modem is built to close. Modem's Jira integration watches the projects you connect and keeps every request as a topic, not a value inside a Summary or Parent field. The company and person behind a request are attached to that topic directly, so when OAK-88 gets renamed or split, the topic doesn't move with the epic's title. It moves with the actual work. Re-parented children stay linked, and the requester list stays attached to whichever epic ends up carrying the work forward. Ask "who asked for this" six months and two reorganizations later, and the answer comes from the topic, not from whichever description line survived the last edit. Modem is our product, so take that for what it's worth, but the convention above costs nothing to adopt and will get a small team most of the way there on its own.
Two habits to add now
Add one line to your ticket template, Requested by: plus the account and a link to the original thread, and make it part of how tickets get filed, not an afterthought. Then add a second habit. Whenever an epic gets renamed or split during planning, spend two minutes finding every story that used to carry a customer's name and pinging them the new key. That second habit is the one that actually gets skipped, and it's the one that would have saved Callum the August scramble.
