How to Update a Literature Review Without Starting Over

An update to a literature review is a controlled comparison, not a fresh project. You keep the original argument, freeze the search that produced it, define a defensible window for new evidence, rerun the core searches, screen only what is new, and then revise the argument where the evidence actually changed. The work stays auditable because every step leaves a record: the frozen strategy, the window dates, the rerun outputs, the screening decisions, and the reason each change entered the manuscript.

This article gives a complete sequence for that task, with diagnostic checkpoints, a worked example, a reusable checklist, and stop or escalation rules. It assumes you are updating a manuscript, a revision, a peer-review response, or a grant-related evidence summary where the prior review already exists and should be preserved.

A first review builds a search from eligibility criteria and screens everything it finds. An update inherits those decisions and asks a narrower question: what appeared since the last search, and does it change what we concluded? That framing matters because it protects the original method trail. If you rebuild the search from scratch, you lose the ability to say precisely which conclusions shifted and why.

Cochrane's guidance on searching and selecting studies supports planning searches from eligibility criteria, combining free-text terms with subject headings, using multiple sources, documenting the process, deduplicating records, screening in stages, linking multiple reports of one study, and rerunning searches before publication. Each of those practices has an update-specific counterpart: the eligibility criteria stay fixed unless you deliberately revise them, the documented process becomes the frozen baseline, and the rerun becomes a bounded, dated operation.

PRISMA 2020 reinforces the reporting side. It provides a checklist, expanded explanations, an abstract checklist, and flow-diagram templates for original and updated systematic reviews, with transparent reporting of search, selection, and synthesis methods. An update that cannot show its search dates, its selection decisions, and its synthesis changes is hard to report against that standard.

Start by reconstructing the exact search that produced the current review. Capture, for each database or source you used:

• the full query string, including free-text terms and subject headings;
• any filters (date, language, publication type, species, study design);
• the platform or interface used, since syntax can differ;
• the date the search was executed;
• the number of records returned and the number retained after deduplication;
• the screening decisions and the reasons for exclusion at full text.

Save this as a read-only baseline. If your original records are incomplete, reconstruct what you can and mark the gaps explicitly rather than silently filling them. A baseline with acknowledged gaps is more honest than a reconstructed search presented as the original.

Checkpoint: Can a colleague rerun your frozen search and reach the same record count? If not, resolve the discrepancy before proceeding. An update built on an unreproducible baseline cannot support claims about what changed.

Your update window is the interval between the last search date of the original review and the date of your rerun. Write both dates down, including the time of day if your sources index continuously. Then decide how to handle the boundary: records published just before the original search date but indexed afterward can appear as new when they are not.

A defensible window has three properties:

1. It is dated, not described. "Searches updated through 14 March" is auditable; "recently updated" is not.
2. It is applied consistently. The same window applies to every source in the core set.
3. It is reported. The window belongs in the methods section and in any flow diagram you produce.

If your original review used several sources, keep the same source set for the update unless you have a stated reason to add or drop one. Changing sources and changing dates at the same time makes it impossible to attribute differences to new evidence rather than to the new source.

Checkpoint: Does your window overlap the original search period? If it does, you will re-screen records you already handled. Either tighten the window or plan to reconcile the overlap against your original included set.

Rerun the frozen strategy first, with only the date filter adjusted to the update window. This is the core search, and its purpose is comparability. Record the raw output for each source before you do anything else with it.

Only after the unchanged rerun should you consider a supplementary search: new terminology that emerged in the field, a newly relevant subject heading, or a source you have a documented reason to add. Keep supplementary results separate from the core rerun so a reader can see which records came from which operation.

When you need to locate papers through a scholarly search interface, WisPaper search provides a place to run academic paper searches, and the WisPaper Scholar Search page is a public entry point for finding academic papers. Use whichever fits your workflow, and export or record results so the rerun stays reproducible.

Checkpoint: Compare the raw count from each source against what you would expect for the window length. A count of zero across all sources usually signals a date-filter error or a syntax problem, not an absence of new research. Investigate before concluding anything.

The efficiency of an update comes from screening discipline. Deduplicate the rerun output against your original included and excluded records, then screen in stages as Cochrane describes: title and abstract first, full text second. Because you are screening only new records, the volume should be manageable, and each decision should be recorded with a reason.

Two screening traps deserve attention:

• Multiple reports of one study. A follow-up analysis, a secondary outcome paper, or a conference abstract may describe a study you already included. Cochrane's guidance on linking multiple reports of one study applies directly: link them rather than counting them as independent evidence.
• Preprints and ahead-of-print versions. These may later appear as peer-reviewed articles. Record the version you screened and revisit it if the published version differs.

If you keep a working library of papers for the update, My Library lets you save or upload papers and organize them in one place, which helps keep the new records distinct from the original set. For questions grounded in the papers you have collected, Library QA supports asking questions based on papers uploaded to My Library or added from search results.

