Rebuilding projects and folders on the other side

Whatever your old assistant called the organisational layer — projects, folders, spaces, custom assistants configured for one job — none of it has a portable format. The content inside is recoverable; the structure is not.

That sounds like a loss and is mostly an opportunity, because you almost certainly built more containers than you used.

Write down the structure before you lose access to it

The first step is a list, made while the old account is still open, because the structure is exactly the kind of thing an export does not contain.

For each container, three facts: its name, what it was for, and any standing instructions attached to it. That last one is the valuable part — a project-level instruction is a custom instruction with a narrower scope, it is pure text, and it disappears with the container.

Ten minutes with a text file now saves an afternoon of trying to remember later. There is no mechanism that reconstructs this.

Then mark which ones you used this month

Go through the list and mark each container with when you last opened it.

The result is predictable and worth seeing anyway: a few live containers, several that were live for a specific piece of work that ended, and a handful created with intent and abandoned within a week.

Only the first group gets rebuilt. The second group’s content is in the archive if you need it; its container has no further job. The third group was aspiration and rebuilding it recreates the same clutter on a clean account.

Rebuild from purpose, not from the old shape

For each live container, ask what it was actually doing. There are usually only three answers.

Holding a standing instruction — everything in this project should be written a particular way, or assume a particular audience. That is text, it moves, and it belongs in your instruction file as a named variant rather than only in the product.

Holding reference material — the project existed so a set of documents was always attached. Those documents belong in your own reference folder, and the container is a convenience wrapper around them.

Holding related conversations together — pure organisation, no configuration. This is the one that genuinely is just a folder, and it rebuilds itself as you work.

Once each container is sorted into one of those, rebuilding is mechanical, and the parts that matter are already files you own.

Match the new product’s shape rather than fighting it

The new assistant’s organisational features will not map one-to-one, and reproducing the old hierarchy inside a system designed differently produces something worse than either.

The practical approach: rebuild the purposes, using whatever the new product offers, and accept that the layout differs. If it has no equivalent for a container you relied on, the fallback is the instruction file plus a naming convention in conversation titles, which is less convenient and completely sufficient.

Whether an equivalent exists at all is worth checking directly in the new product rather than assuming either way — the categories exist widely, and their shapes differ.

Do it during the parallel period

Rebuild containers as you need them, not all at once on day one.

The parallel period is the right window because need is a better filter than memory. A container you have not recreated after three weeks of real work is a container you did not need, and you have just learned that for free.

The exception is anything with a standing instruction attached. Those get rebuilt immediately, because their absence shows up as output that is subtly wrong rather than as a missing folder.

What moves

WHAT MOVES — the organisational layer

  · Conversations that were inside projects
                    → export as text like any other.
                      Grouping does not come with them.

  · Project-level standing instructions
                    → move as text, if you wrote them
                      down before losing access.

  · Reference documents attached to a
    project
                    → move, from your own folder rather
                      than from the account.

  · The containers themselves — names,
    nesting, sharing, ordering
                    → STAYS BEHIND. No export format
                      exists for structure.

  · Containers you built and never used
                    → STAYS BEHIND deliberately. Do not
                      recreate them.

  · Deleting a project in the old account
                    → IRREVERSIBLE, and it takes its
                      instructions with it. List them
                      first.

The team case is different

If the containers are shared with colleagues, the structure is not only yours and rebuilding it is a coordination problem rather than a personal one. Names people navigate by, links in documents, and assumptions about where things live all have other people attached.

That has its own sequence, and the short version is that the shared structure gets rebuilt and announced before anyone loses access to the old one, not after.

What is actually lost

Two things, and neither is recoverable by planning.

The grouping of your history. Conversations that lived together in a project export as individual conversations, and which project a given conversation belonged to survives only if the title says so. For old work this is mildly annoying and rarely matters.

And the accumulated fit — the way a long-running project had drifted into working exactly how you wanted through months of small adjustments you no longer remember making. A rebuilt container from a written list gets the instructions you wrote down. It does not get the ones you never noticed you were relying on, and you find those one at a time, by missing them.