Summary of the Data Portability meeting of the mobility software providers (2024-07-17)

[janinamincer-daszkiewicz]

This is a summary of the Data Portability meeting of the mobility software providers held during the Infrastructure Forum on 2024-07-17

1. The implementation of a mechanism supporting data portability should result from the business interest of the provider and not be imposed by regulations.
2. Changing the provider by HEI should be fully transparent to the network and partners of this HEI.
3. The main goal behind this rule is that such a change does not burden partners or cause misunderstandings and confusion in the network.
4. A data portability mechanism should be formally specified to help implementers avoid situations where different providers implement different data formats.
5. To maintain full transparency, we need to transfer entire set of data from the old provider to the new one, including historical data.
6. Since this transfer happens once between two installations, the export/import mechanism via a structured set of files is the easiest to implement (no need to activate/deactivate any special APIs).
7. All identifiers in the transferred objects should be preserved.
8. IIA approvals should not change, which means that the iia-hash and the snapshot of the mutually approved IIA returned by the new provider should be the same as the iia-hash and the snapshot returned by the old provider.

Please, share your comments.

[JoepDemey]

Hello, I read that we need special data portability API's for IIA, LA, ... and they all have an index and get endpoint. Can't we use the API's we already have? There already is an IIA API with index and get endpoint. If we could just add an optional parameter to indicate we are migrating data, the server than checks if the request comes from the HEI itself and returns all the data for that hei. That way we can just reuse the existing API's instead of duplicating them, that will be very helpful when these API's change version again because we would need to change these data portability too if we have them separately.

If we reuse the existing API's, the steps to migrate would change:

1. The HEI decides to switch providers for a family of distinct APIs (IIAs, LAs etc) and informs the provider they are using.
2. The HEI registers in the EWP network with a new provider, or their own in-house solution.
3. The new provider should be able to access the data portability endpoint of the old provider and import all the data to their system.
4. After the data import is finished, the HEI is notified by the new provider
5. The HEI goes to the Registration Portal and disables the regular API endpoints.
6. The old provider removes all the relevant APIs from their manifest file.
7. The new provider should publish all the relevant APIs in their manifest file.
8. The HEI goes to the Registration Portal and enables the APIs of the new provider
9. The HEI is able to resume its activities in the EWP network seamlessly with the new provider.