Choosing software also means planning the exit
When choosing new software, we look at features, usability and price. That is understandable: the application should solve a problem rather than make getting started difficult.
I would still ask one question at the outset: what happens to our work if we no longer want to use this software?
Consider a customer management system. Over several years, it accumulates contacts, quotations, orders and conversation notes. Documents are uploaded, responsibilities assigned and records linked. Eventually, another supplier becomes a better fit for the business.
The old application offers an export. It produces a table of names and addresses, but attachments are missing, histories remain behind and the relationships between customers, orders and invoices are lost.
This example is fictional. It illustrates the difference between two promises: handing over some data and actually enabling people to continue working with it.
A current reason to look closely: The Data Act
The European Data Act has applied since 12 September 2025. Its objectives include making switching between covered data processing services easier and removing obstacles in the cloud market. The European Commission explains this in its overview updated on 2 July 2026. [1]
The next important date is 12 January 2027. From then, providers may no longer impose switching charges for operations covered by the legislation, including relevant data egress charges associated with switching. For covered platform and software services, the Commission also describes requirements for open interfaces and commonly used, machine-readable export formats. [2]
This does not mean that an entire software migration becomes free in January. Data cleansing, adapting the destination system, internal project work and training still require resources. I would continue to budget for them.
Nor is every application automatically subject to identical switching rules. The actual service and the legislation's scope matter. Not all internal provider information is covered without limits: intellectual property and trade secrets are subject to specific safeguards and distinctions. [2]
Practical checks therefore remain necessary when choosing software. A legal entitlement is of limited help if nobody has identified the data needed until the deadline is approaching.
An export button says little about export quality
For me, a useful export starts by identifying the information that makes up the work.
In our fictional customer management system, that includes more than the visible customer records:
Customers and contacts: clear identification, contact details and the additional fields needed.
Quotations and orders: contents, processing status and links to the relevant customer.
Documents and attachments: files with a reliable association to the correct record.
Processing histories: necessary timestamps and documented changes.
Settings and permissions: an overview that allows the destination environment to be configured deliberately.
These are examples of possible requirements, not a blanket legal entitlement to every item listed.
The distinction matters. Not everything can be transferred unchanged. Some functions differ in the new system or do not exist at all. A decision is then needed on future use or archiving.
A migration has not succeeded merely because files exist if nobody can tell which records belong together.
CSV and JSON help, but a file extension is not enough
Open, documented formats make further processing easier. They do not automatically answer every question about meaning.
The W3C's CSV on the Web primer, published on 25 February 2016, describes a limitation of plain CSV files: the format alone does not define column data types or which values must be unique. Additional metadata can express these rules and support validation. [3]
I would therefore also request field documentation. Does a number represent an amount, an internal identifier or a postcode? What does an empty value mean? Which time zone applies to timestamps?
For example, customer number 00127 must not accidentally be treated as an ordinary number if its leading zeroes are important to identification.
Relationships must remain understandable too. An order list should identify the customer associated with each order. Attachments need the same reliability.
For developers, this is a data modelling task. A well-described export is not created simply by writing the entire database into a file.
An interface must be usable in practice
An application programming interface, usually called an API, gives other applications controlled access to certain functions and data.
Established approaches exist for describing interfaces. OpenAPI Specification 3.2.1, published on 10 September 2026, describes HTTP interfaces in a standardised, programming-language-independent form. People and tools can use it to understand a service's capabilities. [4]
During a demonstration, I would still not settle for the statement that an API exists.
I want to know whether the required data is accessible, what permissions are needed and which request limits apply. How interface changes are announced matters as well.
A connection delivering only some of the required information may be insufficient for a complete migration, while being exactly right for regular transfers to another application.
Open must not be confused with unprotected. Interface documentation may be openly available, while access to customer data still requires appropriate authorisation.
For developers: Treat leaving as a normal feature
When planning a new application, I would not wait until the first customer cancels to add export and import functions.
Stable identifiers, documented formats and clearly defined exchanges with external services belong in the design. If important information exists only in undocumented custom fields, someone will have to reconstruct its meaning later.
For an external document-generation service, for example, I would document the input data and returned results. This helps establish whether another service could take over the task.
Not every supplier dependency is a mistake. A particular feature may offer substantial benefits. I would simply make a conscious decision about its value and the effort required to replace it.
Complete interchangeability at any cost is not a sensible target either. A simple application need not support every imaginable service in advance. What matters is that major dependencies are understood rather than accidental.
Test the move before time becomes critical
Before a major rollout, I would agree a small trial migration.
Suitable test records might include a customer with several contacts, an order with attachments and a record amended after creation. Export these and import them into a separate test environment.
The test should not stop at an import successful message. Can documents be opened? Are amounts and dates correct? Have relationships survived? Are special characters displayed correctly?
Record counts provide an initial indication, not a complete proof. Identical totals can still conceal incorrect associations.
The real migration also needs a clear cutover point. Otherwise, old data may be transferred while new changes are being made in the source system.
A route back belongs in the plan too. What must be confirmed before the old service is switched off? What happens if the new application cannot yet support an important workflow?
These questions should be answered before cancellation.
The migration file needs protection too
A complete export of a customer management system can be particularly sensitive because it brings a great deal of information together.
In its small business guide, checked on 10 October 2026, the European Data Protection Board explains that personal data must be protected through technical and organisational measures appropriate to the risk. Depending on the circumstances, these include access controls, encryption and defined procedures. [5]
For a migration, I would specify who may receive the export, where it is held temporarily and how it is transferred. Keeping it on an employee's personal desktop is not a planned handover process.
After completion, unnecessary temporary copies should be removed in a controlled way. Required archives and backups should remain deliberately configured. Retention requirements and permitted deletion need clarification beforehand.
A successful import does not automatically conclude every task associated with switching.
What I want to know before subscribing
Alongside the feature demonstration, I would request a written explanation of exit conditions.
Which contents can be exported? Which formats are available? Who helps with problems? How long does access remain after the contract ends? Which costs are proposed for the planned migration, and on what basis?
Access to important functions also matters. Must exports be requested from the supplier, or can authorised users perform them? Is understandable documentation available?
During ongoing support, I would repeat the trial after significant changes. An export that worked several years ago does not establish whether additional features used today are included.
My conclusion: Good software must cope with switching
I do not believe in leaving a suitable supplier on principle. A proven working relationship can be valuable.
Nevertheless, I want to stay because the service is convincing, not because switching has become practically impossible.
That requires more than a reassuring statement about our own data. Information must be available in a form that supports useful continued work. Documentation, relationships between records and a tested handover process belong together.
Good software makes joining easy. Trustworthy software makes leaving understandable too.
Scope and research
Research date: 10 October 2026. General guidance, not a legal assessment of a particular contract, service or migration. Statutory switching rules apply within their scope and do not automatically make an entire migration free.
Sources and further reading
Original sources checked on 10 October 2026. Publication and access dates are distinct.
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