Your Team's Memory Starts Over Every Time You Change Tools

The search that comes back empty

You go looking for something you know happened. The decision about how refunds work past ninety days, or the reason the enterprise tier does not include the audit log, or whatever the equivalent is at your company. You remember the conversation. You remember roughly who was in it and roughly when. You type a few words into the search box and get nothing back, and then you remember why.

That thread was in the old tool. The team moved in March.

Nothing was deleted. Nobody made a mistake. The migration went well, in the sense that everyone was working in the new system within a week and the complaints were about keyboard shortcuts. The thing you are now looking for simply was not part of what came across, and you did not notice at the time, because in March you were not looking for it.

A migration is scoped by what is still open

Think about how the plan actually gets written. Somebody lists what has to work on day one. Active projects. The current quarter's documents. Open tickets and who they are assigned to. The member list. The two integrations people touch daily. Maybe the last few months of anything, if the importer makes it cheap.

That list is correct. A migration that tried to bring everything across would cost several times more, take months longer, and most of what it moved would never be opened again. Anyone who has run one knows the pressure is in the other direction, toward moving less, because every extra category is another mapping problem and another week.

So the scoping question is always some version of what do we still need, asked about things currently in flight. The answer is right about the work. It is wrong about the record, and nothing in the process surfaces that, because the record is not a line item. It has no owner, no ticket, and no day in the plan.

Here is the part that costs you. Closed items are the archive. A closed ticket is a question the team settled, and the comment thread under it is often the only place the argument lives. The document marked done is the one that contains the constraint that shaped everything after it. The finished project is where the trade was made. Anything still open is by definition unresolved, which means the part of your history with actual conclusions in it is exactly the part the plan treats as safe to leave behind.

Done and abandoned look identical from the outside

Even a team that wants to be careful runs into a real problem here. Scroll through two years of closed work and you cannot tell which items still matter. A project that finished and shaped everything afterwards and a project that was quietly dropped look the same in a list. No recent activity, status closed, last touched fourteen months ago.

The signal that separates them, whether anyone will ever need the reasoning again, is not a field in any tool. It only becomes visible later, when someone asks a question the old thread would have answered.

Jeff Rothenberg made the same observation about digital records generally, and it holds at company scale. Writing about why there are so few clear cases of important digital material being lost, he pointed out that the ones that survive are the ones somebody recognised as important "while they are still retrievable". The value of a record tends to become obvious long after the moment you would have had to act to keep it. A migration forces that judgement early, on a deadline, from a person whose actual job that week is making sure the sprint board works on Monday.

The old workspace is not deleted, it is downgraded

In most companies the old system does not get switched off. It gets quietly demoted in three steps, and each one is somebody doing their job well.

First it goes read only. This is the responsible choice, it costs almost nothing, and everyone agrees to it in about four seconds. At this point the history is genuinely fine. You can still open it, and once in a while somebody does.

Then the seats. Six months later finance is looking at a renewal for a tool nobody works in, and cuts it to a handful of admin logins. Perfectly reasonable. The archive still exists and almost nobody can reach it. Looking something up has quietly become a favour you ask a colleague rather than a search you run, and most people stop bothering at that point. They do not announce that they have stopped. They just answer from memory instead.

Then the contract ends. Somebody runs the export, drops the file in a shared drive, and ticks the line in the plan that says data archived. That line is true, and it is not what anyone reading it later will assume it means.

Not one of those three is a decision about memory. Each is a defensible decision about cost, made by a person acting correctly on the information in front of them. Nobody ever writes down that the company is going to forget this. Which is worth sitting with, because this is not a habit that faded out on its own. A migration has a date, an owner, a project plan and a launch announcement. It is one of the most documented events a company runs, and the thing it costs you is the one thing it never writes down.

An export keeps the words and throws away the machine

The export is where most teams think they are covered, so it is worth being precise about what is in it.

The text is there. What is not there is the search index, the links between one item and another, the threading that told you which reply answered which question, the status changes and who made them, and the permissions that decided who could open what. What you get is four thousand markdown files in nested folders, or a JSON dump of every message in every channel, or a CSV where the comment bodies are one very long column.

That is complete in the sense that matters to a lawyer and useless in the sense that matters on a Tuesday afternoon. Nobody greps a folder of JSON to settle a question about refund policy. They ask the person who has been there longest, and if that person has left, the question just gets answered again from scratch.

This is a different failure from the one where a record is live and searchable and you still cannot find it because you called it an outage and the note called it an incident. In that case the system is running and your words and its words do not line up. Here the words are exactly as they were. The thing that made them reachable no longer runs. Rothenberg's distinction is the useful one: getting the content out and being able to interpret it are two separate problems, and the second one is what actually bites.

Compliance retention and operational retrieval are not the same job, and an export satisfies the first while looking like it satisfies the second. That resemblance is the whole trap. A folder that nobody can use still reads as a folder that has everything in it, so the question never gets raised again.

Every link across the boundary is already broken

There is a second loss that lands later and quieter. Every document in the new system that says see the discussion here, with a URL pointing into the old one. Every onboarding page linking to a thread. Every ticket referencing the ticket that superseded it. Nobody checks these, because a link looks identical whether or not it resolves.

