Opening and searching the export files

You have the archive and it is complete. Now try to find the conversation where you worked out the pricing model, sometime last spring. That is the moment most people discover an export is a pile of files rather than a searchable history.

The gap is worth closing once, deliberately, in about an hour. After that the archive is genuinely useful for the next several years.

Why the raw archive resists searching

Exports are built for portability, not for reading. They are structured for a machine to reconstruct, which means the text you want is usually wrapped in markup or data structures, split across files, and stored under names that are identifiers rather than titles.

Your operating system’s search does badly with this. It may index the files and return dozens of hits with no context, or skip them entirely because the format is not one it reads as text. Neither result tells you which conversation you wanted.

The specific formats vary by product and change between exports, so the useful skill is not knowing one layout — it is knowing what to do with whatever you got.

Look at the structure before touching it

Extract the archive and read the folder listing before deciding anything.

You are looking for three things: whether there is a single large file or many small ones, whether there is a browsable entry point meant for humans, and whether conversation titles appear anywhere as text. That tells you which of the two paths below you are on.

If a human-readable entry point exists, use it for browsing and still do the flattening below for searching. The two jobs are different: browsing wants structure, searching wants one long text file.

Flatten it into plain text

The goal is one file, or one folder of files, that is nothing but the words — no markup, no identifiers, no nesting. Plain text is the only format that every search tool on every machine will still read in ten years.

If the archive is structured data, a short script converts it: read the file, walk the conversations, and write out each one as a text file with the title and date at the top and the messages in order, speaker prefixed. If the archive is markup, a text extractor does the same job.

Name the output files so the names carry information — a date prefix and a short title beat an identifier. 2026-03-14-pricing-model.txt is findable by browsing alone; the identifier version requires opening it to know what it is.

Then searching is a solved problem

Once it is plain text, ordinary tools work: your editor’s search-across-folder, the system file search, a command-line grep. Nothing exotic and nothing to install.

Two habits make it much better. Keep a single concatenated file of everything as well as the per-conversation files — full-text search across one file is faster and gives cleaner results than across thousands. And put the date in the first line of every file, so a hit tells you when without another lookup.

Deal with attachments now, not later

If the export included uploaded files, they are probably in a folder of their own, referenced from the conversations by name or identifier.

Move them into a sibling folder and, where you can, rename them to something recognisable. If the references are identifiers, the association between a conversation and its file is the fragile part — one line in the text file naming the attachment is enough to keep it.

Where attachments were not included at all, the source documents you still have elsewhere are the real copy, and keeping a canonical set of them matters more than the archive does.

What moves

WHAT MOVES — making the archive readable

  · Conversation text
                    → flattens to plain text cleanly.
                      Searchable with ordinary tools.

  · Titles and dates
                    → survive if you put them in the
                      filename and the first line.

  · Formatting, code blocks, tables
                    → mostly survive as text. Rendering
                      STAYS BEHIND.

  · Threading, branches, edited messages
                    → STAYS BEHIND. A transcript is
                      linear; the original may not have
                      been.

  · Attachment-to-conversation links
                    → STAYS BEHIND unless you write the
                      filename into the text yourself.

  · Deleting the raw archive after
    converting
                    → IRREVERSIBLE. Keep the original
                      alongside the converted copy.

Keep the original archive

Whatever you convert, do not delete what you converted from. The conversion is lossy in ways you will not notice for months, and the original is the only thing that can be re-converted when you discover your script skipped a field.

Both live together: the raw archive as it arrived, the flattened text next to it, and the note recording what the export contained. That folder is the archive. Anything less is a step in the process.

Do this before you cancel, if you can

Not because cancellation touches your local files — it does not — but because conversion is when you find out something is missing, and a missing thing is only recoverable while the account is open.

The sequence that works: export, verify, convert, then cancel. Converting after cancellation is fine right up until it turns up a gap, at which point there is no longer anywhere to go and ask.

What you still do not have

A searchable archive is a research tool, not a migration. You can find what you said and reuse it, and that is genuinely most of the value people want from their history.

What you cannot do is hand it to a new assistant and resume. Pasting an old conversation is handover — the new assistant reads a transcript, the way it would read any document you gave it. Everything that was implicit in the original thread and never written down is not in the text, and therefore is not in the archive either, however well you index it.