When Sara’s cooperative opened its shared archive, everything looked like an obvious improvement. Minutes no longer travelled as attachments, estimates appeared from any phone, and every project had a clean space. Two years later, the cooperative wanted to change services because an affordable plan had become a difficult fee to sustain. They discovered that the question was not merely how many gigabytes they could download. There were links embedded in one hundred and twenty documents, permissions for former collaborators, notes inside a mobile app, and a calendar that the new service did not interpret in the same way. The price of leaving was distributed among small tasks no one had needed to see when joining.
That is one of the invoices for digital convenience: it does not necessarily arrive as a visible line on a card statement. It may arrive as a lost afternoon of work, a decision postponed because nobody knows what a migration will break, or a dependency that prevents a group from negotiating an unfair term. Talking about the data economy means looking at these exit costs. Not to reject every convenient service, but to regain the capacity to choose when circumstances change.
Joining is often an experience; leaving is an operation#
Digital services compete to make onboarding light. A registration with an email address, an automatic import, and a friendly screen turn a tool into part of ordinary life. It makes sense to value that effort: it lowers barriers and lets small groups do things once reserved for organizations with more resources. The problem begins when the initial ease hides the fact that leaving will require knowledge, time, coordination, and sometimes extra payments.
Digital services compete to make onboarding light. A registration with an email address, an automatic import, and a friendly screen turn a tool into part of ordinary life.
It is not enough that a button labelled “export” exists. We need to ask what that button produces. Does it download files with their names and dates? Does it retain comments, versions, permissions, and relationships between items? Can the result be opened without the same program? How long does it take at scale? Who can run the export if the administrator account is lost? A portability promise that ends in an incomprehensible folder does not offer real freedom; it transfers the work of organizing from the provider to the user.
The difference is clear in a small case. A photographer may store images in a service and retrieve the original files. But her albums, client selections, editing notes, and delivery links may remain behind. For her, those are not decorations: they are part of the work that gives photographs context and value. Counting only file size is like measuring a library by the weight of its paper while ignoring the catalogue.
Make the dependency inventory visible#
A responsible exit begins with a simple inventory. The aim is not an endless technical document, but knowing what has been entrusted to each tool and what depends on it. Sara’s cooperative wrote down five columns: stored information, people with access, tasks that use it, connections to other applications, and a way to recover a copy. The exercise showed something important: the documents were movable, but the forms feeding a spreadsheet and the automated notifications were the most fragile pieces.
That inventory helps distinguish reversible convenience from deep dependency. Using a platform for a one-off video call is not the same as placing a contract archive, team authentication, and client relationships there. The more central a tool is, the more reasonable it is to require open formats, complete exports, shared administration, and a continuity plan. This is not paranoid suspicion; it is the same prudence with which an organization keeps emergency contacts or copies of its keys.
It also helps to identify data that do not belong only to the purchaser. An account may contain information about workshop participants, families, patients, or suppliers. If the cost of leaving causes a group to retain a service that no longer meets its privacy needs, those other people become trapped in a decision they did not make. Data autonomy has a collective dimension: changing providers may be necessary precisely to care for people who entrusted information to a group.
Rehearse an exit before it is needed#
The best way to learn whether a migration is viable is to run a small test when there is no crisis. Once a year, an organization can export a representative sample: a project containing documents, permissions, images, a calendar, and a relevant conversation. It can then try to open it with different tools, check that necessary metadata appear, and estimate how much manual work remains. The result should not be a provider compliance test; it should be learning about the group’s own dependency.
This rehearsal often reveals details a sales page does not explain. Creation dates may change on download. A shared link may stop working. Tags may export while filters do not. Someone may need an audit file the basic plan does not include. Each finding can become a specific choice: maintain an encrypted local copy, use clearer file names, document an automation, or avoid a particular module for sensitive information.
Rehearsing does not mean that a service must be abandoned every year. It means that deciding to stay remains a decision. When a community knows what to preserve and who will do it, it can assess a price rise, corporate acquisition, or terms change with less fear. The capacity to leave also changes the conversation while staying: it makes it possible to request improvements without feeling that every disagreement threatens the entire archive.
Count work that does not appear on the invoice#
Price comparisons usually add a monthly fee, storage, and perhaps transfer costs. They leave out hours for cleaning, training, and checking. They also leave out the emotional cost of asking clients or families to create another password, accept a notification, or learn a different interface. These costs should not become an excuse never to change; they should be recognized so that the decision is fair and the burden can be shared.
A well-planned migration reserves paid time, explains why it is happening, and offers help to people who will encounter barriers. If an association chooses a more privacy-respecting system, it should not turn the transition into night work for the one person who understands technology. It can assign small responsibilities, prepare guides in plain language, and keep a support route during the first weeks. An economic saving loses meaning if it is obtained by transferring all effort to the person with the least power to refuse it.
There is also an opportunity cost. Remaining in a tool by inertia can prevent better practices: more limited permissions, shorter retention, formats other organizations can read, or distributed administration. Change sometimes costs, but continuing to pay for a limitation costs as well. Seeing both sides helps us leave behind the false choice between immediate convenience and heroic sacrifice.
Negotiate from an informed position#
Many people cannot freely choose a provider; the service is imposed by a school, employer, or public institution. Even so, transparency about leaving matters. Someone contracting for a group can ask what exports, where copies are stored, what happens when an account closes, and what assistance is offered in a transition. These questions are not a specialist detail. They concern continuity, privacy, and the ability not to accept worse terms because there is no alternative.
For significant purchases, a contract can ask for a trial export, access periods after cancellation, interface documentation, and clear limits on extraction fees. It can also require data to be separated from other customers’ data and deleted verifiably when the relationship ends. Not every organization will have the leverage to obtain every term, but stating them makes portability visible as part of the service, not a favor granted at the end.
Justice appears here as an issue of asymmetry. A large company can switch systems with a dedicated team; a small library, family, or cooperative cannot. If exit mechanisms are workable only for those who can pay consultants, initial convenience becomes an entry door to unequal dependency. Designing simple recovery options particularly benefits people with less room to maneuver.
Decide what should not be centralized#
The answer is not always finding an identical replacement. Sometimes the inventory shows that too much has been concentrated in one account: archive, communication, calendar, identity, and payments. Separating some functions may increase the number of tools while reducing the damage from an outage or an abusive term. The task is to find a distribution that remains understandable to the team and does not turn security into a collection of impossible passwords.
A useful criterion is to separate copying, coordination, and identity. Document copies can have a backup replica; task coordination can allow a weekly export; identity needs especially careful controls because losing it closes the door to everything else. Having two administrators, storing recovery codes under a clear agreement, and reviewing access when someone leaves are modest actions that reduce the power of one platform and one person.
Sara’s cooperative did not need a perfect migration to make progress. It set a monthly copy of closed projects, documented the forms it would have to rebuild, and decided that new proposals would not depend on private links that were difficult to recover. When it renegotiated its plan, it knew exactly what it could move in a week and what would need more care. That clarity turned a diffuse threat into a concrete conversation.
Exit as part of continuing care#
Planning an exit does not express disloyalty to a tool or contempt for those who build it. It recognizes that businesses, needs, and lives change. The tool that enables collaboration today may close tomorrow, raise its price, be acquired, or cease to respect an important boundary. Preparing for that protects memories, work, and relationships.
The next step can be small: choose one central tool, make a one-page inventory, and export a test project. When reviewing it, do not look only for files that arrived. Look for context that disappeared, people who depend on a permission, and tasks nobody knew were automated. Then choose one achievable improvement for the next three months.
When convenience becomes an invoice, the answer is not to live without digital services. It is to refuse to let exit be a surprise. With understandable copies, shared responsibilities, and calm rehearsals, data become a tool in people’s service again instead of an account they can afford only by staying.
