skip to content

When a case library is exported from one case-management product so it can be loaded into another, what happens to the files attached to its cases?

level: juniorimportance: should knowfreq 45%

answer

  1. bytes or a pointer, nothing else
  2. a pointer outlives nothing
  3. check inside the export archive
  4. verify by downloading from the target

basics

~20 s

Attachments come out in one of two shapes: the actual bytes bundled beside the data, or links back into the source instance. Links stop resolving once that instance is retired or the credential expires, so the export must carry bytes.

solid answer

~50 s

There are only two possibilities and they behave completely differently. An export can bundle the **bytes** — an archive containing the files plus a manifest tying each one to a case — or it can emit **references** into the source product, which is cheaper to produce and looks identical in a spreadsheet. References work right up until the source instance is switched off or the credential behind them expires, and then every attachment is gone with no error anywhere. Before scheduling the shutdown, open the export archive and confirm real files are inside it. If it only carries references, dereference them yourself during the migration run, store the bytes, and re-upload them during import. Then verify from the target: open imported cases and download the files, rather than assuming a clean import means the evidence came too.

go deeper

for a junior

Be able to say that an export either contains the files themselves or just pointers back to the old product, and that pointers become worthless once that product is retired.

for a middle

Explain how to tell the two apart and how to close the gap: dereference the pointers while the source is alive, store the bytes, re-upload on import, then verify by downloading from the new product.

for a senior

Talk about the quiet drops — size ceilings, rejected types, images embedded in rich text, evidence attached to runs rather than definitions — and about verifying before the retirement date is fixed.

for a principal

Decide what attachment fidelity is actually worth here, since carrying every historical file is expensive, and make the retention answer explicit before anyone schedules the shutdown of the old instance.

## The two shapes an export can take Attachments are the part of a case library that is not text, and an export has to decide what to do about that. There are two answers. - **Bundled bytes.** The export is an archive: the case data plus the actual files, with a manifest that says which file belongs to which case and which step. Bigger, slower, and self-contained — it still means something after the source product is gone. - **References.** The export carries a pointer back into the source instance for each file. Fast to produce, small, and readable, because the row shows a plausible-looking location and everything appears present. From a spreadsheet the two look the same. That is precisely why this bites teams. ## Why a reference-shaped export is a trap A reference is only as durable as the thing it points into, and every part of that is on its way out: - The **source instance is being retired** — that is the whole point of the migration. Once it is gone the reference resolves to nothing. - The **credential** that made the reference readable is often short-lived or scoped to the export, so it can stop working long before the instance does. - **Nothing raises an error.** The import succeeds, the case count matches, and the failure is only visible when a person opens a case months later looking for the screenshot that proved a defect. The timing is the cruel part. Reference rot is discovered *after* the source is switched off, which is exactly when nothing can be done about it. ## Getting the bytes across 1. **Inspect the export before you trust it.** Open the archive. Are there real files inside, of plausible sizes, or only data rows containing locations? 2. **If it is references, dereference them during the run.** While the source is still alive and the credential still works, fetch each file and store it somewhere durable alongside a mapping from file to case. 3. **Re-upload during import.** Attach the stored bytes to the corresponding case in the target, using the source key parked on the imported case to find the right one. 4. **Verify from the target, not the source.** Open a sample of imported cases in the new product and actually download the files. Confirming they are still listed in the old product proves nothing about the new one. ## What still gets dropped quietly - **Files hanging off an execution rather than off the definition.** Evidence captured during a run belongs to the run. If runs are not being migrated, that evidence is not either — plan for it separately rather than discovering it. - **Per-file size ceilings on the target.** Products cap how large a single attachment may be, and an import that meets a ceiling usually skips the file and continues rather than failing loudly. - **File types the target refuses.** Archives and executables are commonly rejected, so exactly the bulky diagnostic bundles that were worth keeping are the ones that vanish. - **Images embedded inside rich text.** A picture pasted into a description is often not an attachment at all; it lives inside the formatted text and disappears when that text is flattened to plain characters on import. - **Ordering and captions.** Even when files arrive, the note explaining what a screenshot showed may not, leaving evidence that nobody can interpret. The short version: an attachment survives a move only if the bytes moved. Check that before the old instance is switched off, because afterwards the question is unanswerable.

  • The archive does contain files. How would you check that all of them made it?
    Compare the file inventory in the archive against what the target actually holds after import, then open a sample and download them. Pay attention to the largest files and to unusual types — those are the ones a size ceiling or a type restriction silently skips while the import reports success.
  • Screenshots captured during past runs matter to the team. Does migrating the case library bring them?
    No. Evidence captured during execution belongs to the run, not to the definition, so a definition-only migration leaves it behind entirely. If it matters, it needs its own decision — carried across, kept readable in the retired instance for a window, or exported to durable files — made before the shutdown date is set.

saying these in an interview costs you the question

  • Assumes every export bundles the actual attachment bytes
  • Verifies attachments in the source instead of the target
  • Believes a clean import means files came across
  • Ignores that some files fail a target size ceiling
  • Treats pasted images in rich text as attachments