Plan the exit from a software solution when choosing it
Open source makes changes easier. Which data, accounts and services must move depends on the scope of the exit you choose.
An exit plan should state which future change needs to be possible when a software solution is chosen. A new development team, a new hosting environment and the complete replacement of connected services are different projects. Setting that boundary early allows a business to accept dependencies deliberately and agree on the evidence it needs.
Open-source code leaves external dependencies in place
A licence meeting the OSI's Open Source Definition includes access to source code and the ability to distribute modifications and derived works. It does not automatically transfer a hosted search service, a company account or the documents stored there.
In the fictional portal P-18, the application code has an open-source licence. Original documents are in separate file storage, person-to-project assignments are in the application and the search index is held by a managed service. A new developer can modify the code. Whether the portal will find the same documents under the same access rules after switching providers is a separate question.
Distinguish the scope of the switch before procurement
Three goals are possible in this example. The table sets out expected evidence, not a migration that has already taken place.
Goal of the switch | What may stay in this example | Evidence needed |
|---|---|---|
Hosting, storage and search service | The new team can work with its own authorised accounts; responsibilities and necessary documentation have been handed over. | |
New hosting environment for the application | Storage and search service under the company's control | The application reaches those services from the new environment and continues to enforce the agreed access rules. |
Complete replacement of connected services | The current providers need not remain | Original documents, descriptive metadata and permission mappings can be transferred; search and access are tested again in the target environment. |
Copying a search index does not automatically replace the original documents and their mappings. A rebuild needs a defined source for text, stable document identifiers and permissions. An index format understood only by the old service is not useful handover evidence for another search service.
Deliberately keeping a dependency can make sense
A managed service may provide benefits that justify the effort of switching later. The UK government's guidance on technical lock-in recommends balancing the impact of switching against the benefit of staying. It also discusses open formats and the availability of knowledge within the team.
For the second row, continuing to use the search service may be reasonable. It must then be clear who administers the account, can grant access and will maintain the service after the switch. If that service must also be replaceable, data access and testing an alternative become additional scope. The label “open source” does not settle this choice.
Put the chosen scope into the brief
A completed agreement for the example might say: “The application must be able to move to another hosting environment. Document storage and search remain in our company accounts. The target environment is tested for opening a permitted document and denying that same document to a restricted role.”
This makes the retained dependency visible and links the check to a concrete task. If a full product switch becomes necessary later, the business can identify which further data, interfaces and knowledge are missing. The exit plan needs updating as the system changes.
Sources
Read more
All articles
Software Development with ASES
Custom software, web and mobile apps