Leave Your Software Without Losing Your Work

Textured painting of silver fish with coral accents swimming together through a broad opening between dark cobalt rocks toward pale turquoise water.

The Work Travels Together: a shoal moves through an open underwater passage, a painted reflection on carrying records and their relationships safely into a new setting.

A practical exit plan helps nonprofits and small organizations carry their records, relationships and daily work safely into whatever comes next.

By Arbab Naseebullah Kasi, Chief Executive Officer - CEO, Feel Worldwide Foundation Inc.

The most revealing question in a software demonstration may be the one nobody asks until years later: how would we leave?

A small organization can choose a system for sensible reasons. It is affordable, easy to learn and generous to nonprofits. Over time, it becomes the place where staff record commitments, explain decisions and remember people. The subscription pays for an application. The organization supplies years of work.

An illustrative scene, not a reported case: A community organization decides to replace its donor database. Someone clicks “Export,” downloads a spreadsheet and sees familiar names. Only during the trial import does the team discover that donation restrictions are missing, attachments still point to the old service and people who opted out of messages have arrived without that preference.

The file opened successfully. The organization has not yet proved that its work can continue safely.

That is the purpose of an exit plan: to make a future change possible without leaving essential information, responsibilities or people behind. The plan should be small enough to use and specific enough to test.

Decide what must remain possible

Begin with the work people need to do after the move. A program coordinator may need to see an outstanding referral. A finance volunteer may need to connect a receipt with a restricted gift. A director may need to understand why an earlier decision was made.

These needs are more useful than a vague requirement to “keep all the data.” They identify which records, relationships and supporting evidence must remain available, to whom and for how long.

Backup and recovery prepare an organization to restore information after loss or disruption. Data minimization helps it decide what information it should collect and keep. Portability asks whether the information it legitimately needs can remain understandable and usable outside the current service. All three matter, but a backup that only the original vendor can restore may do little to support a move elsewhere.

Give one person responsibility for the exit plan and another enough knowledge to continue it. Include the person who understands the records, whoever manages access and someone who can approve contractual decisions. In a small organization, these may be overlapping roles. The responsibilities should still be clear.

Leaving also has a cost. A system that saves substantial staff time may justify some dependence on its provider. UK government cloud guidance explicitly recognizes that tradeoff and recommends balancing the benefits of dependence against switching risks. The sensible goal is an informed choice, with the likely effort and limitations understood. UK guidance on managing technical lock-in.

Read the ending before agreeing to the beginning

The best time to ask about departure is before signing or renewing. A salesperson’s assurance that “your data belongs to you” leaves important practical questions unanswered.

Ask the provider to identify, in the applicable contract and documentation:

- Which records, attachments, histories, metadata and configuration settings can be exported, and which are excluded. - The available formats, export permissions, volume limits, processing time and any paid assistance required. - Notice periods, automatic renewal terms, early termination charges and the date access ends. - Whether a limited read-only period is available after the operational switch, at what cost and under what conditions. - How the provider will support transfer, return or deletion of information, including copies held by subcontractors. - What happens if the service closes, the account is suspended or a billing dispute interrupts access.

Keep the terms and plan-specific documentation that actually apply. A help page describing an enterprise export may be irrelevant to a discounted account. Ask for a demonstration using a small, safe sample before assuming an advertised capability meets your needs.

The legal setting also matters. The European Commission explains that the EU Data Act includes switching obligations for covered data-processing services, including cloud services. It states that switching charges, including relevant data-egress charges, will be removed from 12 January 2027. This is an EU framework, not a worldwide promise of a cost-free migration. Staff time, replacement configuration and other contractual costs still need assessment. Check the service, jurisdiction and current terms. European Commission explanation of the Data Act.

Nor should an organization assume that an individual’s privacy right solves its entire migration. The GDPR right to data portability concerns qualifying personal data provided by an individual, processed by automated means on consent or contract grounds. It is not a general entitlement to every organizational workflow or vendor feature. European Data Protection Board guidance.

Ask for information that travels with its meaning

