ation for the WIMS 2.0 SDP can be easily performed. This migration can fol- low two paths: Considering that both SDPs, the traditional and WIMS 2.0, are moved to a cloud computing architecture. In this path, the point of contact with the in-company infrastructure of the operator is the Service Broker. Under this consideration, some access control functionalities should be included in this entity that ensures that SLA agreement is fulfilled. Considering that the traditional SDP remains under the infrastructure of the operator and the WIMS 2.0 SDP is moved to the cloud. This way requires a multilevel integration and it is more complex. Entities like IMS thin client, the UGC 2.0 platform, and the IMS PSE 2.0 platform interact with the in-company SDP in the same way, but other like the IMS exposure layer or the User profile entity requires an adaptation. The IMS Exposure Layer is a platform where the IMS APIs are exposed to third parties. In this case, this Moving the SDP to the Cloud platform requires a connection with the IMS and common enablers. The User Profile entity is a database that stores the relationships between Telco identities and the identities used by Web 2.0 services and it requires or con- necting both databases or to have a replica of the Telco identities in the WIMS 2.0 SDP. Under this consideration, the access control functionalities should be included in the SDP framework. Any of the two options mentioned is possible and will provide a collection of mixed Telco-Internet services in a cloud computing strategy, enabling a scalable solution for those operators which are not in the position to tackle huge costs in the deployment of a SDP allowing the convergence of both worlds, the Telco and Internet. 3.5 Conclusions SDP is a key component in order to deploy commercial Telco services especially when the operator is planning to launch services using advanced enablers like Presence, XDM, PoC, and SO on. A deployment of the SDP architecture is expensive in CAPEX and requires expertise during all the pha