Test digital solution portability before committing
A solution is portable when you can recover the data and work you need in another environment with an understood, acceptable effort. An Export button is not sufficient: test a small exit journey before committing.
Map what you need to recover
Separate business data, attachments, history, permissions, automations and interfaces. For each item, identify its source, owner and recovery method. Keep unknowns in a dedicated column.
Illustrative example: leaving a CRM may require contacts, organisations, their relationships and opportunity stages. Exporting contacts alone recreates an address book rather than a working sales process. Adapt this editorial method to your activity.
Test what the export contains
In an authorised test environment, create fictional records: one organisation linked to two contacts, an attachment and a field containing an accented character. Export them and check identifiers, links, characters and missing elements. Use no real personal data for this demonstration.
Record the format, fields, documentation and observed limitations. Compare object counts by type and their relationships. Keep a sanitised sample and a description of the result rather than a screenshot of the export button alone.
Demonstrate recovery in another environment
Load the small export into a test destination or an appropriate reader. Check an entire task: finding the organisation, its contacts and its attachment. A readable archive does not demonstrate that workflows, permissions or automations have been reproduced.
Classify each item as recovered unchanged, transformed, recreated manually or not recovered. Document identifier mapping and checks. If no destination is available, write “recovery not tested”: that limitation must remain visible in the decision.
Estimate exit effort and uncertainties
Separate preparation, export, transformation, recovery, verification and overlap. Request estimates for unknown costs or state explicit assumptions. Include exit in your total-cost comparison without counting the same hours twice.
A dependency can deliver useful value. The cited UK guidance encourages weighing that value against the difficulty of changing providers. Its technical discussion informs this method; its public procurement requirements are not presented as French obligations.
Record the decision and its evidence
Record the decision, untested elements, remaining tasks and their owners. Before removing an old instance, define acceptance conditions, useful retention and rollback. A successful test exit does not justify deleting a production instance.
Review the worksheet when new fields, integrations or volumes change exit difficulty. Make the recovery trial a selection, handover or maintenance deliverable rather than a commercial promise that is hard to verify.
A record to keep with the decision
| Item | Evidence |
|---|---|
| Data and relationships | Objects, identifiers and dependencies to recover. |
| Export | Fictional sample, format, included fields and omissions. |
| Recovery | Task executed in the test destination and observed result. |
| Effort and limits | Known costs, unknowns, manual work and owners. |
Download the worksheet to fill in (CSV)
Frequently asked questions
Does a CSV export prove portability?
It only proves that a file can be obtained. Check its contents, relationships and recovery in the destination. Automations and permissions may require separate handling.
Should all proprietary dependencies be avoided?
Consider the benefit and the exit effort acceptable in your context. Make trade-offs visible and test critical points rather than promising complete independence.
Reference material
Government Digital Service · Managing technical lock-in in the cloud
The practical checklist is an editorial synthesis to adapt to your service. It does not constitute a certification or an audit result.