A German real-estate company wishes to change the service used to transmit its property listings. The existing listings should continue to be managed in a traceable manner. The new service therefore receives not just a list of property names. Before the transfer, it must be clarified which existing portal identities belong to which source and how the actually supported changeover will proceed.
The case is fictitious. The article does not modify any interface and does not describe any specific function of Immosearch or any other account.
Distinguish between data format and the responsible delivery service
OpenImmo explains in its FAQ that it is a data description and does not play an active role in production, transmission or distribution. [Q1] The note that the same data format is used therefore alone does not yet confirm a clarified transition between two services.
Our recommendation is to coordinate with the actually authorised former and future participants. Who will manage the data before the change, who may trigger which change, and what confirmation does the respective portal require? An expected seamless takeover remains an open assumption until confirmed.
Link existing identities to the actual unit
Combine internal property identifier, provider reference and the confirmed respective portal identity. The same title or similar photos are not sufficient for several comparable units. Any already existing duplicate listings are initially documented with their origin.
Media can also have their own references: The ImmoScout 24 documentation describes attachments in relation to a property and additionally names its own attachment identifiers. [Q2] That is an example of the specified API, not a general numbering system of all portals.
Plan the temporal handover without parallel assumptions
In the fictional case a flat exists both in the previous service and in the preparation for the new one. Both teams wish to send changes. Before the transition they therefore determine, based on the confirmed channel process, which route should be active when and how the other will be handled.
No productive old route is switched off unilaterally nor is the same flat re-created as a precaution. Supported identity retention, any necessary new assignment and handling of existing publications are confirmed concretely. A private identification matrix does not replace this confirmation.
Check rights and actual outcome separately
The authorisation to forward and to continue using media remains a separate check. Passwords or access tokens do not belong in the general transfer document. Required accesses are organised via the authorised channels provided for that purpose.
After a separately authorised changeover, it is checked on the confirmed property which source actually leads and which listing continues to exist. Order, processing and observed state remain separate evidences. Open duplicate publications are assigned a concrete responsibility. The transition therefore ends at a traceable data path, rather than solely on the date of the new service contract.