An export format is a starting point. The important question is what the receiving system can reconstruct from it.

CSV can be useful for straightforward rows and columns. JSON or XML can represent more complex structures. Editable documents and original media may be needed alongside a readable archive. A PDF can preserve a report for people to read, but may be a poor source for importing records into another application.

Request a short data dictionary explaining field names, permitted values, identifiers, dates, time zones, currencies and blank values. Preserve the identifiers that connect related records. If one file lists supporters and another lists gifts, the receiving system needs a dependable way to connect each gift to the correct person. Matching by name alone invites confusion.

The World Wide Web Consortium’s tabular-data metadata standard addresses precisely this interpretive layer, including descriptions of data types and relationships between tables. A small organization does not need to implement the full standard to appreciate the lesson: the explanation of a dataset belongs with the dataset. W3C metadata vocabulary for tabular data.

Attachments deserve their own check. Slack’s documentation, for example, explains that its JSON export ZIP contains workspace data and links pointing back to workspace files. Export types differ. A team therefore needs to establish whether required files have actually been preserved independently, rather than assuming a link will remain useful after access changes. This is a product-specific example of a wider question to ask every supplier. Slack guide to reading data exports.

Include consent records, communication preferences, restrictions, original timestamps and necessary audit history in the discussion. Record what cannot transfer. An old workflow, dashboard or calculated field may need to be rebuilt, even when its underlying records arrive intact. Payment credentials and recurring-payment arrangements may require a provider-supported migration rather than an ordinary spreadsheet export. Keep them out of improvised file transfers.

Rehearse the move and examine the exceptions

A rehearsal should end with evidence, not the reassuring sight of a progress bar reaching its limit.

Begin with synthetic records or another appropriately protected test dataset. Include the awkward cases: a long name, a non-Latin script, a missing optional field, a refunded gift, multiple contacts in one household and a record with an attachment. Establish how the destination handles these cases before exposing real personal information to a new service.

When an authorized real-data test is appropriate, use a protected environment with restricted access and disabled outbound messages. Agree what success means before running it.

Illustrative figures, not research findings: Suppose the source contains 1,240 records within the agreed migration scope and the destination contains 1,226. Fourteen records remain unexplained. A rounded “99 percent transferred” figure can hide the fact that those fourteen might contain unresolved service commitments. The team should identify every difference, establish its cause and document the accepted resolution.

Equal counts are useful but insufficient. One missing record and one duplicate can cancel each other numerically. Compare stable identifiers, required fields, financial totals where relevant, relationships and attachment availability. Reconcile totals within the same date range and currency, and retain an exception log rather than editing discrepancies out of sight.

Then ask staff to perform real tasks. Can they find a person without guessing the spelling? Can they distinguish an active commitment from a completed one? Can they retrieve the evidence supporting a transaction? Does a person with limited access remain unable to open confidential records?

Use targeted human checks alongside systematic comparisons. A handful of successful examples cannot prove an entire migration correct. Conversely, a count that matches cannot prove that a record still means the same thing.

Record the test date, source version, export settings, importer version, checks performed, unresolved problems and person approving the result. Australia's Digital Transformation Agency includes recorded exit tests, cost planning and security continuity in its government cloud checklist. Small organizations can adapt those questions without adopting an entire government assurance framework. Australian Government exit-planning checklist.

Move authority as carefully as records

A technically successful transfer can still leave an organization locked out on Monday morning.

List the accounts and services on which access depends. These may include the domain registrar, organizational email, the system used for single sign-on, multifactor authentication, integration accounts and the contact authorized to discuss billing. A subscription created by a departing volunteer can remain difficult to manage even when everyone agrees that it serves the organization.

Use named accounts and organizational control where supported. Make sure an authorized second administrator can sign in through their own account and approved recovery arrangements. Keep recovery material in a controlled credential-management system, separate from ordinary handover documents. A list of passwords sent around by email creates another problem rather than solving continuity.

Sequence the transition. If the old email or identity service authenticates the new application, verify replacement sign-in and recovery routes before closing it. Test from a fresh session so that a still-valid browser session does not conceal a broken login process.