It is worth knowing how fast this happens in a setting where people are actively working against it. Pew Research Center sampled webpages from the Common Crawl archive and found that 38% of pages that existed in 2013 were no longer accessible as of October 2023, and that in most cases the site itself was fine and the individual page had been removed. In the same study, 23% of news pages and 21% of government pages carried at least one broken link.

The public web has the Internet Archive and a community of people whose actual job is keeping copies. Your old workspace has neither. When the tenant is deleted there is no second copy to fall back on, so the link that used to point at the reasoning now points at a login page for a product your company does not pay for. The decay rate on an internal system is not better than the public web. It is considerably worse, and it happens all at once on a scheduled date rather than gradually.

That matters most for the documents you were proudest of. A well written internal page is dense with references, because the author was being careful and pointing at evidence rather than asserting things. After a migration that page is the one with the most dead ends in it.

The floor moves every few years and nobody feels it

Most companies do this more than once. The tracker changes. Then chat. Then the doc system, usually because the doc system was never really chosen in the first place. Then the CRM, when sales gets its own leadership. Each change cuts a different slice of history at a different date, so what you end up with is not one clean boundary but several overlapping ones.

Nobody experiences this as loss, and that is the strange part. The current tool is always full. It has everything anyone has done recently, it is fast, and it looks like a complete picture of the company. The floor under it moves up every few years and there is no line on the screen showing where it is.

The person who joined after the last migration cannot see past it and does not know there is a past. They do not experience a gap, because a gap needs two edges and they can only see one. They experience the company as having started around when they did. When they propose something that was settled three years ago, they are not being careless. They are working from the only record they have been given.

And the team most likely to migrate is the one growing fastest, outgrowing the tool it picked when it was eight people. Which is the same team accumulating decisions fastest, and the same team whose memory is most concentrated in the heads of people who are about to be outnumbered by new hires.

What actually has to survive a tool change

There is a clean test for this. A record worth carrying across a migration is one that is not shaped like the tool that happened to hold it.

A ticket is shaped like a tracker. A thread is shaped like a chat app. A page with a comment sidebar is shaped like whichever doc tool you bought. All of those shapes are the reason importers exist and the reason importers are always partial, because the next vendor's object model is different and something has to be dropped in the mapping.

A decision is not shaped like anything. Neither is the reason behind it, the condition that would change it, the commitment somebody made, or the thing it replaced. Those are plain facts about the work that could be written on paper. No tool exports them as a category, because no tool stores them as one. They are scattered through comment fields and message histories as a side effect of the work happening, which is precisely why they are the first thing a migration loses and the last thing anyone thinks to ask about.

So the small set worth holding somewhere that is not your tracker: what was decided and roughly when, the reason in the words people used at the time, the condition that would make the team revisit it, who committed to what, and what the decision replaced or ruled out. That is five short lines per decision. It is not a knowledge base project.

The obvious objection is that this sounds like maintaining a parallel wiki, and a parallel wiki is a thing every team has tried and abandoned. That objection is correct about wikis. Anything that asks a person to type the same conclusion into a second place, after the work is already done and the meeting is already over, loses to the next deadline, every time, at every company, regardless of discipline. The version that works is capture that forms from the work itself, held somewhere whose job is memory rather than execution. Then changing your tracker is changing your tracker, and not changing your history.

Where Driffle fits

This is the problem Driffle is built around. It sits alongside the tools rather than inside one of them, captures meetings and work context without a bot joining the call, and keeps decisions, commitments and follow-ups as work memory you can ask plain questions against later. What was decided about refunds past ninety days, who owns the billing migration now, what was the condition on the October date.

Because that record is not stored as tickets or threads, it does not have a vendor boundary running through it. Switching trackers changes where the work happens. It does not change where the reasoning lives.

Two honest limits. It helps for what was captured while it was happening, so it is a forward looking fix rather than a rescue operation. And it does not reconstruct an archive that has already been exported to a zip file in a shared drive. If that is your situation, the useful move is not a recovery project, it is making sure the next boundary does not land in the same place.

The privacy question this raises

A record that survives your tools survives longer than anyone planned for, and that deserves a straight answer rather than a reassuring one.

Most work records get an accidental expiry date from the software holding them. Deprecate the tool and the material goes with it. Once memory stops being tied to a vendor, that accidental expiry is gone, and the thing that has to replace it is a deliberate one.

Which means the scope has to be tighter, not looser. Keep what was decided and why it was decided, not a running account of what everyone said all day. Keep access attached to the work rather than to a general archive anyone can browse. Keep deletion real and reachable, so that a person can have something removed and it is actually removed rather than surviving in an index. A memory designed to outlive your tools has to be designed to be narrowed and cut down, or it turns into something nobody wants to have built.

A check you can run in five minutes

Name the last tool your team replaced, and roughly when the switch happened. Most people can do this quickly, because a migration is memorable.

Now pick one decision your team made before that date that you are still following today. Not a famous one. Something ordinary, a policy or a limit or a standing arrangement that is still in force.

Try to retrieve the reason for it in five minutes, using only what you have access to right now. Not your own memory of it. The record.

Whatever happens in those five minutes is the honest answer to how much of your history survived the last migration, and a fair prediction of what the next one will do. If it went badly, the fix is not a project to recover the old archive. It is making sure that the reasoning your team generates this quarter is held somewhere that does not have a renewal date attached to it.