Vendor lock-in in work management software and the Data Act

Use a work management tool for long enough and your organization starts to take its shape. Processes, permissions and routines follow its logic, and new hires learn it in their first week. It becomes part of how work gets done, and as long as the terms are fair, nobody thinks about leaving.

That is until these terms change. The vendor gets acquired and rewrites its licensing model, the renewal quote comes in much higher, or the self-hosted version you rely on is discontinued. That's usually when someone first asks how realistic a switch would be, and the answer is rarely encouraging. It would take months, eat into budget planned for other projects and disrupt day-to-day operations. So you go into the negotiation without your strongest card: a credible option to walk away.

This is vendor lock-in, and it's far from rare. In a recent survey conducted in among 603 German companies, 59 percent named lock-in effects as the biggest obstacle to switching provider.

The EU Data Act sets out to reduce this kind of dependency. Its rules on switching periods, data export and support during the move have applied since 12 September 2025, and from 12 January 2027 providers can no longer charge switching fees.

That can give IT leaders a false sense of security. A regulated exit is not the same as an easy one. The effort depends on which data, settings and processes you can actually transfer, and how much your team has to rebuild in the new tool. Few companies check this before they give notice.

For anyone running Jira or Confluence Data Center for example, this is no longer a theoretical question. Both products reach their announced end of life on 28 March 2029, so a decision is due: where to go next, and what can come along.

Atlassian Cloud, another vendor, a different solution on your own servers: each route has its own challenges. Below, we look at what makes switching work management tools so demanding, where the EU Data Act helps, and seven questions that let you estimate the effort before you sign.

Key takeaways

1. In work management tools, the real lock-in sits in processes, permissions and integrations

   Exporting tickets and pages is usually possible. Workflows, automations, permissions, apps and your team's know-how are much harder to take with you.

2. The EU Data Act covers SaaS and secures the export of data and configuration

   Since September 2025, notice is capped at two months and the transition at 30 days. From January 2027, switching charges fall away. Settings and access rights can be included too.

3. A self-hosted Data Center is outside the Data Act

   Protection only starts when you move to SaaS, and even then it has gaps. Before you sign, find out how you would leave that provider later.

4. Your configuration won't necessarily work in the new tool

   For infrastructure services, the Data Act requires measures that enable comparable functionality after a switch. SaaS has no such requirement, so you need to plan the rebuild yourself.

5. Know what leaving costs before you commit

   Seven questions make the effort visible before you sign.

What is vendor lock-in?

Vendor lock-in, also called the lock-in effect, is a dependency on a single vendor that makes switching so costly, risky or disruptive that it's barely an option. The causes can be technical (proprietary formats and interfaces), contractual (long terms) or economic (investments you'd lose by leaving).

A study by Asterès for Cigref, the French association of corporate IT users, shows how expensive limited switching options can get. The 54 IT leaders surveyed reported price increases for cloud and software services averaging 8.7 percent a year over the past three years, and they expect 12 percent a year over the next five. The study points to high switching costs and a lack of alternatives as key reasons why vendors can make these increases stick.

Extrapolated across European companies and public administrations, these increases could add an average of EUR 140 billion a year in extra costs between 2026 and 2030. That's a model calculation based on specific assumptions, not a settled outcome. But it it clarifies the stakes. if you can barely switch, you have little leverage against higher prices.

In cloud infrastructure, cloud vendor lock-in is mostly about whether servers and applications can move to another provider, and that's where the Data Act's functional equivalence rules apply. In work management software such as Jira, Confluence, monday.com or Asana, the dependency runs deeper. It also lives in the workflows, permissions and integrations your daily collaboration is built on.

Where lock-in really sits in work management tools

Years of project and knowledge management in one tool leave behind far more than data. Structures, rules and ways of working build up, and they don't transfer easily to another system.

It helps to think of this in five layers. The more tightly a layer is tied to the tool, the more effort a switch takes.

Atlassian and Slack show how different these hurdles can be.

