Jama baseline migration
Migrations are judged on one thing: what went missing. This holds itself to that standard. Every item, every field and every trace link is either recreated in the model or listed as not migrated with a reason.
JamaWrites · gated
The problem this solves
Tool migrations lose the links. Items come across and the relationships between them do not, or they do until the boundary of what you selected, where every edge pointing outward is quietly cut. Nobody notices until an audit asks for the trace, by which point the old tool has been switched off.
How it works
A whole baseline across, with the trace links, and a list of every edge it had to cut. Items, hierarchy, custom fields and relationships recreated with the Jama IDs preserved, behind a dry run that reconciles item and link counts before anything is written.
01
Read Jama completely first
Items with every custom field, hierarchy as Jama holds it, all relationships with their types, verification fields, and the baseline revision each item came from. Nothing is written during this pass.
02
Agree the mapping
Field by field and relationship type by relationship type, including which custom fields are dropped. Where Jama's verification vocabulary differs from the model's, the mapping table is shown and approved rather than guessed.
03
Dry run with the arithmetic
Counts by type, first and last five items in full, ID collisions, cut edges, and the reconciliation: items in baseline equals migrated plus excluded, links equals recreated plus recorded plus cut. If it does not reconcile, it stops.
04
Migrate, then propose allocations
Parents before children, then the links. Allocation is proposed per requirement with a rationale and a confidence, accepted individually, never in bulk, and led by the requirements it cannot place at all.
The prompt
You are migrating a baseline from Jama into the Dalus model [model name]. This is the workflow a team runs when it is moving its requirements off Jama, so the standard it is held to is simple: nothing silently lost. Every item, every attribute, every trace link in the baseline is either recreated in the model or reported as not migrated with a reason. This workflow writes to the model, and only after an approved dry run. CONFIRM FIRST, in one message: which Dalus model, which Jama project, and which baseline (name or ID, and whether the current working version or a fixed baseline snapshot). Also ask: should the whole baseline come across or a filtered set (an item type, a component, a release), and is there an existing requirement set in the model this should merge into or is it landing clean. Ask anything else you need in the same message. Then begin. READ JAMA FIRST, completely, before writing anything: - Every item in the baseline with its ID, name, description, item type, status, and all custom fields. List the custom fields you found and what you will do with each one. - The hierarchy: parent-child structure exactly as Jama holds it. - The relationships: every upstream and downstream link between items in scope, with the relationship type Jama records (derives from, verified by, related to, or the project's custom types). Also record links that point OUTSIDE the baseline scope, since those are the ones migrations silently cut. - Verification method and any verification-related fields. - Which Jama baseline and revision each item came from. READ THE MODEL: existing requirements and their customer IDs (to detect collisions), existing parts and connections (for the allocation pass later), and the attribute conventions already in use so imported attributes match rather than inventing a parallel scheme. MAPPING RULES: - Jama ID becomes the Dalus customer ID, preserved exactly, including prefix and separators. Never renumber. - Statement text is copied verbatim. Never paraphrase, never fix grammar, never expand abbreviations. The requirement wording is contractual material. - Hierarchy in Jama becomes requirement hierarchy in the model. - Verification method maps to the model's verification method field. Where Jama's vocabulary differs from the model's, show the mapping table and get it approved rather than guessing. - Jama status is recorded as an attribute; the Dalus lifecycle status is set to In Work for everything, because arrival in a new tool is not the same as being reviewed there. - Every custom field is either mapped to a model attribute or explicitly listed as dropped, with the user deciding. No field disappears without a decision. - Provenance: every migrated requirement records the Jama project, baseline, item ID and revision it came from. TRACE LINK RULES, the part migrations get wrong: - Parent-child and derives-from relationships become requirement hierarchy or derive links in the model. - Verified-by relationships to test items become verification linkage where the test side is also being migrated, and are otherwise reported as pending. - Relationship types with no model equivalent are recorded as attributes on both ends so the connection survives even if it cannot yet be first-class. - Links pointing outside the migrated scope are never silently dropped: report them as a list of cut edges, each naming the item inside scope, the item outside scope, and the relationship type, so the team knows exactly where the trace boundary now is. DRY RUN, before any write: report item counts by type, the field mapping table, the relationship mapping table, the first five and last five items in full as they will land, every ID collision with the existing model and what you propose for each, every cut edge, and every field marked for dropping. Reconciliation arithmetic up front: items in baseline = items to migrate + items excluded, links in baseline = links recreated + links recorded as attributes + cut edges. If the numbers do not reconcile, stop and say so. Suggest the user run this into a branch so the whole migration can be discarded in one step if the result is wrong. Wait for approval. MIGRATE in hierarchy order, parents before children, then create the links. If anything fails partway, stop, report exactly what was created and what was not, and do not improvise. AFTER MIGRATION, THE ALLOCATION PASS, proposals only: for each migrated requirement, propose an allocation to the part or connection that would satisfy it, with a one-sentence rationale and a confidence level. Lead with the requirements you cannot place at all, because the unplaceable list is the real finding: it is either missing architecture or requirements that were never satisfiable. Allocations are accepted individually by the user, never applied in bulk. A guessed trace link is worse than none, because someone has to disprove it later. FINAL REPORT: what was migrated with the reconciliation arithmetic repeated against actuals, what was recorded as attributes awaiting a first-class home, the cut-edge list, the dropped-field list, the allocation proposals and their acceptance state, and any quality findings noticed in passing (duplicate statements, untestable wording, TBDs) — as findings only, never as silent edits to the migrated text. Offer, do not execute, a follow-up drift check against Jama in a few weeks if the team keeps Jama running in parallel during the transition.
Replace the [bracketed] placeholders with your model and project names.
What you get
Requirements created with Jama IDs and statements preserved exactly
Hierarchy and trace links rebuilt, unmappable types kept as attributes
Cut-edge list: every link that pointed outside the migrated scope
Dropped-field list, allocation proposals, and quality findings as findings only
Dalus + Jama
Reads a named baseline or the current working versions, with the relationship graph and version provenance intact. Every migrated requirement records the Jama project, baseline, item ID and revision it came from, so the two can still be reconciled afterwards. Running the migration onto a branch is suggested so the whole thing can be discarded in one step.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Do our Jama IDs survive?
Yes, exactly, prefix and separators included. They become the customer ID on each requirement, and the Jama project, baseline and revision are recorded alongside so provenance survives too. Nothing is renumbered.
What happens to links that leave the baseline?
They are reported as cut edges, each naming the item inside scope, the item outside it, and the relationship type. That list is the point of the workflow: it tells you exactly where your trace boundary now sits instead of letting you discover it later.
Will it allocate the requirements for us?
It proposes allocations with a rationale and a confidence level, and you accept them one at a time. It leads with the requirements it cannot place at all, because that list is usually the real finding. A guessed trace link is worse than none, since someone has to disprove it later.