Checkpoint: Does every newly included record have a recorded reason for inclusion and a link to the section of your argument it might affect? If not, finish that mapping before synthesis.

Extraction for an update is comparative. For each newly included study, record the same fields you used originally, then add a column for its bearing on your existing conclusions: supports, extends, qualifies, or contradicts.

This is where many updates go wrong. A new study that contradicts one sentence of your discussion does not require rewriting the review. A new study that undermines a pooled estimate or a central claim does. Sort the new evidence by what it touches:

• Background and framing: usually a light touch; add or adjust a citation.
• Inclusion criteria or scope: potentially structural; a new population or design may mean your eligibility criteria need restating.
• Synthesis and conclusions: the highest-stakes category; changes here need explicit justification in the text.

Checkpoint: For each conclusion in the original review, can you state whether the new evidence leaves it unchanged, narrows it, or overturns it? Conclusions you cannot classify need more reading, not more writing.

Suppose a team published a review of a screening intervention with searches run through June of one year. A journal invites a revision, and the team must show whether evidence published since then changes the conclusions.

Freeze. The team retrieves the original query strings for two databases, the date filters, the deduplication counts, and the full-text exclusion reasons. One database's original query was saved only as a screenshot; the team reconstructs the string, tests it, and notes the reconstruction in the method record.

Window. The update window runs from the day after the original search date to the rerun date. The team writes both dates into the methods section and applies them to both databases.

Rerun. The unchanged strategies return a set of records, most of which are irrelevant to the intervention. A supplementary search adds one new term that became common after the original review. Supplementary records are tagged separately.

Screen. After deduplication against the original set, the team screens titles and abstracts, then full texts. Two new reports turn out to be secondary analyses of a study already included; they are linked to the original study rather than counted as new evidence. One preprint is set aside pending peer review and flagged for a final check before submission.

Compare. Of the genuinely new studies, one extends the original finding to a subgroup the review had flagged as uncertain, and one reports a null result in a setting the review had not covered. The team narrows one conclusion, adds a sentence about the null result, and leaves the main estimate unchanged.

Report. The methods section states the original search date, the update window, the sources rerun, the supplementary search and its rationale, and the screening approach. The flow diagram distinguishes records from the original search from records from the update.

Checkpoint reached: every changed sentence traces to a specific new record, and every unchanged conclusion has been checked against the new evidence rather than assumed.

Revise surgically. For each affected passage, make the smallest change that accurately reflects the new evidence, and keep a change log that maps manuscript location to the record that prompted the edit. Where a conclusion now holds only for a narrower population or setting, say so in the text rather than deleting the conclusion.

When new evidence conflicts with the original synthesis, present the conflict rather than resolving it silently. A review that reports a null result alongside a positive one is more useful than one that omits the inconvenient study. If the conflict is substantial enough to change your eligibility criteria or your synthesis method, treat that as a scope decision and document it as such.

For longer update tasks that involve assembling and reviewing a body of literature, Scholar Agent is the WisPaper area for literature review, inspiration, or reproduction use cases. If the update is part of a larger effort with multiple documents and stages, Research Projects is where you can create and manage a project in WisPaper.

Checkpoint: Read the revised discussion on its own. Does it still make a coherent argument, or does it now read as a list of new citations appended to old text? If the latter, revise for argument, not for coverage.

An auditable update leaves a trail a reviewer could follow without asking you questions. At minimum, keep:

• the frozen baseline, stored read-only;
• the update window and the rule for handling boundary records;
• raw rerun outputs per source, with supplementary searches separated;
• the deduplication log and staged screening decisions with reasons;
• the extraction table with its bearing-on-conclusions column;
• the change log linking manuscript edits to records;
• the updated flow diagram and methods text.

NIH guidance on scientific rigor and reproducibility treats careful assessment of prior knowledge, strengths, weaknesses, knowledge gaps, transparent methods, validation, and reproducibility as core parts of rigorous practice. An update that documents its window, its rerun, and its decisions is applying that principle to the review itself.

If your reference list grew during the update, check the new entries before submission. TrueCite checks BibTeX against real academic databases to flag hallucinated references, which is useful when citations were added quickly during revision.

Clear rules prevent an update from expanding indefinitely or from being declared finished too early.

Stop when:

• the core rerun is complete across all original sources and the window is fully covered;
• every new record has a screening decision with a reason;
• every conclusion has been classified as unchanged, narrowed, or overturned;
• every manuscript change traces to a record in the change log;
• the methods text and flow diagram reflect the update accurately.

Escalate when:

• the frozen baseline cannot be reconstructed well enough to support the original conclusions;
• a central conclusion is contradicted by new evidence and the team cannot agree on how to present it;
• the volume of new evidence suggests the field has moved enough that the eligibility criteria themselves need revision;
• a preprint or ahead-of-print record is central to a changed conclusion and its publication status is unresolved at submission;
• the update window cannot be closed because sources are still indexing records from within it.

Escalation means a deliberate decision by the team, recorded in the method trail, not a silent expansion of scope.