Atlassian: Jira Cloud can export up to 10,000 work items at once as CSV. That helps with ticket data, but it's no substitute for a full migration. Even moving from Jira Server or Data Center to Atlassian's own cloud leaves gaps. The Jira Cloud Migration Assistant doesn't carry over global permissions, for example, or certain workflow properties and triggers. Much app data only moves if the app vendor provides its own migration path. Dashboards and cross-project filters, on the other hand, are now supported. Our post on Jira as an operating system shows how much configuration a mature instance can hold.

Slack: In 2025, Salesforce tightened the Slack API terms. Third parties can no longer bulk export data, store it long-term or use it for large language models. This points to a different kind of dependency; what connected tools can do also depends on the platform's access and usage rules.

What both examples show is that a data export alone won't make a switch work. A file can hold every ticket without the approval rules that govern how those tickets move. Even an exported automation won't tell you why it's tied to a particular field or which exception it handles. That knowledge often lives with the people who use the tool every day, so it belongs in migration planning alongside data and configuration.

What the EU Data Act regulates when you switch providers

Since 12 September 2025, the EU Data Act has governed how customers in the EU can switch between covered cloud services or move their data onto their own servers. That includes software as a service, or SaaS. The rules apply to companies of any size, and to existing contracts too.

When you switch providers, four requirements matter most:

• Notice period: No more than two months may pass between telling your provider you want to switch and the start of the switching process. That doesn't mean you can walk away from any running contract for free.

• Transition period: The switch itself should generally be completed within 30 calendar days. If that's not technically feasible, the provider has to explain why within 14 working days of your request, and can then set an alternative period of up to seven months. You can extend the period once yourself.

• Data retrieval: Once the transition period ends, your data has to stay retrievable for at least another 30 calendar days.

• Contract content: The contract has to state which data and digital assets can be transferred, and which categories of internal data are excluded to protect trade secrets. Those exclusions must not block or delay the switch.

Then there are the charges. Until 11 January 2027, providers can charge no more than the costs directly linked to the switch. From 12 January 2027, these switching charges, data egress fees included, generally fall away. Regular usage fees and any compensation for early termination are a separate matter.

One point is easy to miss: the EU Data Act covers more than tickets and pages. Metadata on settings, security and access rights can be included, so part of your configuration is covered in principle. What you can take with you also depends on your usage rights, though. The provider's protected technology doesn't become yours.

Atlassian Data Center is a case in point: none of this applies yet.

Data Center is the version of Jira and Confluence that companies run themselves. Buying a software license and running the installation yourself doesn't, on its own, count as using a data processing service under the Data Act. What matters is how the software is actually delivered. If a service provider runs the installation for you, whether it falls under the definition has to be assessed case by case.

This matters when you choose what comes next, because Jira and Confluence Data Center reach their announced end of life on 28 March 2029. If that's pushing you toward a cloud service, check its exit options before you sign. The switching rules may apply to the new service, but they don't automatically cover the migration away from your current installation.

Customers in Switzerland and the UK can't rely on the Data Act.

Its switching rules apply to providers delivering covered services to customers in the EU, wherever the provider is based. A purely Swiss or UK contract and use case isn't automatically covered. The reverse also holds: a Swiss or UK provider can be bound by the rules toward its EU customers. If your group has companies on both sides, review the contracting party, where the service is used and the exit rights in the contract together.

What the EU Data Act doesn't solve

The Data Act lowers the legal, economic and technical barriers to switching. How much work is left in the target system, though, depends on what you've built in your current tool. In work management software, that goes well beyond importing data.

Data and structure: a readable export isn't a working transfer

Infrastructure providers have to take reasonable measures so that comparable functionality is possible after a switch. That functional equivalence requirement doesn't apply to SaaS. SaaS providers still have to offer open interfaces and meet the relevant data portability and interoperability requirements. Until common specifications or harmonized standards are published, they have to provide a structured, commonly used and machine-readable export on request. But a CSV or JSON file alone doesn't guarantee that the target system picks up every link and permission correctly.

Configuration: exportable doesn't mean usable

You can take your workflow definitions with you. Whether the target system can read them isn't something the Data Act addresses, and your current provider doesn't have to build new technology or disclose protected technology to make it work. Check and plan the rebuild up front.

Ecosystem: each extra app may need its own migration path

Marketplace apps and integrations can come with their own contracts, data and technical requirements, so the main platform's export doesn't automatically cover them. For every business-critical extension, find out who enables the export and what the target system needs as a replacement.