Review automated connections as well. An integration can continue copying records, creating invoices or sending messages after staff believe a system has been retired. Recreate only the connections that are needed, grant appropriate permissions and document their owner. Revoke obsolete tokens and access after dependencies and any necessary fallback have been addressed. Credential changes that could interrupt essential services should be planned with qualified support.

Choose a clear moment when the new system takes over

Before the final move, decide where new work will be recorded and how changes made during the migration will be captured. Two systems accepting updates without a reconciliation method can quickly produce conflicting histories.

For a simple system, a short, announced pause in editing may be workable. A service that cannot pause needs a more careful arrangement for recording and transferring changes. Record the final export time, import outcome and the person who authorizes the switch.

Keep a practical fallback for a failed transition. Define the conditions that would trigger it and how any work already entered into the new system would be preserved and reconciled. Reopening the old application without that step may split the organization's records again.

Test the activities people depend on before announcing completion. Check forms, receipts, searches, access restrictions and reports. Confirm which system is allowed to send messages or collect payments. A duplicate reminder is embarrassing; a duplicate charge requires a much more serious response.

Communicate the change in ordinary language. Staff and volunteers need to know where to work, what has changed and where to report a problem. Participants and supporters need relevant instructions when their experience changes, with accessible alternatives where necessary.

Finally, distinguish the operational switch from contract cancellation and data deletion. Each has its own decision, timing and evidence. Confirm the cancellation outcome and final billing arrangements instead of assuming that an unused account has stopped renewing.

Close the old service without scattering new copies

Migration often creates a temporary forest of files: exports, cleaned versions, test imports, failed batches and copies downloaded by helpers. Give these files owners, approved storage locations and disposal dates. Limit access throughout the transition and protect transfers appropriately.

Before deletion, identify records that must remain available for legal, contractual, audit or operational reasons. Keep justified archives readable and access-controlled. Follow the applicable retention schedule and preserve material subject to a legal hold. The FTC’s business guidance recommends written retention policies specifying what must be kept, how it is secured, how long it is retained and how it is disposed of. The relevant obligations depend on the organization and the information involved. FTC guidance on protecting personal information.

Ask the outgoing provider what deletion covers, what residual copies remain, how backups are handled and when applicable retention periods expire. Request confirmation that identifies the account, scope and date, together with any exceptions. An immediate promise to erase everything may conflict with a legal retention obligation or the provider’s disclosed backup cycle.

Where the EU GDPR applies to a controller-processor relationship, Article 28 requires the contract to provide for return or deletion of personal data at the controller’s choice after processing services end, and deletion of existing copies unless EU or Member State law requires storage. That specific rule should not be presented as universal law. Obtain appropriate advice where records involve children, health, regulated activities or cross-border transfers. GDPR Article 28.

Update the organization's records of where information is held. Review privacy notices and contractual arrangements when the new provider, purposes or locations make changes necessary. Moving a database does not erase the organization's responsibilities toward the people in it.

Make the next exit easier

For each essential service, keep a brief, usable record of its owner, renewal deadline, export method, dependencies, tested limitations and next review. Store it somewhere the organization controls. Review it when staff change, a major feature is added or a contract comes up for renewal.

A reasonable first step this month is to choose one important system, export a safe sample and ask someone else to explain what it contains. Can they open the files, understand the fields and trace a record to its supporting evidence without relying on the person who set everything up?

That small exercise can reveal a large dependency while there is still time to address it calmly. The purpose is to protect freedom of choice and the continuity of useful work. An organization should be able to outgrow a tool without losing the knowledge, care and commitments it placed inside it.

If you have practical expertise in accessible technology, secure data migration or organizational continuity, consider proposing a clearly scoped contribution through Feel Worldwide Foundation’s partnership inquiry. Describe the support you could offer, its limits and the setting it would suit, without including confidential records. You can also support Feel Worldwide Foundation’s mission with a donation.

Previous
Previous

Build a Credible Case for Investing in a US Region

Next
Next

When People Can Admit Mistakes, Teams Can Learn