Migrating cleanly out of a SaaS comes down to five moves: check what the export actually gives you, rebuild the target data model before copying anything, run the old and new systems in parallel long enough to verify everything, switch over on a quiet day, and have negotiated the next tool's reversibility before you even sign its contract. No software does this work for you. The method does.
What does an export actually give you, beyond the marketing promise?
Most SaaS vendors display a prominent "export my data" button. What that button actually produces deserves to be checked before you base a migration decision on it — not after.
Formats, first. A CSV or Excel export flattens relationships that existed between your tables — a customer linked to several orders, an order linked to several line items — into a series of columns that will need to be reconstructed by hand. A JSON or XML export preserves more structure, but then requires mapping work toward your new model. A PDF export, common for invoices, simply isn't reusable data: it's a picture of the data.
Completeness, next. Certain custom fields, internal notes, and workflow statuses simply don't appear in the standard export — the vendor never planned for them, or reserves them for a higher-tier plan. Attachments rarely follow the main export: scanned invoices, contracts, and product images often require a separate, sometimes manual, file-by-file export.
History and metadata, finally, are the great forgotten ones. A record's actual creation date, its author, the successive edits, the comments exchanged around a case: this layer disappears most often, even though it carries part of the value of your data. The only way to know what you'll lose is to run a test export, early, and open it field by field next to the still-active tool.
Rebuild the target data model before copying anything
A failed migration almost always starts with the same reflex: copying the old model as-is into the new tool. The result faithfully reproduces the approximations accumulated over years — fields that have become obsolete, duplicates never cleaned up, categories that no longer make sense.
The right order reverses the logic. First, decide what the business actually needs in the new tool: which fields, which categories, which identifiers are authoritative. Only then map each source field to its destination, one by one, accepting that some things no longer serve a purpose and should be dropped. This is design work, not copy-paste, and it's exactly the kind of project a custom-built solution can properly frame, with a data model designed for the business rather than inherited from a generic tool.
Why running both systems in parallel isn't a matter of comfort
Running the old and new systems in parallel for a defined period isn't a superfluous precaution: it's what lets you catch discrepancies before they become your new reality. A customer entered twice, an amount that no longer matches, a status that only updates on one side — these are the details that running both systems in parallel reveals, while they're still easy to fix.
The rule that avoids getting bogged down is easy to state, harder to hold to: set an end date for the parallel run before you start it, and cover at least one full cycle of the activity in question — a billing month, a reporting quarter, depending on what's being migrated. Without an announced end date, double entry becomes entrenched, wears teams down, and no one dares to call it anymore.
Choosing the right day to switch over
The switchover itself deserves to be treated as a project, not as a switch you flip on a Friday evening hoping it goes through. The best day is a quiet one: no accounting close, no sales campaign, no period of heavy customer activity. Warn the team in advance, freeze changes in the old system a few hours before the switchover, and set aside a slot for final verification rather than discovering problems in production.
Above all, keep the old system accessible, at least in read-only mode, for a few weeks after the switchover. The temptation to cancel everything on the same day is understandable; it also deprives the team of the only remaining safety net if a discrepancy turns up once the new tool has actually been put to the test.
The reversibility clause: negotiated before signing, not after
This is the most poorly anticipated point in the entire process. Reversibility is the contractual ability to retrieve all of your data, in a usable format, within a defined timeframe — and it gets negotiated when you sign the contract for the next tool, never after, once the balance of power has already tipped in the vendor's favor.
A reversibility clause worthy of the name spells out several points:
- the guaranteed export format — structured and documented, not a PDF;
- the delivery timeframe after a request;
- the cost of the operation, free or capped, but known in advance;
- how long the data remains accessible after the contract ends;
- the fate of attachments and history, explicitly included or explicitly excluded.
None of these points is guaranteed by default. A vendor that refuses to put them in writing before signing gives a fairly clear indication of what it will offer the day you want to leave.
This clause actually touches on a broader question: who owns your tool, your code, and your data once the contract is signed. I addressed that question on its own in Who owns your tool, your code, your data? It also often connects to a hosting question: changing tools frequently comes with a change of hosting location, and I detailed what that really changes in Hosting in Switzerland: what actually changes
The myth of the miracle tool
No migration software, however well-praised, does this work for you. Automatic synchronization tools handle the mechanics of the transfer, not the substantive decisions: which field to keep, which data to merge, which day to switch over. These are human, documented decisions, made in order — and that's exactly why a migration should be prepared as a small project, with a named owner, rather than as a task delegated to an "import" button.
Even before getting there, you first need to know what you hold and where: the inventory I describe in nLPD: where is your SME's data actually sitting? is the natural starting point for any serious migration. And because the question goes beyond mere technical mechanics, I place it within the broader framework of What should a Swiss SME do about AI in 2026?, where the trade-off between keeping, migrating, and rebuilding as a custom-built solution plays out function by function.
FiscalDoc, the local application I built for my own tax filing, illustrates the best migration there is: the one you never have to redo, because the data never left the machine. It's not the answer to everything, but before migrating yet again to yet another SaaS, it's worth asking whether owning the tool wouldn't settle the question once and for all — I documented it in FiscalDoc: replacing CHF 1,400/year of SaaS with local AI
Key takeaways
— Check what an export actually gives you — formats, completeness, attachments, history — before basing a migration decision on it. — Running both systems in parallel with an announced end date, and switching over on a quiet day, avoids most migration incidents. — Negotiate the reversibility clause when signing the next contract, never after: guaranteed format, timeframe, cost, and access duration all need to be in writing.
FAQ
Is there a tool that automatically migrates all my data without me having to touch it? No, not for structured business data with its history and relationships. Synchronization tools move files; they don't decide which field to keep, which data to merge, or which duplicate to delete. That decision-making work stays human, even when the mechanics of the transfer are automated.
How long should you plan for running both systems in parallel? Long enough to cover at least one full cycle of the activity being migrated — a billing month, a reporting quarter, depending on the case. Set the end date before you start rather than waiting for double entry to stop on its own: it never does.
What if the vendor doesn't offer a complete export? Treat it as a warning sign, not just a technical obstacle. A vendor that limits exports limits your freedom to leave, and that's information worth knowing before you renew, not after. Push in writing, and if nothing changes, factor that point into the selection criteria for your next tool.
Do you have to migrate all the data, including old archives? Not necessarily. Some older data can remain accessible in read-only mode in the old system, or in an archived export, without being reloaded into the new tool. Migrating selectively only what still gets used keeps the new system from carrying the weight of the old one.
I didn't negotiate a reversibility clause when I signed: is it too late? No, but the balance of power is less favorable once the contract is signed. The right moment to raise it again is renewal — the one moment the vendor genuinely risks losing you if they refuse. In the meantime, at least request a test export to find out where you actually stand.
Facing a tool change and worried about losing data along the way? The AI Usage Diagnostic: sixty minutes to map your actual workflows, identify what deserves a custom build, what stays in SaaS, and what doesn't need AI at all. Book a diagnostic
Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.