Team know-how: experience doesn't come as a file

Query languages, admin routines and established ways of working are part of everyday work. An export may contain the technical configuration, but it won't necessarily explain why a rule exists or which exception it handles. That knowledge has to be documented and adapted to the new tool.

The contract leaves important questions open too.

Leaving early can still cost you

Fixed-term contracts can still include proportionate compensation for early termination. And the switching rules don't cap license prices at renewal.

Custom-built services are exempt

The exemption applies to services whose main features were largely built for individual customers and that aren't offered at scale through a service catalog. Ordinary customization of standard software usually doesn't qualify. For exempt services, switching charges can remain allowed even after January 2027, among other things. Providers have to tell you about the relevant exemptions before you sign.

The European Commission's Digital Omnibus proposal includes further changes to the switching rules. A proposal doesn't change the rules in force, though. For your contract, the law as it currently stands is what counts.

A certain degree of lock-in isn't automatically a bad thing. A tool where tickets, documentation and automations work well together saves you interfaces and maintenance. A well-configured system also stays attractive because it supports the way you work. The point is to enter this dependency knowingly, and to know what a later switch would take and cost.

Financial entities within the scope of the DORA regulation have further obligations. For ICT services that support critical or important functions, exit plans have to be documented, sufficiently tested and reviewed regularly. Alternative solutions and transition plans should allow a secure and complete transfer to another provider or back in-house. The seven questions below can serve as the basis for that kind of cloud exit strategy.

Exit check: 7 questions to ask before you sign

Where the EU Data Act applies, the contract has to name the data and digital assets you can transfer. Even where it doesn't, it's worth getting this in writing.

These seven questions show where the effort and cost of a later exit come from. Put them to your current vendor as well as your next one.

1. What data, metadata and history does the export include, and in what format? Ask to see the list. Beyond the tickets, look for change history, links, attachments and permissions.

2. What limits apply to exports and APIs? Volume caps, daily quotas and throttling all affect how long a full transfer takes. Also ask whether the vendor raises quotas for a migration.

3. Can workflows, automations and permissions be exported? If so, ask whether the target system can import that configuration, or whether it only works as documentation for a rebuild.

4. Which processes depend on third-party apps? For each important extension, clarify the contract, the data export and the replacement in the new tool.

5. Is there a source code escrow, and what triggers it? It protects you if the vendor is sold or shuts down.

6. What terms, deadlines and costs apply when you leave and when you renew? Separate switching charges from regular usage fees and any compensation for early termination. Check the price change clauses and how long a price guarantee runs.

7. When was the full switch last tested? A test export shows what you can get out. Only importing it into a test environment of the target system shows what arrives and actually works. Check configuration, integrations and your key workflows as well.

How to estimate the effort

Start with a list of every workflow, automation, app and integration the new system will need to take over or replace. Sort each item into one of three groups: transfers directly, needs adapting, or needs rebuilding. Then estimate the effort in person-days with your admin and project team. Add data cleanup, testing, training and project coordination.

Multiply the person-days by the relevant internal or external day rates, and add any costs for migration tools, consulting and running both systems in parallel. That gives you a first range for the switching effort, and a test run lets you check your assumptions.

Then compare that figure with the cost of staying and the changes ahead. For Jira and Confluence Data Center, that includes the announced end of life on 28 March 2029, after which the products will generally be read-only. Moving to Atlassian Cloud is a migration project in its own right, with configuration and apps that need checking separately. Our post on the end of Atlassian Data Center goes into more detail.

Where sovara stands

Open formats, documented interfaces and clear contract terms make a later exit easier to assess. sovara, our European platform for project and knowledge work and an alternative to Jira and Confluence, should be held to the same standard. Anyone who recommends an exit check should be ready to answer it.

1. Export: Content can be exported via the REST API as JSON, and pages as Markdown, with links between tickets included.

2. Limits: The whole workspace can be exported via the REST API or the command line. Bulk CSV exports allow up to 10,000 rows and 20 exports per day.

3. Configuration: Workflows, fields and automations can be exported as JSON and imported into another sovara instance. Because the configuration is readable, it can serve as a basis for a rebuild in another tool, though another system can't run it directly.

4. Apps: Scripted automations and time tracking, for example, are built into sovara. Depending on your setup, that means fewer additional apps and contracts. Other systems connect via the REST API and webhooks.

5. Escrow: The source code is deposited with an independent third party. The escrow agreement sets out when customers get access and which usage rights come with it.

6. Contract: The standard contract includes a company-wide license, regardless of the number of users, and a three-year price guarantee. For covered services to customers in the EU, the statutory switching rules apply, even though rready is based in Switzerland. Any exit rights guaranteed beyond that have to be spelled out in each offer.

7. Test: Customers can trigger the export themselves, within the confirmed quotas and technical limits from answer 2. A full exit test also means checking the import into your chosen target system.

Open formats and accessible configuration make a later switch easier to assess. But an API alone doesn't remove the dependency on a system, and neither does an escrow. What counts is which parts can actually be transferred and how much rebuilding is left in the target system. That's exactly what the confirmed answers are meant to show.

The move to sovara also needs a clear scope before the project starts. Our migration guarantee covers moving a standard Jira setup with tickets, workflows and automations.

Plugins and custom code get a separate review. For each app, we work out whether sovara already covers the feature, whether it needs adapting or whether it can be dropped. ScriptRunner automations and fields from apps can be handled as guided project work. sovara doesn't have a marketplace on the scale of Atlassian's, so highly specialized extensions need to be assessed one by one.

Our product comparison shows in detail how sovara differs from Jira and Confluence.

Conclusion

Lock-in makes itself felt when prices rise or a switch comes due. The Data Act strengthens your exit options from covered cloud services. It doesn't replace a technical assessment of the target system, though, or the work of rebuilding your environment.

For companies on Jira or Confluence Data Center, the 2029 end of life makes that assessment especially urgent. Use the seven questions with your current vendor and your next one to find out what can be transferred and what the rest will take. The earlier you test it, the sounder your decision will be.

If you're already planning the switch, our post on migrating to a sovereign solution can help. The Sovereignty Trust Center sets out where rready stands on location, hosting and export.

FAQs

What does vendor lock-in mean?

It's a dependency on a vendor that makes switching so time-consuming, risky or expensive that it's barely an option. In work management software, the dependency also comes from workflows, automations, apps and established ways of working.

Does the EU Data Act apply to SaaS tools?

Yes, as long as the service meets the legal definition. SaaS is explicitly one of the covered delivery models. Time-limited trial and evaluation versions are exempt, and certain custom-built services are exempt from some obligations (Art. 31).

Does the EU Data Act apply to Jira Data Center?

A license for a Jira installation you host yourself generally falls outside the switching rules for data processing services. For managed or hosted installations, it depends on the actual service. The test is Article 2(8), not the product name.

When are switching charges banned?

For covered services, generally from 12 January 2027 (Art. 29(1)). Until then, providers can only charge costs directly linked to the switch. Regular usage fees and any proportionate compensation for early termination are a separate matter. Certain custom-built services are exempt.

Does the EU Data Act apply in Switzerland or the UK?

Its switching rules apply to providers delivering covered services to customers in the EU, even if the provider is based in Switzerland or the UK. A purely Swiss or UK contract and use case isn't automatically covered, but comparable exit rights can be agreed in the contract.

Can I export all my Jira data?

That depends on the export route, the type of data and the apps you use. A Jira export as CSV covers up to 10,000 work items at once in Jira Cloud, and APIs and other export options can cover further needs. That still doesn't add up to a full transfer to another tool: history, links, configuration and app data all need checking separately. For Confluence, see our post on the Confluence alternative.

What is source code escrow?

With source code escrow, also known as software escrow, the vendor deposits its source code with an independent trustee. If a contractually agreed event occurs, customers can get access and the agreed usage rights. Whether that's enough to keep the software running depends on factors such as completeness, how up to date the code is, documentation and any third-party licenses required. An escrow is no substitute for a data export or migration planning.

Is open source software automatically free of lock-in?

No. An open license and accessible source code can reduce your dependence on a single vendor staying in business. But workflows, extensions, data models and your team's know-how still tie you to that particular solution. Moving away from open source software also has to be planned and tested.